On 02/24/05 04:27:07, Joseph Wang wrote:
> I've uploaded a new batch of pricing engines to
>
>
http://wiki.quantlib.org/twiki/bin/view/Quantlib/FiniteDifferencePricingEngines>
> These include pricing engines for multi period options. The fd pricing
> engines should now be include all of the instruments that were in the old
> code, although they do not take into account control variates, and
> testing is a bit sparse. Also, I do suspect that there are a lot of
> structural simplifications that can be made with the new pricing engines.
Thanks--I'll have a look at them when I get some time.
> Is there a general framework for getting a full set of greeks from the
> instruments? It would seem that there would be something that would see
> if the pricing engine provided the greek, and if it didn't, it could
> "wiggle" the engine to get a greek value.
I had thought of this, but in the end I decided that the user could perturb
the inputs himself to get the unsupported greeks. Doing this automatically
might be convenient at times, but in general I tend to avoid code trying to
outsmart the user. In particular, this specific trick raises problem such
as: how can the user distinguish between supported greeks and synthesised
ones? Or, in the case of synthesised greeks: how much should the code
perturb the inputs? Some users would want it to be as small as possible, to
get an estimate of the derivative (but then again, depending on the
instrument there might be numerical issues if the increments are too
small;) some others would want the greeks to be calculated over, say, one-
basis-point perturbations; some would want to use a first-order
approximation, as in (f(x+dx)-f(x))/dx, for speed; others would want a
second-order approximation, as in (f(x+dx)-f(x-dx)/(2*dx)), for accuracy...
Later,
Luigi
----------------------------------------
All generalizations are dangerous, even this one.
-- Alexandre Dumas
Locked
