today's payment (QL_TODAYS_PAYMENTS)

[Ferdinando M. Ametrano-3]

Hi all

QL_TODAYS_PAYMENTS rules the inclusion of payments occurring "today"
in the NPV of an instrument. Today is not always the calendar's today,
and is often t+2 or t+3, according to which date your discount curve
has as origin (i.e. to which date it attaches the 1.0 discount factor)

By default PAYMENTS is undefined, so that payments occurring "today"
are not included in the NPV.

This default has a bad impact whenever you want to net the NPV by
introducing an upfront: e.g. in asset swaps the equilibrium bond price
would not zero the NPV if the yield curve you use has discount factor
= 1 at the bond settlement date (as it is natural to have).

Besides all the software systems I currently use would include such a
flow in the NPV: any flow which can be discounted by your curve (even
if with discount = 1.0) is included in the NPV

I propose to reverse the default behaviour, defining
QL_TODAYS_PAYMENTS, or even better not defining an alternative
QL_EXCLUDE_TODAYS_PAYMENTS.

Actually I would go even further and get rid of QL_TODAYS_PAYMENTS /
QL_EXCLUDE_TODAYS_PAYMENTS altogheter, assuming the rule "any flow
which can be discounted by your curve is included in the NPV" is good
enough.
The rationale is to get rid of the ambiguity the current setting
produces when associated with multiple settlement_date/curves; it's ok
to have different NPVs on curve with different settlement dates and
one knows how to adjust for it, but this is much more confusing if
there is a flow on the latest settlement date, which would be excluded
by one curve and included by the others with earlier settlement dates

any toughts?

ciao -- Nando

------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
QuantLib-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users

[Luigi Ballabio]

On Fri, 2009-03-06 at 15:05 +0100, Ferdinando Ametrano wrote:
> QL_TODAYS_PAYMENTS rules the inclusion of payments occurring "today"
> in the NPV of an instrument. Today is not always the calendar's today,
> and is often t+2 or t+3, according to which date your discount curve
> has as origin (i.e. to which date it attaches the 1.0 discount factor)

Yes. Actually, it is not even related to the discount factor; it
specifies whether Event::hasOccurred(d) includes or excludes the passed
date.


> This default has a bad impact whenever you want to net the NPV by
> introducing an upfront: e.g. in asset swaps the equilibrium bond price
> would not zero the NPV if the yield curve you use has discount factor
> = 1 at the bond settlement date (as it is natural to have).

True. An upfront, being an upfront, is supposed to be included.

But I wouldn't do it by reversing the define, because in that case the
inclusion of the upfront would only be a side effect, and not a choice
that comes from it being an upfront.  (Moreover, a user would lose the
upfront again if he decided to use the current behavior---and I would
leave him the choice to do so, even though the other behavior is good
enough for you :)

What I would do is make the behavior explicit.  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.


> Actually I would go even further and get rid of QL_TODAYS_PAYMENTS /
> QL_EXCLUDE_TODAYS_PAYMENTS altogheter, assuming the rule "any flow
> which can be discounted by your curve is included in the NPV" is good
> enough.

See above :)

> The rationale is to get rid of the ambiguity the current setting
> produces when associated with multiple settlement_date/curves; it's ok
> to have different NPVs on curve with different settlement dates and
> one knows how to adjust for it, but this is much more confusing if
> there is a flow on the latest settlement date, which would be excluded
> by one curve and included by the others with earlier settlement dates

You're not solving this by switching the behavior.  If you have curves
with settlement dates at T, T+1 and T+2,  a payment at T+1 will be
included by some and excluded by some others, regardless of the behavior
you've chosen.

Luigi


--

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



------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
QuantLib-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users

[Ferdinando M. Ametrano-3]

On Fri, Mar 6, 2009 at 4:17 PM, Luigi Ballabio <[hidden email]> wrote:
> If you have curves
> with settlement dates at T, T+1 and T+2,  a payment at T+1 will be
> included by some and excluded by some others

yes, but while I do expect the t+2 curve not to consider a cashflow at
t+1, I would expect both t and t+1 curves to take that flow into
account

> 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

In a private message Simon Ibbotson wrote to me:
> I would suggest that some sort of configuration is required for this...
>  but perhaps it is two separate configurations...
> Perhaps QL_TODAYS_PAYMENTS should apply solely to the
> Settings::evaluationDate(), not to the discounting "to" date of a
> termstructure?

I agree with his suggestion: your mileage can vary when it comes to a
flow being paid today, i.e. at 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.

ciao -- Nando

------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
QuantLib-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users

[Luigi Ballabio]

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



------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
QuantLib-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users

[Ferdinando M. Ametrano-3]

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 <[hidden email]> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users

[Luigi Ballabio]

On Mon, 2009-04-20 at 19:06 +0200, Ferdinando Ametrano wrote:

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

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.  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.
It's a minor problem compared to the upfront thing? Definitely. Can we
fix both? Yes, we can. 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.


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


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


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

Sorry, I don't to see in which way it's in the same spirit.  I'm not
saying it's not, mind you :)  But I fail to see the connection.


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

And in the same post, I suggested to add the includeToday parameter to
the npv() function so we can choose the correct behavior.


>  First it should be up to the user to remove all unwanted cashflows
> from the leg;

I beg to differ. We never ask the user to do so in any of the CashFlows
methods. And if we were to ask the user, in order to remove the unwanted
cashflows in a consistent way, he'd have to use hasOccurred. It's a
chicken and egg problem.


>  second the current CashFlows::npv, CashFlows::bps, and
> CashFlows::atmRate can deal with this requirement with the
> exDividendDays parameter;

It would be a hack.  If I want the NPV excluding today's payment, I
should be able to say so explicitly.  Using the exDividendDays would
work (in most cases: I'm pretty sure there would be corner cases that
fail) but it would not express the intent of the code as clearly.


>  third this is a minor issue compared with the discarded upfront one.

Sure, but we can fix both.

Luigi


--

Weiler's Law:
Nothing is impossible for the man who doesn't have to
do it himself.



------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users

[Ferdinando M. Ametrano-3]

On Tue, Apr 21, 2009 at 3:33 PM, Luigi Ballabio
<[hidden email]> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users

[Luigi Ballabio]

On Wed, 2009-04-22 at 15:06 +0200, Ferdinando Ametrano wrote:

> On Tue, Apr 21, 2009 at 3:33 PM, Luigi Ballabio
> <[hidden email]> wrote:
> >  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

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());

> >> 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'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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users

[Ferdinando M. Ametrano-3]

On Wed, Apr 22, 2009 at 6:17 PM, Luigi Ballabio <[hidden email]> wrote:
> 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?

yes we should not

>  Whereas if upfront date and
> reference date are both at t+2, we should?

yes we should

>  Why are the two cases different?

because 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

> 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

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.

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.
The following snippet of code is repeatedly used in the CashFlows functions:

#ifndef QL_TODAYS_PAYMENTS
if (settlementDate==Settings::instance().evaluationDate())
    includeSettlementDateFlows = false;
#endif

The above could be moved out of the cashflows.cpp into all pricing engines if it is deemed more appropriate, but I would be not in favor of this approach
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?

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

ciao -- Nando

------------------------------------------------------------------------------
Crystal Reports &#45; New Free Runtime and 30 Day Trial
Check out the new simplified licensign option that enables unlimited
royalty&#45;free distribution of the report engine for externally facing
server and web deployment.
http://p.sf.net/sfu/businessobjects
_______________________________________________
QuantLib-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users

[Luigi Ballabio]

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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users

[Ferdinando M. Ametrano-3]

On Tue, May 5, 2009 at 5:27 PM, Luigi Ballabio <[hidden email]> wrote:
> Ok, please go ahead and commit it.
done. anybody interested please review the code

>> Much better it would be to derive a PaymentEvent class from Event and
>> put that snippet into PaymentEvent::hasOccurred overload
>> [...]
>>
>> Does it make sense?
>
> It does, but how is PaymentEvent different from the existing Cashflow
> class?

you're right. I just overloaded CashFlow::hasOccurred

thank you

ciao -- Nando

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users

[Luigi Ballabio]

On Wed, 2009-05-06 at 09:25 +0200, Ferdinando Ametrano wrote:
> On Tue, May 5, 2009 at 5:27 PM, Luigi Ballabio <[hidden email]> wrote:
> > Ok, please go ahead and commit it.
> done. anybody interested please review the code

I will. But I can say right away that the FittedBondCurve example is
broken...

Luigi


--

The Feynman Problem Solving Algorithm:
1) Write down the problem.
2) Think very hard.
3) Write down the solution.



------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users

[Ferdinando M. Ametrano-3]

On Fri, May 8, 2009 at 11:13 AM, Luigi Ballabio
<[hidden email]> wrote:
> On Wed, 2009-05-06 at 09:25 +0200, Ferdinando Ametrano wrote:
>> On Tue, May 5, 2009 at 5:27 PM, Luigi Ballabio <[hidden email]> wrote:
>> > Ok, please go ahead and commit it.
>> done. anybody interested please review the code
>
> I will. But I can say right away that the FittedBondCurve example is
> broken...

the problem is that rolling the evaluation date forward in time one
bond expires. The RateHelper wrapping this bond tries to initialize
its dates and one BondFunction throws since the bond is not tradable
anymore (this is a newly added check). The date initialization happens
because of observability even if that RateHelper would not be used
anymore in following code.

This "expired rate helper" issue is a general problem, quite unrelated
to the recent Bond/BondFunction/CashFlows refactoring, and it's not
clear to me which would be the best solution... but I'm sure you have
one :-)

ciao -- Nando

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users

[Luigi Ballabio]

On Fri, 2009-05-08 at 16:04 +0200, Ferdinando Ametrano wrote:

> > I will. But I can say right away that the FittedBondCurve example is
> > broken...
>
> the problem is that rolling the evaluation date forward in time one
> bond expires. The RateHelper wrapping this bond tries to initialize
> its dates and one BondFunction throws since the bond is not tradable
> anymore (this is a newly added check). The date initialization happens
> because of observability even if that RateHelper would not be used
> anymore in following code.
>
> This "expired rate helper" issue is a general problem, quite unrelated
> to the recent Bond/BondFunction/CashFlows refactoring, and it's not
> clear to me which would be the best solution...

We should delay the exception to when the helper is actually used.
I've committed a fix for BondHelper. Is it needed for other helpers?

Luigi


--

I'd never join any club that would have the likes of me as a member.
-- Groucho Marx



------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users

[Ferdinando M. Ametrano-3]

On Wed, May 13, 2009 at 10:19 AM, Luigi Ballabio
<[hidden email]> wrote:
> We should delay the exception to when the helper is actually used.
> I've committed a fix for BondHelper. Is it needed for other helpers?

Actually I realized that BondHelper was mistakenly inherited from
RelativeDateRateHelper instead of RateHelper. Fixing this solved the
issue with no further patches needed.

To make things clearer I also templatized RelativeDateRateHelper into
a generic RelativeDateBoostrapHelper.

Now there are two open issues:
1) when the global evaluation date changes the earliestdate_ of some
BoostrapHelper derived classes (e.g. BondHelper) might be
recalculated. For all derived classes (e.g. FuturesRateHelper) it
should be verified that it's not in the past. This is not an issue for
RelativeDateBoostrapHelper
2) few (non-rate e.g. CdsHelper) helpers should derive from
RelativeDateBoostrapHelper instead of BootstrapHelper; the rest should
take care of the above issue

ciao -- Nando

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users

[japari]

Quoting Ferdinando Ametrano <[hidden email]>:

> 2) few (non-rate e.g. CdsHelper) helpers should derive from
> RelativeDateBoostrapHelper instead of BootstrapHelper; the rest should
> take care of the above issue

I'll take care of this if thats ok, I have changed those helpers in the last few
days for the new scheme (I found time now, almost there). Are all the changes
for this uploaded so I align with them?

I have to read this thread again but to make sure I understand; just resetting
Settings::instance().evaluationDate()
to a date which would set me between say my two first helpers is enough as a
test, right? That triggers recalc of all the helpers dates, etc

Also, does this affect to the calibrated models with time dependent model
parameters in the same way? I am asking this without really remembering the code
maybe is a stupid question.

Regards
pp


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users

[Luigi Ballabio]

On Wed, 2009-05-13 at 15:11 +0200, Ferdinando Ametrano wrote:
> Actually I realized that BondHelper was mistakenly inherited from
> RelativeDateRateHelper instead of RateHelper. Fixing this solved the
> issue with no further patches needed.

That's because you're not yet recalculating earliestDate_.  When you do,
the issue will be back (and so, probably, will the patch.)

Anyway: I've been going through the new code, and there are still a few
problems.  For instance, in the current implementation, if
QL_TODAYS_PAYMENTS is not defined (i.e., if you want today's payment to
go to the cash account by default) the two calls

cashFlow->hasOccurred(today, true);

and

cashFlow->hasOccurred(today, false);

return the same value (i.e., true) for a payment occurring today, even
though I'm specifying explicitly whether or not to include it.  The
define should be used when the call is

cashFlow->hasOccurred(today);

but an explicit user choice should override it.  In the same way, a call
to npv() with an explicit includeRefDatePayments = true should include
the payments even if the ref date happens to be today. This is not the
case now; the code overrides the explicit user choice. It should only
override the default choice.

Now (and with apologies to all other devs for taking this off-list---I'm
not doing it lightly, but the turnaround time for posts is really too
long for this:)  how about you come around to see the new StatPro
offices, and while you're here we sit down to try and iron out the
corner cases?

Later,
        Luigi


--

I'd never join any club that would have the likes of me as a member.
-- Groucho Marx



------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables
unlimited royalty-free distribution of the report engine
for externally facing server and web deployment.
http://p.sf.net/sfu/businessobjects
_______________________________________________
QuantLib-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users

[Luigi Ballabio]

On Wed, 2009-05-13 at 18:32 +0200, Jose Aparicio-Navarro wrote:
> Quoting Ferdinando Ametrano <[hidden email]>:
>
> > 2) few (non-rate e.g. CdsHelper) helpers should derive from
> > RelativeDateBoostrapHelper instead of BootstrapHelper; the rest should
> > take care of the above issue
>
> I'll take care of this if thats ok, I have changed those helpers in the last few
> days for the new scheme (I found time now, almost there).

Ok, please do.

> I have to read this thread again but to make sure I understand; just resetting
> Settings::instance().evaluationDate()
> to a date which would set me between say my two first helpers is enough as a
> test, right? That triggers recalc of all the helpers dates, etc

Right. Let's say you have curve A with helpers at maturities 1y, 2y, 3y,
5y and curve B with helpers at 2y, 3y, 5y (and by this I mean fixed
maturities, not maturities that move with today's date like, say, a
deposit-rate maturity.)  If you set the evaluation date at 1 and 1/2
years so that the first helper of curve A expires, you'd check that:

- just setting the evaluation date (i.e., just executing
  Settings::instance().evaluationDate() = newDate;
should _not_ throw;
- trying to use curve A afterwards _should_ throw;
- using curve B afterwards should work, of course.


> Also, does this affect to the calibrated models with time dependent model
> parameters in the same way? I am asking this without really remembering the code
> maybe is a stupid question.

Not a stupid question---in fact, a few calibrated models (for instance
the Hull-White one) has problems with a moving evaluation date.  But I
guess it's a problem for another day.

Luigi


--

The economy depends about as much on economists as the weather does on
weather forecasters.
-- Jean-Paul Kauffmann



------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables
unlimited royalty-free distribution of the report engine
for externally facing server and web deployment.
http://p.sf.net/sfu/businessobjects
_______________________________________________
QuantLib-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users