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

[Ferdinando A. <qf...@am...>]

On Wed, Apr 8, 2009 at 10:50 AM, Luigi Ballabio
<lui...@gm...> 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