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

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

> Sorry, it breaks backwards compatibility.  We'll have to think how to go
> about this, and it's ok to leave it for the time being, but it will have to
> be reverted.

mmm... I saw this coming, but wanted to give you a chance at being
less conservative :-)

jokes aside, let me add few points to think about:

1) I broke the backward compatibility of yield/credit/inflation
traits, but is there anyone using those traits decoupled from QuantLib
iterative bootstrap? Really hard to believe.. and if such a geek
exists, please speak up now!
Anyway I could add the old signature (deprecated) methods back along
with the new overloads: this would preserve backward compatibility,
but I see little point besides obfuscating the traits usage

2) my refactored iterative bootstrap does use the new traits methods,
and so I broke any proprietary traits used for bootstrapping
proprietary curves with QuantLib iterative bootstrap. Frankly I find
hard to believe that someone able to figure out how to write new
traits would have problems moving them to their new generalized
interface. It's much more likely that such a coder would consider the
huge speedup of the bootstrap worth the few minutes needed for adding
a curve pointer in the signature

As for the benefit of this refactoring:

a) the guess change is to separate guessing from iterative
boostrapping. To fully delegate guessing to the traits improves
dramatically the readability of the iterative bootstrap. In the
previous version of iterative bootstrap the guess logic intervened
badly with the bootstrap logic.
Anyway this is mostly a cosmetic change: to revert it would just
increase the universe entropy and no more

b) the minValueAfter, maxValueAfter change is the relevant one: to
give those methods access to the full curve allows for much better
bracketing of the solution. This is crucial (even when the curve
previous state is an excellent guess) because the ineffective
bracketing is currently the major issue slowing down the bootstrap.

One final note: if we were to agree on this interface change I would
go further and add the ratehelpers in the new signatures: they might
be used to improve guess and bracketing, even if I don't plan to use
them anytime soon

What do you think about it, Luigi?
Anyone else willing to contribute his feedback?

ciao -- Nando