From: Ferdinando A. <na...@am...> - 2009-04-22 13:07:15
|
On Tue, Apr 21, 2009 at 3:33 PM, Luigi Ballabio <lui...@gm...> wrote: > On Mon, 2009-04-20 at 19:06 +0200, Ferdinando Ametrano wrote: >> I propose the following implementation for Event::hasOccurred: >> [...] > > I'd rather not. While this does address glitches that need to be ironed > out, it does it in a roundabout way and introduces other problems. For > instance, today's date becomes a magic date that causes an specific > behavior in hasOccurred. ok, I agree. I tried yesterday my proposal and you're right that it introduces other inconsistencies > If one were to ask > > cashflow.hasOccurred(today) > cashflow.hasOccurred(today + 1*Years) > > (both legitimate questions, not related to discounting but only to the > definition of a coupon) the cashflow will answer in an inconsistent way. mmm... I don't get this one, but I hope I'm not missing something crucial here >> This would fix all glitches I am aware of, most notably the nefarious >> discarding of upfront payments in (bond asset) swap when the term >> structure has discount = 1.0 at the upfront date, even if the upfront >> date is t+3 or t+2 from today. > > But it still wouldn't fix it if the upfront and the reference date are > at t=0. oh, but if the upfront date is at t=0 it's correct not to include it in the NPV according to the QL_TODAYS_PAYMENTS define > I sketched a solution for the upfront problem in > the previous thread that doesn't need to change hasOccurred and > therefore doesn't cause the inconsistency. I must confess your solution it's not clear to me. Anyway let's see if we agree on the following summary: 1) as far as accrued coupon (and so yield, z-spread, etc) is concerned a payment at the settlement date is never to be taken into account. This is in accord to the fact that a) at coupon payment date the accrued coupon is zero, not full coupon b) a bond cannot be traded on its maturity date. So in those relevant function hasOccurred should always be called with includeToday=false, disregarding the QL_TODAYS_PAYMENTS define 2) isExpired should call hasOccurred using the evaluation date (i.e. the session's date for "today") and respecting the QL_TODAYS_PAYMENTS define. So a bond could be not expired yet, even if on some TermStructure its NPV might be zero, because on a TermStructure with reference date equal to evaluation date its NPV could easily be non-zero. 2b) the above point relates to Instrument::isExpired. It does not concern bond tradability and clean/dirty price, which follow their own peculiar, if similar, logic 3) all cashflows at a date later than or equal to YieldTermStructure::refenceDate() should enter the NPV. The only exception is for cashflows at the evaluation date which would enter the NPV according to the QL_TODAYS_PAYMENTS define; of course this can happen only if YieldTermStructure::refenceDate() is equal to evaluation date >> With the proposed implementation QL_TODAYS_PAYMENTS would become true >> to its name: I mean, it is not QL_REFERENCE_DATE_PAYMENTS ! > > But it should really be QL_LATE_PAYMENTS. Don't chain me to my wrong > choices in naming :) if we agree to point 3 above it's really QL_TODAYS_PAYMENTS, as it only applies to the evaluation date > I suggested to add the includeToday parameter to > the npv() function so we can choose the correct behavior. sure it can be done. ciao -- Nando |