quantlib-dev — Discussion of QuantLib development

[Quantlib-dev] RE: MakeScheduler

[Andre L. <An...@de...>]

Luigi,

Sorry for not making myself clear, I realize I would not need to implement
MakeScheduler.
Yr example triggered me to think of something else I'm doing where a
conversion operator would work very nicely.
SWIG does not directly support the concept of conversion operators, is there
another mechanism/hook I can use to get a similar result?

Later
Andre

Re: [Quantlib-dev] RE: Latest commits

[Luigi B. <lui...@fa...>]

At 11:35 AM 7/25/03 +0200, Andre Louw wrote:
> > class MakeScheduler {
> >       ...
> >     operator Scheduler() {
> >         return Scheduler(mandatory params, stub, fromEnd, ...);
> >     }
> > };
>
>Is there a nice way of implementing the conversion operator in SWIG? Any
>examples in QuantLib?

As for Python, there's no need to export MakeScheduler since it has keyword 
arguments---one can write

s = Scheduler(..., fromEnd = 1)
s = Scheduler(..., stub = Date(...))

For the other languages, I'll have to think about it...

Later,
         Luigi

[Quantlib-dev] RE: Latest commits

[Andre L. <An...@de...>]

Luigi,

> class MakeScheduler {
>	...
>     operator Scheduler() {
>         return Scheduler(mandatory params, stub, fromEnd, ...);
>     }
> };

Is there a nice way of implementing the conversion operator in SWIG? Any
examples in QuantLib?

Thanx
Andre

[Quantlib-dev] Fwd: Re: [Quantlib-users] CapeTools.net web site containing QuantLib based calculations

[Ferdinando A. <fer...@am...>]

>From: "Toyin Akin" <toy...@vi...>
>To: "Ferdinando Ametrano" <fer...@am...>
>Subject: Re: [Quantlib-users] CapeTools.net web site containing   QuantLib 
>based calculations
>Date: Thu, 24 Jul 2003 19:08:38 +0100
>
>
>Hi,
>
>Please let me know of your initial thoughts/comments regarding the
>website/pricers.
>I would certainly like to taylor some deal/market pricers for developers as
>well as traders/marketers.

Best Regards,
Toyin Akin.

[Quantlib-dev] Branch tomorrow?

[Luigi B. <lui...@fa...>]

Hi all,
	now that Neil's work is checked in, I'd like to create the branch for next 
release. Unless somebody tells me he has some NEW stuff to check in, I'm 
going to create it at 12:00 tomorrow (Friday), Italian time. Please leave 
the cvs alone for some little time around. After that, fixes and tune-ups 
for the release will have to be checked into the branch. New stuff will go 
on the trunk and will not make it into next release.

Later,
	Luigi

Re: [Quantlib-dev] RE: Latest commits

[Luigi B. <lui...@fa...>]

At 03:25 PM 7/23/03 +0200, Andre Louw wrote:
> > CashFlowVectors---a lot of parameters now. Maybe we should pass them a
>Scheduler?
> > The same goes for SimpleSwap.
>
>Would you prefer me to keep the original constructors (before adding the
>optional parameters)?

Yes, I'd keep them for the time being. We can deprecate them in this 
release and remove them in the next one.

Bye,
         Luigi

[Quantlib-dev] RE: Latest commits

[Andre L. <An...@de...>]

Luigi,

> CashFlowVectors---a lot of parameters now. Maybe we should pass them a
Scheduler? 
> The same goes for SimpleSwap.

Would you prefer me to keep the original constructors (before adding the
optional parameters)?

Andre

Re: [Quantlib-dev] RE: Latest commits

[Luigi B. <lui...@fa...>]

Hi Andre,

At 09:24 AM 7/23/03 +0200, Andre Louw wrote:
> > b) As a matter of personal taste entirely, and therefore fully discardable
>on your part,
> > I'm not enthusiastic about Date::Date(string). I'd rather keep the class
>clear from IO (Ditto for Period.)
>
>I did this solely to make my life in SWIG easier, but I'll put my back into
>it and clean up.

We can leave the additional constructor in SWIG---it just takes to write

