Re: today's payment (QL_TODAYS_PAYMENTS)

On Wed, Apr 22, 2009 at 6:17 PM, Luigi Ballabio <luigi.ballabio@...> wrote:
> I'm confused.  If the upfront date is at t+0 and the reference date is
> at t+0 too, we shouldn't include it?

yes we should not

>  Whereas if upfront date and
> reference date are both at t+2, we should?

yes we should

>  Why are the two cases different?

because your term structure reference date has no relevance in real "accounting" world, whereas if a cashflow is due today this is relevant since it might belong to the NPV or the cash account. Usually it belongs to the cash account because it does not need to be hedged, i.e. it has no sensitivity to whatever term structure you might use

> Forget that the macro is called QL_TODAYS_PAYMENTS, call it
> QL_FUNKY_PAYMENTS if you want.  I though that the desired behavior was
> that, if an upfront is specified, it should override the define and be
> included no matter what

from day one I've always assumed the desired behavior was to discriminate if today's cashflows belong to NPV or cash account. So it was properly named.

I've finally nailed down a coherent implementation where all CashFlows functions are fully parametrized with explicit includeSettlementDateFlows, BondFunctions forward to CashFlows functions setting includeSettlementDateFlows equal to false.
The following snippet of code is repeatedly used in the CashFlows functions:

#ifndef QL_TODAYS_PAYMENTS
if (settlementDate==Settings::instance().evaluationDate())
    includeSettlementDateFlows = false;
#endif

The above could be moved out of the cashflows.cpp into all pricing engines if it is deemed more appropriate, but I would be not in favor of this approach
Much better it would be to derive a PaymentEvent class from Event and put that snippet into PaymentEvent::hasOccurred overload: it now occurs to me that QL_TODAYS_PAYMENTS does not belong to Event at all if you consider that in the future we might have more events which are not paymente events, e.g. the option exercise event, the default event, etc. These events are not related with QL_TODAYS_PAYMENTS

Does it make sense?

The next step for which I would love to get some feedback too is that I would add valuationDate to value and errorEstimate in Instrument::Results, so that compliant engines might use it to store the NPV date

ciao -- Nando

------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensign option that enables unlimited
royalty-free distribution of the report engine for externally facing
server and web deployment.
http://p.sf.net/sfu/businessobjects
_______________________________________________
QuantLib-users mailing list
QuantLib-users@...
https://lists.sourceforge.net/lists/listinfo/quantlib-users