AW: [Quantlib-dev] Some issues

[Jens T. <jen...@st...>]

Luigi,

I'm applying some last minute documentation changes to QL.NET, but I have
most of the "deliverables" finished. Can you contact me two days or so
before you release 0.3.1 so I can finish the .NET release,  update the
website and send you a short "project status and description".

Regarding the term structures discussed below, I really can't see any
difference in the resulting behaviour; but maybe that is by design as long
as we have a constant spread. I'm not sure about it.

Another thing: The PieceWiseFlatForward test (or better: the equivalent .NET
test) fails on holidays (because it will lookup the fixing history for the
preceding business day); I guess the same will be true for the SWIG tests.

Jens.


>
> At 06:41 PM 12/31/02 +0100, Ferdinando Ametrano wrote:
> >Hi Jens
> >>A) Term Structures:
> >>
> >>ZeroSpreadedTermStructure and ForwardSpreadedTermStructure BOTH
> >>implement/override forwardImpl() AND zeroYieldImpl(), resulting in an
> >>identical behaviour.
>
> It is not really necessary for ZeroSpreadedTermStructure to implement
> forwardImpl(); the same goes for ForwardSpreadedTermStructure and
> zeroYieldImpl(). However, while the spread is constant it is more
> efficient
> to implement both---especially in the case of
> ForwardSpreadedTermStructure,
> since the default zeroYieldImpl(t) would perform a numerical
> integration of
> the forwards from 0 to t.
>
>
> >>   Documentation from Wellington???
> >what's the problem here?
>
> Fixed.
>
> >>Toronto:
> >>   Some forwards to Monday are not documented but implemented
> >done. I have a remaining problem with November 11th, possibly moved to
> >Monday (Remembrance Day):
> >((d == 11 || (d == 12 && w == Monday)) && m == November)
> >
> >from the above line I read that it's moved to Monday 12 if the
> 11th is on
> >Sunday, but what if the 11th is on Saturday? Shouldn't the
> Remembrance Day
> >move to Monday 13 in thus case?
> >Luigi?
>
> Yes, the above is probably wrong. However, national-holidays.com and a
> couple other sources say that the holiday doesn't move at all. Oh
> well. Fixed.
>
>
> >>B) ShortFloatingRateCoupon vs. FloatingRateCoupon
> >>Method amount(): Usage of Preceding for rolling back fixing dates is
> >>different and has changed compared to earlier CVS version.
> >I'll leave that to Luigi
>
> Oh, yes. As for the changes, there was quite a bit of confusion about
> fixing dates. I think the current version is the correct one. As for the
> difference between short and regular floating coupon, it's not
> really there
> as Preceding does nothing just as Following, and Following is the
> default.
> But you're right, I'll throw in a Preceding just for clarity.
>
> >>Sydney calendar
> >>
> >>   Documentation from Wellington???
> >>   New Years day possibly not moved?
> >>         (see http://www.national-holidays.com/)
>
> Done.
>
> Bye,
>          Luigi
>
>
>