Re: Finite differencing refactoring

Posted by Joseph Wang on Aug 27, 2005; 10:12pm
URL: http://quantlib.414.s1.nabble.com/Finite-differencing-refactoring-tp4004p4008.html

What about these as design principles?

1) The pricing engine algorithm should know nothing about the instrument
it is pricing.

2) The interaction between the pricing engines and the instrument should
be mediated via the adapter pattern.

3) Control variate should be a separate class.

4) The short rate bond processes and the equities processes should come
off the same hierarchy.

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


Lou, Wujiang (FID) wrote:

>Good point.
>My solution to the same problem (narrowly 'for each option type there is
>a corresponding option engine') is to separate the pricing process into
>a modeling process and a solution process. The modeling process
>identities a set of SDEs and payoff functions, while the solution
>process solves the SDE with the payoffs. In typical equity option world,
>you'd have a diffusion SDE with option payoffs, typical solution methods
>are binomial tree, finite difference, MC, etc. The solution process does
>not see instruments; it only sees SDE and payoffs (as inputs); therefore
>you could reuse the same solution method eg finite difference scheme for
>different instruments.
>There could be a Quant object taking instrument and yielding SDE and
>payoffs; See pseudo-code below:
>
>Instrument myInstrument(...);
>(SDE, Payoffs) = Quant<Instruments>(myInstrument);
>PDESolver solver(SDE, Payoffs); //Finite difference scheme
>OptionResults myresults = solver();
>// Try MC solver. Upto this point we don't care about instrument anymore
>MCSolver mc(SDE, Payoffs);
>myresults = mc();
>
>//another instrument type, like a warrant vs option
>InstrumentDerived myInstrument2(...);
>(SDE2, Payoffs2) = Quant<InstrumentDerived>(myInstrument2);
>solver.bind(SDE2, Payoffs2); //same Finite difference scheme as above
>myresults2 = solver();
>mc.bind(SDE2, Payoffs2); //same MC solver as above
>myresults2 = mc();
>
>-----Original Message-----
>From: [hidden email]
>[mailto:[hidden email]] On Behalf Of Joseph
>Wang
>Sent: Thursday, August 25, 2005 8:29 PM
>To: [hidden email]
>Cc: [hidden email]
>Subject: [Quantlib-users] Finite differencing refactoring
>
>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.....
>
>  
>