Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Finite Difference Engine for Option under CoxIngersollRoss Short Rate Process #824

Merged
merged 6 commits into from
May 30, 2020

Conversation

w31ha0
Copy link
Contributor

@w31ha0 w31ha0 commented May 27, 2020

The short rate for a CoxIngersollRoss process can be described by the following SDE

cir

By following the methodology described here http://scriptiesonline.uba.uva.nl/document/656101, using Ito's Lemma and riskless portfolio, the PDE for an option under CIR short rate can be derived as

pde1

By doing a change of variables for X=lnS, the PDE becomes

pde2

A test has been added to show that the value converges between multiple evolver schemes.

Also, as the sigma for the underlying black scholes process can only be determined during setTime(t1, t2), I needed a way to update the coefficients in the ninepointlinearop(equivalent to the apxb in triplebandlinearop) so i created a reset method for that but I'm open to better ways of doing that instead.

void FdmCIRMixedPart::setTime(Time t1, Time t2) {
const Real v = std::sqrt(sigma1_->blackForwardVariance(t1, t2, strike_)/(t2-t1));
const NinePointLinearOp op(dyMap_.mult(Array(mesher_->layout()->size(), v)));//TODO fix this
mapT_.reset(op);
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since you're about to throw op away at the end of this method, you can write mapT_.swap(op). This removes the need for the reset method.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks. I'm now getting a n error

unknown location(0): fatal error: in "QuantLib test suite/Finite Difference CIR tests/QuantLib__detail__quantlib_test_case(&FdCIRTest__testFdmCIRConvergence)": std::runtime_error: Boost assertion failed: buckets_

How do I fix this? I don't get the same error when I tried running locally.

@lballabio
Copy link
Owner

I can't reproduce it either, but according to the Travis builds it's a memory access violation. Maybe an array access out of bounds somewhere? (On our machines it might just read uninitialized memory without complaining.)

Initial Commit

Cleanup code

Add delta,gamma,theta calculations

Fix build

Remove unused variables

Remove unused variables

Reorder variables

fix build

fix build

Fix mispell

Fix stuff

test fix
@lballabio
Copy link
Owner

Not sure if it can help, but configuring with --enable-extra-safety-checks adds some access checking to arrays and matrices and might trigger the error locally so you can debug it. (If you're on Windows instead, you can enable the corresponding #define in ql/userconfig.hpp.)

@w31ha0
Copy link
Contributor Author

w31ha0 commented May 30, 2020

--enable-extra-safety-checks

I tried doing a ./configure --enable-extra-safety-checks, make, make install and then run the test locally using CMake build but it still doesn't throw the error.

Is this the right way to do it to get the CMake build to pick up the flag? Or should i set that option somewhere else for CMake?

@lballabio
Copy link
Owner

Not sure if CMake can pick it up. Passing an additional define (-DDEBUG) in the compiler option might do the trick, but I tried a debug build in a Windows virtual machine (which enables the extra checks) and the test succeeded. Now I'm compiling your branch in the same Docker image used on Travis and hoping I can diagnose the problem in there...

@lballabio
Copy link
Owner

I should have found the problem. The engine stored the underlying processes by reference, and sometimes they ended up dangling. I've pushed a fix.

@coveralls
Copy link

Coverage Status

Coverage increased (+0.04%) to 71.062% when pulling 23907f1 on w31ha0:fd-cir-engine2 into 4df35a9 on lballabio:master.

@w31ha0
Copy link
Contributor Author

w31ha0 commented May 30, 2020

I should have found the problem. The engine stored the underlying processes by reference, and sometimes they ended up dangling. I've pushed a fix.

Thanks!

@lballabio lballabio merged commit f56c717 into lballabio:master May 30, 2020
@lballabio lballabio added this to the 1.19 release milestone May 30, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants