Re: today's payment (QL_TODAYS_PAYMENTS)

On Tue, Apr 21, 2009 at 3:33 PM, Luigi Ballabio
<luigi.ballabio@...> 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

------------------------------------------------------------------------------
Stay on top of everything new and different, both inside and
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today.
Use priority code J9JMT32. http://p.sf.net/sfu/p
_______________________________________________
QuantLib-users mailing list
QuantLib-users@...
https://lists.sourceforge.net/lists/listinfo/quantlib-users