Re: today's payment (QL_TODAYS_PAYMENTS)

On Fri, 2009-03-06 at 15:05 +0100, Ferdinando Ametrano wrote:
> QL_TODAYS_PAYMENTS rules the inclusion of payments occurring "today"
> in the NPV of an instrument. Today is not always the calendar's today,
> and is often t+2 or t+3, according to which date your discount curve
> has as origin (i.e. to which date it attaches the 1.0 discount factor)

Yes. Actually, it is not even related to the discount factor; it
specifies whether Event::hasOccurred(d) includes or excludes the passed
date.


> This default has a bad impact whenever you want to net the NPV by
> introducing an upfront: e.g. in asset swaps the equilibrium bond price
> would not zero the NPV if the yield curve you use has discount factor
> = 1 at the bond settlement date (as it is natural to have).

True. An upfront, being an upfront, is supposed to be included.

But I wouldn't do it by reversing the define, because in that case the
inclusion of the upfront would only be a side effect, and not a choice
that comes from it being an upfront.  (Moreover, a user would lose the
upfront again if he decided to use the current behavior---and I would
leave him the choice to do so, even though the other behavior is good
enough for you :)

What I would do is make the behavior explicit.  One way to do that is
turning Event::hasOccurred a virtual method, defining an Upfront class
derived from (Simple)CashFlow and therefore from Event, and overriding
Upfront::hasOccurred(d) so that it always includes the payment on the
given date.


> Actually I would go even further and get rid of QL_TODAYS_PAYMENTS /
> QL_EXCLUDE_TODAYS_PAYMENTS altogheter, assuming the rule "any flow
> which can be discounted by your curve is included in the NPV" is good
> enough.

See above :)

> The rationale is to get rid of the ambiguity the current setting
> produces when associated with multiple settlement_date/curves; it's ok
> to have different NPVs on curve with different settlement dates and
> one knows how to adjust for it, but this is much more confusing if
> there is a flow on the latest settlement date, which would be excluded
> by one curve and included by the others with earlier settlement dates

You're not solving this by switching the behavior.  If you have curves
with settlement dates at T, T+1 and T+2,  a payment at T+1 will be
included by some and excluded by some others, regardless of the behavior
you've chosen.

Luigi


--

Ninety percent of everything is crap.
--- Theodore Sturgeon



------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
QuantLib-users mailing list
QuantLib-users@...
https://lists.sourceforge.net/lists/listinfo/quantlib-users