%extend Date {
     Date(const std::string& s, const std::string& fmt) {
         return new Date(DateParser::parse(s,fmt));
     }
}


> > c) Maybe Period::operator== should be a partial function.
>
>Not quite sure I understand what you mean?

I slipped into math talk--or maybe some other field? I meant "not defined 
upon the whole domain", since there are pairs of Periods for which it is 
ambiguous.

Bye,
         Luigi

RE: [Quantlib-dev] Latest commits

[Luigi B. <lui...@fa...>]

At 12:37 PM 7/23/03 +0200, Jens Thiel wrote:
>one idea here: implement < and > for the cases were it is well defined, and
>expand == to be "not larger and not smaller", eg.
>
>   4w<1m false
>   4w>1m false
>
>   4w==1m expands to ( !(4w<1m) && !(4w>1m) ) which is true
>
>   28d<1m        false
>   31d>1m        false
>
>   30d==1m expands to ( !(30d<1m) && !(30d>1m) ) which is true

Hmm, I still have the problem that:

Date d(23,7,2003);
Period p1(30,Days);
Period p2(4,Weeks);
Period p3(1,Months);

p1 == p3                 => true
d.plus(p1) == d.plus(p3) => false
p2 == p3                 => true
d.plus(p2) == d.plus(p3) => false

which is kind of surprising, and the additional problem that equality is 
not transitive:

30d == 1m  => true
1m == 4w   => true
30d == 4w  => false

Later,
         Luigi

[Quantlib-dev] RE: Latest commits

[Luigi B. <lui...@fa...>]

At 12:51 PM 7/23/03 +0200, Andre Louw wrote:
>Some questions on the so-called "named parameter paradigm" as per your
>comments on Scheduler.
>
>Scheduler s1 = MakeScheduler(mandatory parameters).withStubDate(d);
>Scheduler s2 = MakeScheduler(mandatory parameters).backwards();
>Scheduler s3 = MakeScheduler(mandatory
>parameters).withStubDate(d).backwards();

It would be something like:

class MakeScheduler {
   private:
     ... (mandatory parameters)
     Date stub;
     bool fromEnd;
     ... (other optional parameters)
   public:
     MakeScheduler(mandatory params) : copy mandatory parameters,
         fromEnd(false), ... {}
     MakeScheduler& withStubDate(const Date& d) { stub = d; return *this; }
     MakeScheduler& backwards() { fromEnd = true; return *this; }
     MakeScheduler& forwards() { fromEnd = false; return *this; }
     // when we're ready...
     operator Scheduler() {
         return Scheduler(mandatory params, stub, fromEnd, ...);
     }
};

i.e., no Scheduler is actually instantiated until the MakeScheduler thing 
is assigned to one.

Bye,
         Luigi

RE: [Quantlib-dev] Latest commits

[Jens T. <Je...@Th...>]

Hi there,

one idea here: implement < and > for the cases were it is well defined, =
and
expand =3D=3D to be "not larger and not smaller", eg.

  4w<1m	false
  4w>1m	false

  4w=3D=3D1m expands to ( !(4w<1m) && !(4w>1m) ) which is true

  28d<1m	false
  31d>1m	false
=20
  30d=3D=3D1m expands to ( !(30d<1m) && !(30d>1m) ) which is true

This could also be done in a Compare() function that returns either -1, =
0 or
1 to make sure that absolutely noone uses the operators carelessly.=20

Regards,

Jens.


c) Maybe Period::operator=3D=3D should be a partial function. There's a =
subset=20
of the domain where it is well defined ("1 year =3D=3D 12 months" is ok, =
and so=20
is "3 days =3D=3D 3 days" and "14 days =3D=3D 2 weeks") but how about =
"31 days =3D=3D 1=20
month"? Or "4 weeks =3D=3D 1 month"? With the current implementation, =
the first=20
is false, with the disconcerting result that if d =3D Date(22,7,2003), =
p1 !=3D=20
p2 but d.plus(p1) =3D=3D d.plus(p2). The second is true, but for most =
dates,=20
d.plus(p1) !=3D d.plus(p2). How about throwing an exception if the =
=3D=3D is=20
undecidable?

[Quantlib-dev] RE: Latest commits

[Andre L. <An...@de...>]

Luigi,

Some questions on the so-called "named parameter paradigm" as per your
comments on Scheduler.

Scheduler s1 = MakeScheduler(mandatory parameters).withStubDate(d);
Scheduler s2 = MakeScheduler(mandatory parameters).backwards();
Scheduler s3 = MakeScheduler(mandatory
parameters).withStubDate(d).backwards();

Am I correct to assume "withStubDate" would be defined something like

> Scheduler withStubDate(const Date& date) {
>	stubDate_ = date;
>	return *this;
> }

On the other hand this could erroneously be assumed to be a constructor,
which of course it isn't! Am I missing something? Also, some flag would need
to be set to force creation/recreation of the date vector?

Thanx
Andre

RE: [Quantlib-dev] Latest commits

[Andre L. <An...@de...>]

Nando,

> Andre's latest commit is the right occasion for me to urge 
> everybody to consider adding a unit test when adding new features/classes.

> It is easier done than said, and it will guarantee the author that next 
> releases will be compliant to the original test-specification.

Will do.

Andre

[Quantlib-dev] RE: Latest commits

[Andre L. <An...@de...>]

Luigi,

> a) Calendar::isLastBusinessDayOfMonth seems quite a lot of writing. How
about Calendar::isEndOfMonth?

No problem, the original reason for the long name is to clarify that it's
not just last day of month, but last _business_ day of month, but then
that's really superfluous where a calendar is concerned!

> b) As a matter of personal taste entirely, and therefore fully discardable
on your part, 
> I'm not enthusiastic about Date::Date(string). I'd rather keep the class
clear from IO (Ditto for Period.) 

I did this solely to make my life in SWIG easier, but I'll put my back into
it and clean up.

> But I can live with it.

There are many things we can live with, that does not necessarily make them
right!

> how about we implement operator>> and an IO manipulator instead, so that
one can write:
> cin >> setdateformat(fmt);
> Date d1, d2;
> cin >> d1 >> d2;

Will look into it.

> c) Maybe Period::operator== should be a partial function.

Not quite sure I understand what you mean?

> There's a subset of the domain where it is well defined ("1 year == 12
months" is ok, and so 
> is "3 days == 3 days" and "14 days == 2 weeks") but how about "31 days ==
1 month"? 
> Or "4 weeks == 1 month"? How about throwing an exception if the == is
undecidable?

Will do.

> d) Date::ascending() is none other than std::less<Date>(). In the same
way, 
> Date::descending() is std::greater<Date>() and Date::less_equal(d) is 
> std::bind2nd(std::less_equal<Date>(),d). 

Shows my lack of STL knowledge - alas, peer review is a way of learning!

> e) Scheduler. No problem per se---on the contrary, I'm grateful you
tackled 
> the thing---but it starts to have too many optional parameters. We could 
> make it a bit prettier with the named parameter idiom ...
> f) CashFlowVectors---a lot of parameters now. Maybe we should pass them a 
> Scheduler? The same goes for SimpleSwap.

OK, once again I learn...

> g) Swap::fairRate seems to work only if the first leg is the fixed one---I

> wouldn't count on that. Also, Swap is a generic swap class: one could be 
> swapping two floating legs, so that fairRate() might not make sense at
all.

Sorry, I realized this and should have removed it before I checked in. 

Thanks for your input Luigi

Re: [Quantlib-dev] Latest commits

[Luigi B. <lui...@fa...>]

At 4:27 PM +0200 7/22/03, Luigi Ballabio wrote:
>In random order:

I forgot h) please oh please, 4-spaces tabs... :)

Did we find out some way to make this comfortable for you? Maybe some 
emacs macro that makes the setting local for the buffer?

Later,
	Luigi

Re: [Quantlib-dev] Warming up (very slowly) for release?

[Dirk E. <ed...@de...>]

On Tue, Jul 22, 2003 at 05:19:30PM +0200, Luigi Ballabio wrote:
> At 09:42 AM 7/22/03 -0500, Dirk Eddelbuettel wrote:
> >I never got around to making Debian snapshots of the goldem
> >master you announced a while back, but I should be able to get back into it
> >and make releases we could throw at the build daemons.
> 
> Ok, but don't bother doing it with the tarballs I made before---I'll make 
> new next week.

