Re: [QuantLib-svn] SF.net SVN: quantlib:[17105] trunk/QuantLib/ql/cashflows

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [QuantLib-svn] SF.net SVN: quantlib:[17105] trunk/QuantLib/ql/cashflows

Luigi Ballabio
On Tue, 2010-02-16 at 19:09 +0000, [hidden email] wrote:
> Revision: 17105
>           http://quantlib.svn.sourceforge.net/quantlib/?rev=17105&view=rev
> Author:   nando
> Date:     2010-02-16 19:09:58 +0000 (Tue, 16 Feb 2010)
>
> Log Message:
> -----------
> added more Coupon inspectors

We're duplicating code all over the place---they're all basically the
same loop.  Why don't you write a nextCoupon() method instead and call
whatever method you want on the result?

Luigi


--

These are my principles, and if you don't like them... Well, I have
others.
-- Groucho Marx



------------------------------------------------------------------------------
SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
http://p.sf.net/sfu/solaris-dev2dev
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev
Reply | Threaded
Open this post in threaded view
|

Re: [QuantLib-svn] SF.net SVN: quantlib:[17105] trunk/QuantLib/ql/cashflows

Ferdinando M. Ametrano-3
On Wed, Feb 17, 2010 at 10:21 AM, Luigi Ballabio
<[hidden email]> wrote:
> On Tue, 2010-02-16 at 19:09 +0000, [hidden email] wrote:
>> added more Coupon inspectors
>
> We're duplicating code all over the place---they're all basically the
> same loop.  Why don't you write a nextCoupon() method instead and call
> whatever method you want on the result?

you're right and this is true for both nextCashFlow and nextCoupon,
their "previous" variants, and their CashFlows and Bond flavors

Anyway if bond_ is a shared_ptr<Bond> you would then have to write

(*BondFunctions::nextCashFlow(*bond_))->date();

instead of

bond_->nextCashFlowDate();

You might have multiple CashFlow on the same date, so nextCashFlow
might actually aggregate flows and create a new AggregateCashFlow
instance, then returning a shared_ptr instead of an iterator. In this
case one would have to write:

BondFunctions::nextCashFlow(*bond_)->date();

As for nextCoupon it should return an instance of some AggregateCoupon
class. This class would have pointers to the Coupons to be aggregated
for its own nominal() and rate() method implementations.

What do you think about it ?

ciao -- Nando

------------------------------------------------------------------------------
SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
http://p.sf.net/sfu/solaris-dev2dev
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev
Reply | Threaded
Open this post in threaded view
|

Re: [QuantLib-svn] SF.net SVN: quantlib:[17105] trunk/QuantLib/ql/cashflows

Luigi Ballabio
On Wed, 2010-02-17 at 16:11 +0100, Ferdinando Ametrano wrote:

> On Wed, Feb 17, 2010 at 10:21 AM, Luigi Ballabio
> <[hidden email]> wrote:
> > On Tue, 2010-02-16 at 19:09 +0000, [hidden email] wrote:
> >> added more Coupon inspectors
> >
> > We're duplicating code all over the place---they're all basically the
> > same loop.  Why don't you write a nextCoupon() method instead and call
> > whatever method you want on the result?
>
> you're right and this is true for both nextCashFlow and nextCoupon,
> their "previous" variants, and their CashFlows and Bond flavors
>
> Anyway if bond_ is a shared_ptr<Bond> you would then have to write
>
> (*BondFunctions::nextCashFlow(*bond_))->date();
>
> instead of
>
> bond_->nextCashFlowDate();

Worse---You'd have to check for a null iterator first.  Ok, I can see
it's good to have the whole bunch of functions for convenience.  Plus
there's the aggregation thing.  It might still be worth to write the
common loop in a nextCoupon() method (private, if need be) so that at
least the functions returning a date can call it and remove a good part
of the duplication.  For the aggregation, I don't know.  I had though of
returning a range (begin,end) of the cashflows on the same date, but it
wouldn't work if there was a non-coupon cashflow between two coupons.
Maybe a composite, as you say.

Well, I'll let you know if I get any ideas...

Luigi


--

A programming language is low-level when its programs require attention
to the irrelevant.
-- Alan Perlis



------------------------------------------------------------------------------
SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
http://p.sf.net/sfu/solaris-dev2dev
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev