[Quantlib-dev] Finite differencing refactoring

[Joseph W. <jo...@co...>]

One thing that's always bothered me about the way that the finite 
difference classes are structured is that for each option type there is 
a corresponding option engine, and there should be an automatic way of 
associating an instrument with an engine.

I was wondering if using a policy template class would do this.  The 
pseudo-code would like something like

PricingEngine *pe = FiniteDifferenceEngineFactor<OptionType>;

which would and the association between option type and which difference 
engine to use would be in the code rather than requiring the user to 
include it by hand.  The other refactoring would be to add in features 
such as step function conditions and multi-period conditions as 
templated add-ins rather than using subclassing as is currently done.

One final thing is that I've noticed that the general scheme people use 
to finite difference is

stochastic process -> PDE -> difference equation

There isn't any reason that I can see that for Markovian processes you 
can't go directly from the stochastic process to the difference 
equation.  What this would mean for quantlib is to create new processes 
that for example represent one factor short rate models, and then 
extending the finite difference engines so that they can handle 
processes other than Black-Scholes.  This wouldn't work for the general 
HJM model, but it would for one-factor short rate models, right?

Thoughts?

---------------------
Dr. Joseph Wang
Currently looking for Greater China related quant work.....