Posted by
Luigi Ballabio on
URL: http://quantlib.414.s1.nabble.com/Re-QuantLib-svn-SF-net-SVN-quantlib-16114-trunk-QuantLib-tp12686p12688.html
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