Re: today's payment (QL_TODAYS_PAYMENTS)

Hi all

sorry for resurrecting this old quantlib-users thread (and hi-jacking it to quantlib-dev) but I need to iron out few remaining idiosyncratic glitches for the job I'm doing.

I propose the following implementation for Event::hasOccurred:

bool Event::hasOccurred(const Date& d,
                        bool includeToday) const {
    Date todaysDate = Settings::instance().evaluationDate();
    if (d==Date() || d==todaysDate) {
        if (includeToday)
            return date() < todaysDate;
        else
            return date() <= todaysDate;
    }
    return date() < d;
}

following Simon's suggestion that
> QL_TODAYS_PAYMENTS should apply solely to the Settings::evaluationDate(),
> not to the discounting "to" date of a termstructure

With the proposed implementation QL_TODAYS_PAYMENTS would become true to its name: I mean, it is not QL_REFERENCE_DATE_PAYMENTS !

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.

This would also be in the same spirit of considering an Instrument expired if all its cashflows have occurred by today, and not by the term structure reference date.

Luigi has pointed out this would conflict with the calculation of forward atm rate of a seasoned leg, where you do not want to take into account any cashflow paid at the forward date. First it should be up to the user to remove all unwanted cashflows from the leg; second the current CashFlows::npv, CashFlows::bps, and CashFlows::atmRate can deal with this requirement with the exDividendDays parameter; third this is a minor issue compared with the discarded upfront one.

On a related issue I would also add valuationDate along with value and errorEstimate in Instruments::results. It would be initialized as Null<Date>, but any nice engine could set it equal to the referenceDate of the relevant term structure(s)

ciao -- Nando


On Mon, Mar 9, 2009 at 5:01 PM, Luigi Ballabio <luigi.ballabio@...> wrote:
> On Fri, 2009-03-06 at 18:10 +0100, Ferdinando Ametrano wrote:
>> > One way to do that is
>> > turning Event::hasOccurred a virtual method, defining an Upfront class
>> > derived from (Simple)CashFlow and therefore from Event, and overriding
>> > Upfront::hasOccurred(d) so that it always includes the payment on the
>> > given date.
>>
>> mmm... I might be missing something but this sound very convoluted to me
>
> It might take more coding, but it's explicit.  This way, the behavior of
> an upfront payment is made explicit in its class, instead of relying on
> the fact that some other global variable is set "correctly."  After
> this, we may or may not include today's payments (I'm not opposed to
> changing the default---we're using the other behavior ourselves here at
> StatPro---I'm just opposed to removing the choice) but the upfront
> remains included; because it's an upfront, not because of a hack
> somewhere else.
>
>
>> I agree with [Simon Ibbotson's] suggestion: your mileage can vary when
>> it comes to a flow being paid today, i.e. a
>> Settings::evaluationDate(), because of different accounting
>> approaches, but it makes no sense at all (at least to me ;-) to
>> discard a flow just because it's on a termstructure settlement date.
>
> It might not even be the settlement date of a term structure. For
> instance, you might want to calculate the NPV of the two legs of a swap
> at a future date d in order to compare them and calculate its forward
> ATM rate.  In that case, you only want the future cash flows and discard
> those at d, if any.
>
> I guess what I'm saying is that we should leave the choice, and possibly
> increase the places where we make an explicit one (e.g. by using the
> optional includeToday argument in Event::hasOccurred, and possibly
> adding such an argument to CashFlows::npv.)  Upfront? always include.
> Forward swap rate? always exclude.
>
> Luigi
>
>
> --
>
> Of course, if people could just act consistently, they could keep
> their desks clean, avoid cavities, lose weight, give up smoking,
> play a musical instrument, and possibly even produce software on
> a regular and timely basis.
> -- Alistair Cockburn
>
>
>


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