Discussion:
[Quantlib-users] Use Local Volatility in FDAmericanEngine
Jack Pai
2017-06-02 19:02:23 UTC
Permalink
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/Use-Local-Volatility-in-FDAmericanEngine-tp18328.html
Sent from the quantlib-users mailing list archive at Nabble.com.
Luigi Ballabio
2017-06-06 09:51:50 UTC
Permalink
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
Post by Jack Pai
Hi,
I'm trying to use the FDAmericanEngine in QL to price American Option with
Local Volatility.
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.
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
--
http://quantlib.10058.n7.nabble.com/Use-Local-Volatility-in-FDAmericanEngine-tp18328.html
Sent from the quantlib-users 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
_______________________________________________
QuantLib-users mailing list
https://lists.sourceforge.net/lists/listinfo/quantlib-users
Loading...