Re: today's payment (QL_TODAYS_PAYMENTS)

On Mon, 2009-04-27 at 18:00 +0200, Ferdinando Ametrano wrote:
> [...] 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
>
> 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.

Ok, I'm sold.  Thanks for making a detailed case.


> 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.

Ok, please go ahead and commit it.


> 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?

It does, but how is PaymentEvent different from the existing Cashflow
class?  Is there any payment event that is not a cash flow, or a cash
flow that is not a payment event?


> 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

It seems ok, as it complements the NPV. But I see you've committed this
already :)

Luigi


--

The box said "Use Windows 95 or better," so I got a Macintosh.



------------------------------------------------------------------------------
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image
processing features enabled. http://p.sf.net/sfu/kodak-com
_______________________________________________
QuantLib-users mailing list
QuantLib-users@...
https://lists.sourceforge.net/lists/listinfo/quantlib-users