Re: today's payment (QL_TODAYS_PAYMENTS)

On Wed, 2009-04-22 at 15:06 +0200, Ferdinando Ametrano wrote:
You're right, I was too short. Nothing crucial, I just meant that if you
wrote:

SimpleCashFlow cf1(today, 100.0);
SimpleCashFlow cf2(today + 1*Years, 100.0);

cf1.hasOccurred(today);
cf2.hasOccurred(today+1*Years);

the two hasOccurred calls would return different values---surprisingly,
as they could be written as

cf1.hasOccurred(cf1.date());
cf2.hasOccurred(cf2.date());


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?  Whereas if upfront date and
reference date are both at t+2, we should?  Why are the two cases
different?  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 (provided, of course, that it's not strictly
before the reference date.)


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

To declare upfronts, use a specific Upfront class derived from CashFlow.
Upfront::hasOccurred() overrides the default behavior and ignores the
define so that the upfront is included in the NPV. Something like

bool Upfront::hasOccurred(Date d, bool) {
    // forward to base class, but includeToday = true
    return CashFlow::hasOccurred(d, true);
}


> 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

Ok. I guess this should be done in BondFunctions, correct?


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

Ok.


> 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

Which is the logic of point 1), right?


> 3) all cashflows at a date later than or equal to
> YieldTermStructure::refenceDate() should enter the NPV.

According to QL_FUNKY_PAYMENTS or whatever it's called. No?

> 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

Hmm. Again, why a payment at t+0 with a reference date at t+0 should
behave differently than a payment at t+2 with a reference date at t+2?


Also, 4): Specific functions might follow their own logic. For instance,
CashFlows::atmRate() should probably call npv() and bps() with
includeToday = false.

Luigi

P.S. We'd also have to think about which default behavior we want. Do we
keep the current default, or do we change it? (After we get the right
logic for atm rates etc., of course.)


--

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



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