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

[Luigi B. <lui...@gm...>]

On Thu, 2011-06-30 at 11:11 +0200, Ferdinando Ametrano wrote:
> > 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 :-)

Ok.  Since there's little chance of anybody having written any code that
might break, go ahead; but please write a short how-to in the News.txt
file explaining how to change one's own traits and bootstrap.

Ciao,
	Luigi


> 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

-- 

Can't act. Slightly bald. Also dances. 
-- RKO executive, reacting to Fred Astaire's screen test. 
Cerf/Navasky, "The Experts Speak"