

Hi,
I'm trying to use the FDAmericanEngine in QL to price American Option with Local Volatility.
I've made these steps:
1, provide local volatility. GeneralizedBlackScholesProcess already provides an implementation for local vol, I overwrote this with my own. This is not my question ( FYI, I've changed FDAmericanEngine to take a StochasticProcess1D instead of GeneralizedBlackScholesProcess, and my own LocalVolatilityProcess is a subclass of StochasticProcessID and implements the diffusion by returning local volatility that I provide)
2, create FDAmericanEngine with last argument timeDependent set to true. This will allow the engine to update the Operator on every single step with the diffusion provided by my LocalVolatilityProcess.
That's the key changes I made. Now the FDAmericanEngine will get local volatility based on time and underlying price in every step to generate Operator.
My question:
1, I noticed that at the end of the FDStepConditionEngine.hpp, the calculate() method, it use the FD Engine to get both American (or any Exotic) and European (the Control set) option value. Then, it gets the difference between the American and European, and apply the difference to the Analytical BlackCalculator result for European Option. So it is taking the Black Analytical results as the base, and adding only the difference from the FD Engine. Why not use the FD Engine result for the American (Exotic) Option directly? Current implementation still depends on Black Vol. If user only has Local Vol, FDAmericanEngine won't be able to calculate option value at all.
2, I tried to use the value from the FDStepConditionEngine calculate() directly, without going through the BlackCalculator at all. In other words, I take the FD Model output directly, after rollback to T0, without going through the subtract Control value (FD European value) and add BlackCalculator value. I compared the FDStepConditionEngine value to the BlackCalculator value for European Option, the difference is quite big, can be up to 10%. I'm wondering, if the FD step engine was known for big error? Is that why it uses Black Analytical calculator as the base for results?
Thanks


Hi Jack, as far as I know, the reason we're adding the FD European value and subtracting the analytic one is to cancel possible biases due to the use of FD. The reasoning goes: let's suppose that FD introduces some kind of numerical bias. In that case, using the FD result directly would give you the real price plus an error. If you price both American and European option and subtract the values, the bias should partially cancel out and you should get the unbiased (or less biased) value of a portfolio long the American and short the European. At this point, if you add the analytic exact value of the European, you'll get an unbiased value for the American option.
About your second question: I'm not sure I got it. The way I read it, you're reading the value of the American option directly from the FD model (without going through the above) and comparing it to the value of the European option. They should be the same only for a call with no dividend yield, otherwise it's apples and oranges. Am I misreading it? If you're indeed comparing similar values, you might try to reduce the FD step in order to increase the accuracy and see if the two values get closer.
Luigi
Hi,
I'm trying to use the FDAmericanEngine in QL to price American Option with
Local Volatility.
I've made these steps:
1, provide local volatility. GeneralizedBlackScholesProcess already provides
an implementation for local vol, I overwrote this with my own. This is not
my question ( FYI, I've changed FDAmericanEngine to take a
StochasticProcess1D instead of GeneralizedBlackScholesProcess, and my own
LocalVolatilityProcess is a subclass of StochasticProcessID and implements
the diffusion by returning local volatility that I provide)
2, create FDAmericanEngine with last argument timeDependent set to true.
This will allow the engine to update the Operator on every single step with
the diffusion provided by my LocalVolatilityProcess.
That's the key changes I made. Now the FDAmericanEngine will get local
volatility based on time and underlying price in every step to generate
Operator.
My question:
1, I noticed that at the end of the FDStepConditionEngine.hpp, the
calculate() method, it use the FD Engine to get both American (or any
Exotic) and European (the Control set) option value. Then, it gets the
difference between the American and European, and apply the difference to
the Analytical BlackCalculator result for European Option. So it is taking
the Black Analytical results as the base, and adding only the difference
from the FD Engine. Why not use the FD Engine result for the American
(Exotic) Option directly? Current implementation still depends on Black Vol.
If user only has Local Vol, FDAmericanEngine won't be able to calculate
option value at all.
2, I tried to use the value from the FDStepConditionEngine calculate()
directly, without going through the BlackCalculator at all. In other words,
I take the FD Model output directly, after rollback to T0, without going
through the subtract Control value (FD European value) and add
BlackCalculator value. I compared the FDStepConditionEngine value to the
BlackCalculator value for European Option, the difference is quite big, can
be up to 10%. I'm wondering, if the FD step engine was known for big error?
Is that why it uses Black Analytical calculator as the base for results?
Thanks

View this message in context: http://quantlib.10058.n7.nabble.com/UseLocalVolatilityinFDAmericanEnginetp18328.html
Sent from the quantlibusers mailing list archive at Nabble.com.

Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
QuantLibusers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlibusers

Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________
QuantLibusers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlibusers

