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