Posted by
Wujiang Lou on
URL: http://quantlib.414.s1.nabble.com/Finite-differencing-refactoring-tp4004p4005.html
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).