Finite differencing refactoring

[Joseph Wang]

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

[Wujiang Lou]

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





-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle
Practices Agile & Plan-Driven Development * Managing Projects & Teams *
Testing & QA Security * Process Improvement & Measurement *
http://www.sqe.com/bsce5sf
_______________________________________________
Quantlib-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users
--------------------------------------------------------

This is not an offer (or solicitation of an offer) to buy/sell the securities/instruments mentioned or an official confirmation.  Morgan Stanley may deal as principal in or own or act as market maker for securities/instruments mentioned or may advise the issuers.  This is not research and is not from MS Research but it may refer to a research analyst/research report.  Unless indicated, these views are the author's and may differ from those of Morgan Stanley research or others in the Firm.  We do not represent this is accurate or complete and we may not update this.  Past performance is not indicative of future returns.  For additional information, research reports and important disclosures, contact me or see https://secure.ms.com/servlet/cls.  You should not use e-mail to request, authorize or effect the purchase or sale of any security or instrument, to send transfer instructions, or to effect any other transactions.  We cannot guarantee that any such requests received via e-mail will be processed in a timely manner.  This communication is solely for the addressee(s) and may contain confidential information.  We do not waive confidentiality by mistransmission.  Contact me if you do not wish to receive these communications.  In the UK, this communication is directed in the UK to those persons who are market counterparties or intermediate customers (as defined in the UK Financial Services Authority's rules).

[Joseph Wang]

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

[Dmitry Goryunov]

Hi,
I am trying to build QuantlibXl. Unfortunately neither in the release
(0.3.13) nor in CVS I can find fle marketmodels.cpp . How do I get this
one?
Thanks, Dmitry

--

[Ferdinando M. Ametrano-3]

Hi Dmitry,

Market Model stuff have not been released in 0.3.13, and should not be
needed to build 0.3.13.

As for the current cvs: marketmodels.cpp in QuantLibXL is an
autogenerated file, so you need to use gensrc. Check the
QuantLibAddin.sln solution.

ciao -- Nando

On 8/24/06, Dmitry Goryunov <[hidden email]> wrote:

> Hi,
> I am trying to build QuantlibXl. Unfortunately neither in the release
> (0.3.13) nor in CVS I can find fle marketmodels.cpp . How do I get this
> one?
> Thanks, Dmitry
>
> --
>
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> QuantLib-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>