Posted by
Wujiang Lou on
URL: http://quantlib.414.s1.nabble.com/Multi-asset-options-tp2771p2781.html
Hi,
The benefit of a more sophisticated Payoff class is that it allows pricing to
be decomposed into modeling phase and computing phase. By modeling I mean the
things quant does to arrive at model dynamics (SDE) and economics (cashflow,
payoff etc.) while computing is simply a numerical/analytical procedure to
solve the SDE, whether closed form, finite difference, MC, lattice, etc.
In the asian option example Luigi mentioned, the MC method is modeling asset
price as a SDE while the analytic formula the avearged asset price
approximately. You see here the modeling phase one comes out different SDEs.
The real advantage of such a separation is, as soon as you've arrived your
SDE and payoffs, existing solutions / tools may be reused to compute it.
Black-Scholes formula for example can be used without modification and you
don't need to write a AsianOptionBlackScholesPricer. In fact, all your 1-D
trees, 1-D finite differences work as well, in a similar manner to plug-n-play.
With this design I can see the number of Pricers in quantlib can be
significantly reduced without lossing any pricing capability. (That was the
exact reason I came across this design in my earlier job. Jus t name this:
OptBSPricer, OptBinTreePricer, OptFDPricer; QuantoBSPricer,
QuantoBinTreePricer, QuantoFDPricer; ... repeat that list with CompositeOpt,
FuturesOpt, DigitalOpt, ... Eventually the list of pricers grows
unmanageably.)
I think we're already seeing the list grow a lot in QuantLib. May be a good
time to revisit it a little bit.
Best,
-Wujiang
Ferdinando Ametrano wrote:
> Hi Wujiang
>
> >template<class D, int N>
> >class Payoff
> >{
> >public:
> > virtual ~Payoff() {}
> > virtual double operator()(D t, const State<N> & s) const = 0;
> > virtual double operator()(D t, const Path<D, N>& p) const = 0;
>
> in the current QuantLib design Payoff just encapsulate max(S-K, 0),
> max(K-S,0), etc
> The operator()(D t, const Path<D, N>& p) is similar to the PathPricer
> interface double operator()(Path), and I wouldn't favour the mixing of the
> payoff/pathpricer concept until I understand which benefit we would obtain.
>
> In the current framework a PathPricer takes care to calculate for each Path
> (single or multi-asset) the double referenceValue that Payoff::operator()
> requires as input
>
> ciao -- Nando
>
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
>
http://www.eclipsecon.org/osdn> _______________________________________________
> 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 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. You should not use email 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 email 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).