« Return to Thread: today's payment (QL_TODAYS_PAYMENTS)
Re: today's payment (QL_TODAYS_PAYMENTS)
by Luigi Ballabio
::
Rate this Message:
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
QuantLib-users@...
https://lists.sourceforge.net/lists/listinfo/quantlib-users
> 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
QuantLib-users@...
https://lists.sourceforge.net/lists/listinfo/quantlib-users
« Return to Thread: today's payment (QL_TODAYS_PAYMENTS)
| Free embeddable forum powered by Nabble | Forum Help |
