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