-
-
Notifications
You must be signed in to change notification settings - Fork 142
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 pricer adjustments #221
Conversation
…move unnecessary argument for boundary_condition_at_time_n()
Hi, is this still a work in progress? |
Hi @avhz - yes this is still a work in progress, I will push something out before the end of this week. I have made some changes to the methodology and code which I will document in this PR. |
Just checking, thanks for the update ! |
…diagonal_matrix() accordingly
… matrix and vector + amend invert_tridiagonal_matrix() to return matrix representation using only diagonal and sub/super diagonals arguments
…y_vector() and amendment in invert_tridiagonal_matrix()
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #221 +/- ##
==========================================
+ Coverage 56.09% 57.62% +1.52%
==========================================
Files 148 154 +6
Lines 4929 5170 +241
==========================================
+ Hits 2765 2979 +214
- Misses 2164 2191 +27 ☔ View full report in Codecov by Sentry. |
…t and manually add first and final entries outside loop
This branch is still a work in progress
This PR is for addressing the issues raised by @avhz in this comment - the code in question was initially merged from this PR to address issue 98.
There were some errors in implementation, namely:
(1..self.time_steps)
instead of(0..self.time_steps)
self.call_boundary(t + 1, T, delta_t) - self.call_boundary(t, T, delta_t)
when it should beself.call_boundary(t + 1, T, delta_t) + self.call_boundary(t, T, delta_t)
(same amendment made for put option boundaryAlthough the above amendments have been made, there are still issues with convergence in some places. For brevity, I have limited the cases to European call options.
The cases below were run with the following configuration:
with a distinct value for
initial_price
in each case:At the money
initial_price: 10.0
Target: 2.179260421286683
In the money
initial_price: 15.0
Target: 6.064426504411616
Out the money
initial_price: 1.0
Target: 1.0140475395001201e-6
There is some level of convergence for the at/in the money cases, although I think there is room for improvement for accuracy. Whilst experimenting with different time step sizes, it seems that there is an issue with consistency i.e.$\Delta t \rightarrow 0 \Rightarrow \text{Error}\rightarrow 0$ - this suggests there is still an issue with implementation - Note that there is convergence, but just not to the target value. The out the money case further confirms that there is something wrong.
Stability issues
It was noticed that$\Delta t$ . Hence, in the config above, I changed the time step from 1000 to 10000 (though 5000 suffices for stability).
explicit()
was blowing up in some configurations. It is likely that this indicates an issue with stability, which can be resolved by having a larger time steps, which in turn provides smaller