Hi QuantLib's!
In the current QuantLib code the definition of the instruments include
assumptions about the future movement of the underlying. E.g. PlainOption
has volatility as a property. However, for me, the properties of the
instrument and the characteristics of the underlying seems to be seperate
issues.
Specifically, I encounter a problem, as I've implemented a pricing engine
using the closed formula from Bates (1996) (link below). However, in order
to do a full implementation, I also need to make an Instrument for a
BatesOption. This would have to include extra parameters for stochastic
volatility and jumps. But the Bates option in sé is really no different from
a plain option. It will just be priced using a different model.
Also, one could imagine other ways of pricing an option. A toolkit that I
know of defines a currency option like this:
FXOption.Strike
FXOption.Maturity
FXOption.FixingDate
FXOption.DeliveryDate
FXOption.DomesticExchange
FXOption.ForeignExchange
(and more)
and have methods:
PresentValueOnTermStructure(SpotPrice, DomesticTermStructure,
ForeignTermStructure, FXVolatility, TradeDate, SpotDate)
PresentValueOnFXCurve(DomesticTermStructure, ForwardFXRateStructure,
TradeDate)
(and more)
The second method doesn't use SpotPrice and ForeignTermStructure at all,
though in the QuantLib-setup they would be properties of the FXOption
object. Instead it uses a forward price structure.
To me it seems cleaner to seperate the properties of the "paper" option and
the parameters used to price this option. Have there been any considerations
of making the option and the pricing method seperate inside the QuantLib
library?
Best regards... Niels
Links:
http://rfs.oupjournals.org/cgi/content/abstract/9/1/69http://www.nielses.dk/quantlib/nesquant/nq/Instruments/batesoption.hpphttp://www.nielses.dk/quantlib/nesquant/nq/Pricers/batesengine.hpphttp://www.nielses.dk/quantlib/nesquant/nq/Pricers/batesengine.cpp
Locked
