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

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

On Wed, 2007-04-18 at 18:31 +0200, Ferdinando Ametrano wrote:
> I've created the folder structure that I feel will be ok for proper
> categorization of all evolvers we're going to develop and which will
> be much more than the current 7.

Assuming that categorization should be done by means of the folder
structure and not, say, by documentation. I'm not opposing it, I'm just
pointing out it's an assumption. You know I'm picky...

> The possible evolvers I would like to see in QuantLib are about 6 (pc,
> ipc, euler, capc, cani, and PPR terminal measure) for each of the 6
> dynamics (log-normal cot swap rate, log-normal cm swap rate,
> log-normal fwd rate, normal cot swap rate, normal cm swap rate, normal
> fwd rate)

I confess my ignorance here (it's a while since I looked at the
evolvers, and some I haven't seen yet) but can't the 6 evolvers and the
6 dynamics be made orthogonal? Do we really need 36 distinct classes?

> As a matter of fact the folder reorganization was just the step before
> asking for volunteers to implement the next batch of 6 evolvers: ipc
> and euler for log-normal coterminal, log-normal constant maturity swap
> rates, and normal fwd rates. The task is not hard and given the
> current 7 evolvers is mostly copy/paste/adapt (and hopefully test).

Coding these 6 might be ok, but once we get to 13 (or maybe sooner than
that) it might be worthwhile to step back and look at the differences
between the various evolvers to see if anything can be abstracted (and
since the task is mostly copy/paste/adapt, there should be plenty.) In
an ideal world, we might be able to declare specific evolvers as
   Evolver<NormalFwd,IPC>
which would remove the need for categorization altogether.

However, since we're about to branch for the next release and any
further work on the evolvers will likely be done afterwards, do you have
anything against my _temporarily_ reverting the folder structure for
such release?

> Any volunteer would get a lot of credit for not so much work ;-) and
> it would be a good chance to get familiar with the current code base.

True. People, please give a though to this request.

Later,
	Luigi


---------------------------------------- 

Steinbach's Guideline for Systems Programming: 
Never test for an error condition you don't know how to handle.