Great. It is easier for me to work from tarballs. 

Dirk

-- 
Those are my principles, and if you don't like them... well, I have others.
                                                -- Groucho Marx

Re: [Quantlib-dev] Warming up (very slowly) for release?

[Luigi B. <lui...@fa...>]

At 09:42 AM 7/22/03 -0500, Dirk Eddelbuettel wrote:
>I never got around to making Debian snapshots of the goldem
>master you announced a while back, but I should be able to get back into it
>and make releases we could throw at the build daemons.

Ok, but don't bother doing it with the tarballs I made before---I'll make 
new next week.

>--
>These are my principles. If you don't like them, I have others.
>                                                 -- Groucho Marx

Ha! :) I always loved the Marx brothers. Hopefully this summer I'll have 
some time to take some dust off their vhs...

Later,
         Luigi

Re: [Quantlib-dev] Latest commits

[Ferdinando A. <fer...@am...>]

Andre's latest commit is the right occasion for me to urge everybody to 
consider adding a unit test when adding new features/classes. It is easier 
done than said, and it will guarantee the author that next releases will be 
compliant to the original test-specification.

ciao -- Nando 

Re: [Quantlib-dev] Warming up (very slowly) for release?

[Ferdinando A. <fer...@am...>]

At 09:42 AM 7/22/2003 -0500, Dirk Eddelbuettel wrote:
>Sounds good!
and if it sounds good to Dirk, it's deal done for me too. Let's see what 
"his" Debian machines will say of our next tarball...


------------
ciao -- Nando 

Re: [Quantlib-dev] Warming up (very slowly) for release?

[Dirk E. <ed...@de...>]

On Tue, Jul 22, 2003 at 04:34:49PM +0200, Luigi Ballabio wrote:
> 
> Hi all,
> 	summer vacations are upon us. However, in the light of Andre's 
> 	latest contribution and of Nando's work on low-discrepancy sequences and MC 
> engines, I think we could start planning a release. Given the season, a 
> realistic time frame could be creating the branch next week, playing with 
> it in August, and releasing in early September. The version number will be 
> a puzzling 0.3.3 since Nando and I naively created a 0.3.2 branch a few 
> weeks ago...
> 
> Thoughts?

Sounds good! I never got around to making Debian snapshots of the goldem
master you announced a while back, but I should be able to get back into it
and make releases we could throw at the build daemons.

Dirk

-- 
These are my principles. If you don't like them, I have others.
                                                -- Groucho Marx

[Quantlib-dev] Warming up (very slowly) for release?

[Luigi B. <lui...@fa...>]

Hi all,
	summer vacations are upon us. However, in the light of Andre's latest 
contribution and of Nando's work on low-discrepancy sequences and MC 
engines, I think we could start planning a release. Given the season, a 
realistic time frame could be creating the branch next week, playing with 
it in August, and releasing in early September. The version number will be 
a puzzling 0.3.3 since Nando and I naively created a 0.3.2 branch a few 
weeks ago...

Thoughts?

Later,
	Luigi

[Quantlib-dev] Latest commits

[Luigi B. <lui...@fa...>]

Andre,
	first things first: it's a great job you did on date calculations and all 
the other stuff, so kudos to you.

Secondly, I'm going to nag you just a tiny bit---feel free to come after me 
with a big clown-sized rubber hammer...

In random order:

a) Calendar::isLastBusinessDayOfMonth seems quite a lot of writing 
(although I'm sure I came up with names just as long in the past, so I 
ain't throwing the first stone here). How about Calendar::isEndOfMonth?

b) As a matter of personal taste entirely, and therefore fully discardable 
on your part, I'm not enthusiastic about Date::Date(string). I'd rather 
keep the class clear from IO (Ditto for Period.) But I can live with it.

