Posted by
Luigi Ballabio on
URL: http://quantlib.414.s1.nabble.com/calendar-advance-problem-with-Days-TimeUnit-bug-tp6531p6534.html
On Thu, 2008-08-21 at 11:29 +0000, Luca Ferraro wrote:
> <marco.tarenghi <at> bancaleonardo.com> writes:
>
> > [...] when the shift period
> > is "Days", the shift is made day by day on business days; so
> > a shift of 365Days is different from a shift of 1Year, and making a 365Days
> > shift will not take you a yera before.The same reasoning holds for forward
> > adjustment.
>
> Marco, thanks a lot for your replay.
>
> [...]If I understand well, every Period object which has a "Days" time unit behaves
> like that ... so [...] I should
> initialize the maturity period as:
>
> for (int i = 0; i < swaptionMaturityDates.size(); ++i) {
> swaptionMaturityPeriods.push_back(
> Period firstMaturity(calendar.businessDaysBetween(
> AsOfDate, swaptionMaturityDates[i]) , Days) )
> );
> }
>
> ... am I right? Is there a better way to compute periods to initialize
> CalibrationHelpers?
Luca,
yes, you're right. Unfortunately, there's no better way. We should have
used different enums for Days and BusinessDays, but I'm afraid it's a
bit late for that---we'd have to change too much code...
I'm open to suggestions if anyone comes up with an idea to bolt the
choice between calendar/business days upon the current code (in a
backward-compatible way, of course.)
Luigi
--
The economy depends about as much on economists as the weather does on
weather forecasters.
-- Jean-Paul Kauffmann
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/_______________________________________________
QuantLib-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users