Login  Register

RE: Latest commits

Posted by Andre Louw-2 on Jul 23, 2003; 1:12am
URL: http://quantlib.414.s1.nabble.com/Latest-commits-tp10269p10274.html

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