(Aside: if the constructor was prompted by:

string s1, s2;
cin >> s1 >> s2;
Date d1(s1,fmt);
Date d2(s2,fmt);

how about we implement operator>> and an IO manipulator instead, so that 
one can write:

cin >> setdateformat(fmt);
Date d1, d2;
cin >> d1 >> d2;

In the other cases, writing "Date d = DateParser::parse(s,fmt)" hurts me 
less, but that's only me :) end of aside)

c) Maybe Period::operator== should be a partial function. There's a subset 
of the domain where it is well defined ("1 year == 12 months" is ok, and so 
is "3 days == 3 days" and "14 days == 2 weeks") but how about "31 days == 1 
month"? Or "4 weeks == 1 month"? With the current implementation, the first 
is false, with the disconcerting result that if d = Date(22,7,2003), p1 != 
p2 but d.plus(p1) == d.plus(p2). The second is true, but for most dates, 
d.plus(p1) != d.plus(p2). How about throwing an exception if the == is 
undecidable?

d) Date::ascending() is none other than std::less<Date>(). In the same way, 
Date::descending() is std::greater<Date>() and Date::less_equal(d) is 
std::bind2nd(std::less_equal<Date>(),d). If those classes are to be used 
with the STL, probably we better use their STL implementation :) Especially 
Date::less_equal might be more confusing than useful, since std::less_equal 
is a binary function. And in general, when one familiar with the STL reads 
std::less<Date>, he knows what that it. If he reads Date::ascending, he 
doesn't know. The same goes for TimeBasket::Entry.

e) Scheduler. No problem per se---on the contrary, I'm grateful you tackled 
the thing---but it starts to have too many optional parameters. We could 
make it a bit prettier with the named parameter idiom, i.e.,

Scheduler s1 = MakeScheduler(mandatory parameters).withStubDate(d);
Scheduler s2 = MakeScheduler(mandatory parameters).backwards();
Scheduler s3 =
     MakeScheduler(mandatory parameters).withStubDate(d).backwards();

f) CashFlowVectors---a lot of parameters now. Maybe we should pass them a 
Scheduler? The same goes for SimpleSwap.

g) Swap::fairRate seems to work only if the first leg is the fixed one---I 
wouldn't count on that. Also, Swap is a generic swap class: one could be 
swapping two floating legs, so that fairRate() might not make sense at all.

Thanks again,
		Luigi

[Quantlib-dev] [ quantlib-Bugs-759518 ] wrong/no longer active doc. link for needed add-in

[SourceForge.net <no...@so...>]

Bugs item #759518, was opened at 2003-06-24 00:21
Message generated for change (Comment added) made by lballabio
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=759518&group_id=12740

Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: wrong/no longer active doc. link for needed add-in

Initial Comment:
To create LaTex documentation one is directed to get:

LaTeX Fancy Header 
(http://toocool.calpoly.edu/latex/fancy_header.html)

that link does not seem to work.

----------------------------------------------------------------------

>Comment By: Luigi Ballabio (lballabio)
Date: 2003-07-08 10:32

Message:
Logged In: YES 
user_id=75450

Fixed by referring to CTAN (www.ctan.org)
Thanks


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=759518&group_id=12740

RE: [Quantlib-dev] Unresolved Externals

[Luigi B. <lui...@fa...>]

At 03:14 PM 7/2/03 +0200, Andre Louw wrote:
>Luigi wrote:
>
> > $ nm /usr/local/lib/libQuantLib.so | grep blackVarianceImpl
> > (or wherever it's installed if not /usr/local/lib) should
> > tell you whether
> > the missing external is actually defined.
>
>I am now totally confused. I have only 1 version of libQuantLib.so located
>in /usr/local/lib and it _does_ define the missing external. Sorry to be
>such a pain but I'm now stumped!

Maybe for some reason it's not finding the library altogether? Try checking 
that ld.so.conf contains an entry for /usr/local/lib (the file should be in 
/etc), run ldconfig and try again.

HTH,
         Luigi

RE: [Quantlib-dev] Unresolved Externals

[Andre L. <An...@de...>]

Luigi wrote:

> $ nm /usr/local/lib/libQuantLib.so | grep blackVarianceImpl
> (or wherever it's installed if not /usr/local/lib) should 
> tell you whether 
> the missing external is actually defined.

I am now totally confused. I have only 1 version of libQuantLib.so located
in /usr/local/lib and it _does_ define the missing external. Sorry to be
such a pain but I'm now stumped!

Andre