Re: [QuantLib-svn] SF.net SVN: quantlib:[16114] trunk/QuantLib

[Luigi Ballabio]

Hi all,
        about yesterday's flurry of commits:


> Revision: 16114
>
> Log Message:
> -----------
> improved z-spread calculation and removed redundant dirty-price based interface

Sure it was redundant, but:
1) it's convenient;
2) it's inexpensive to maintain;
3) as it's defined as a set of free-standing functions, we're not adding
excess baggage to a class interface.
In short, I'd restore the dirty-price functions since I don't see any
disadvantage in them.


> Revision: 16116
>
> Log Message:
> -----------
> moved yield calculation in its own file (as for the z-spread
> calculation)

> Revision: 16120
>
> Log Message:
> -----------
> removed redundant Bond methods

Previously, I had kept the yield calculations in Bond because I felt
that they were used as much as, say, theoretical-price calculations, so
they deserved to be methods in Bond.  On the other hand, I see that it's
convenient to have the calculations in a separate file.  How about we
make a compromise and keep the methods in Bond forwarding to the
external functions?

Luigi


--

Everything can be filed under "miscellaneous".
-- unknown



------------------------------------------------------------------------------
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev

[Ferdinando Ametrano-4]

On Wed, Apr 8, 2009 at 10:50 AM, Luigi Ballabio
<[hidden email]> wrote:
>> [...] removed redundant dirty-price based interface
> Sure it was redundant, but:
> 1) it's convenient;
> 2) it's inexpensive to maintain;
> 3) as it's defined as a set of free-standing functions, we're not adding
> excess baggage to a class interface.
> In short, I'd restore the dirty-price functions since I don't see any
> disadvantage in them.

I've never used the dirty-price yield/z-spread functions, as the
market standard for prices is clean price, so in order to use the
dirty price as input the user must have gone through the unnecessary
step of adding accrued amount to clean price. The only occasion I had
to deal with a dirty-price function was when a trader started using it
at a time when the accrual of the bond he was interested into was
little enough not to notice the mistake. We then noticed 3 months
later...

Dirty price is usually only used for internal calculations, so my
advice is not to restore those functions, unless some real benefit is
pointed out. Of course I'm not against it, especially as long as I
manage the Excel interface from which they have been eradicated :-)

I would be even more radical and remove the Bond::dirtyPrice() method,
more on this below

>> Revision: 16116
>>
>> Log Message:
>> -----------
>> moved yield calculation in its own file (as for the z-spread
>> calculation)
>
>> Revision: 16120
>>
>> Log Message:
>> -----------
>> removed redundant Bond methods
>
> Previously, I had kept the yield calculations in Bond because I felt
> that they were used as much as, say, theoretical-price calculations, so
> they deserved to be methods in Bond.  On the other hand, I see that it's
> convenient to have the calculations in a separate file.  How about we
> make a compromise and keep the methods in Bond forwarding to the
> external functions?

I intentionally committed with high granularity to facilitate code
inspection and to ease change reverting. I paid special attention
notably for Rev16120, and in previous revisions I already provided the
Bond methods forwarding to external functions.
So I'm not against restoring them

Anyway my 0.02€ would be for not adding them back to the Bond
interface, seconding Scott Meyer's advice of preferring friend
functions instead of class members, and keep the class interface free
of baggage.
Besides any special role for yield vs z-spread (and maybe in the
future OASpread) doesn't win me over.

I would be even more aggressive, and limit the Bond interface to the
implementation of the Instrument interface + inspectors. Any
additional "theorical-price" (clean/dirty) could be delegated to the
DiscountingBondEngine. But I do understand that conservative minds
might be against such a change :-) especially since we're approaching
1.0

ciao -- Nando

------------------------------------------------------------------------------
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev

[Luigi Ballabio]

On Wed, 2009-04-08 at 12:39 +0200, Ferdinando Ametrano wrote:
> I've never used the dirty-price yield/z-spread functions, as the
> market standard for prices is clean price [...]
>
> [...] so my
> advice is not to restore those functions, unless some real benefit is
> pointed out. Of course I'm not against it, especially as long as I
> manage the Excel interface from which they have been eradicated :-)

Fair enough.


> I would be even more radical and remove the Bond::dirtyPrice() method

You mean in the Excel interface, right? :)

> > Previously, I had kept the yield calculations in Bond because I felt
> > that they were used as much as, say, theoretical-price calculations, so
> > they deserved to be methods in Bond.
>
> in previous revisions I already provided the
> Bond methods forwarding to external functions.
> So I'm not against restoring them
>
> Anyway my 0.02€ would be for not adding them back to the Bond
> interface, seconding Scott Meyer's advice of preferring friend
> functions instead of class members, and keep the class interface free
> of baggage.

Meyers argues against member functions that access the private data
members---and it does so in order to improve encapsulation. Here, the
methods would just be forwarding calls to non-friend functions, thus
they would not decrease encapsulation.


> Besides any special role for yield vs z-spread (and maybe in the
> future OASpread) doesn't win me over.

For one thing, the yield is intrinsic to the bond, while the z-spread is
based on an external discount curve.  Second, come on---the yield is
much more used; one's just as likely to look at the yield as to look at
the price, when choosing what bonds to buy.  You can say that it's just
another calculation, but not in the real world.


> I would be even more aggressive, and limit the Bond interface to the
> implementation of the Instrument interface + inspectors. Any
> additional "theorical-price" (clean/dirty) could be delegated to the
> DiscountingBondEngine.

And then the users should retrieve the results as

bond->result<Rate>("cleanPrice");

instead of

bond->cleanPrice();

after which I couldn't blame them if they forked the project :)

Luigi


--

Better to remain silent and be thought a fool than to speak out and
remove all doubt.
-- Abraham Lincoln



------------------------------------------------------------------------------
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev

[Bojan Nikolic]

I think the removal of the yield member function from the Bond class
has broken the current version of Examples/Bonds/Bonds.cpp. Not sure
what the conclusions of the discussion are: are you reverting them in
or should we fix the example?

Best,
Bojan

--
Bojan Nikolic          ||          http://www.bnikolic.co.uk

------------------------------------------------------------------------------
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev

[Ferdinando Ametrano-4]

On Thu, Apr 9, 2009 at 1:25 PM, Bojan Nikolic <[hidden email]> wrote:
> I think the removal of the yield member function from the Bond class
> has broken the current version of Examples/Bonds/Bonds.cpp. Not sure
> what the conclusions of the discussion are: are you reverting them in
> or should we fix the example?

as per Luigi's request I will add back the yield members functions.
I'll also take care of any residual change to be applied to the
example.

thank you

ciao -- Nando

------------------------------------------------------------------------------
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev