|
|
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.....
|
Locked
