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.

Sign up for GitHub

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

Jump to bottom

Major implementation change for ibor_swap? A notebook example doesn't tie out anymore. #188

Closed
YimingZhang07 opened this issue Jul 6, 2023 · 12 comments
Closed

Major implementation change for ibor_swap? A notebook example doesn't tie out anymore. #188

YimingZhang07 opened this issue Jul 6, 2023 · 12 comments

Comments

@YimingZhang07
Copy link

Hello,

I looked at the ibor_swap implementation. And noticed an example in FINIBORSWAP_ComparisonWithQLExample.ipynb, which I believe was trying to convince the results tie to the Quant Lib implementation.

This notebook ran with version 0.184, and the results matched perfectly. However, with the latest version, the difference enlarged significantly.

The fixed leg has no problem. The floating leg was 2292441.20, but now it turns to be 2318923.97 mainly due to the change in rate calculations on index curve. The change seems nontrivial.

I am not sure if this notebook should be updated, and most importantly, we could not tie anymore, so either one must have a problem.

BTW, the print_valuation function in swap_float_leg instrument will call print_payments as well, creating visual verbose including duplicate tables and info, maybe this could be improved this as well. (this is also a new problem in latest version).

Thanks,
@domokane
Copy link
Owner

domokane commented Jul 7, 2023

Thanks. I will look into this. I have not had time to push the most recent changes. Maybe this weekend.

@nashquant
Copy link
Contributor

Hi Professor, I've probably introduced the changes related to the swap legs, so happy to pick up this review this weekend if you are ok with it.

@domokane
Copy link
Owner

domokane commented Jul 8, 2023 via email

@nashquant
Copy link
Contributor

Alright, I started looking into this.

  1. Formatting: Indeed the choice I made to include print_payments within print_valuation wasn't good, what if I refactored the valuation table schema like the image below + remove print_payments from it? I.e. Upside: Quite concise table, with all relevant info / Downside: User would need to print_payments to check Start/End Accrual valuation dates, otherwise the table would be too long to display. Let me know if you have a better idea!

image

  1. Values not matching: I suspect that this isn't related to my change, but of course gonna keep debugging this. Looking at the notebook @ version 0.184, noticed the column "Rate/IBOR" used to derive the cashflows are quite different (e.g. comparing the two images, for 1st payment, it is 2.005 in one,and 1.97758 in the other, which explains the final difference). Nevertheless, the logic to derive the rates shown wasn't changed in my PR, @domokane are you aware of any change that might be related to this?

image

I'll take a look again later

Cheers,
Matheus

@nashquant
Copy link
Contributor

Apparently the float_leg issue was introduced in commit 2d43d10.

If you look at the changes in swap_float_leg.py, you'll notice fwd_rate calculation changed to use index_alpha instead of pay_alpha, which explains the IBOR Rate change I highlighted above.

Professor, do you recall why this was necessary?

PS: For the 1st payment in the example above, we have:
Pay_alpha == 0.2555555
Index_alpha == 0.2520547

Which is explained by Index being in Act_365F day count, whereas Pay_alpha is ACT_360 - the two account for 92 days of accrual.

Thanks

@domokane
Copy link
Owner

domokane commented Jul 9, 2023

Hi - I believe I did this as it seemed appropriate to separate the choice of accrual method for the index from the choice of accrual method for the payment leg. Perhaps I have mispecified the index accrual method in the example - it should be the same as the payment method ? Would that fix the problem ?

@nashquant
Copy link
Contributor

Hi @domokane, thanks for your reply.

  • I don't think you mispecified the index accrual method. The example setup is in accordance to the one for QL: http://gouthamanbalaraman.com/blog/interest-rate-swap-quantlib-python.html (Libor is in Act/365F, whereas swap is in Act/360)
  • It is possible that the new/current result for float_leg is right - although I haven't given too much though on that yet, I think your change is appropriate.

@nashquant
Copy link
Contributor

After giving it some thought, I'm quite confident that the updated value for the float leg is the right one - the changes you've made look good to me. Besides that, considering that we're setting Libor rate at a flat 2%, the figures above tell us that in version 0.184 (which matches the results in the blog), the Libor rate was off a bit, coming in at 1.97%.

@domokane
Copy link
Owner

OK. Thanks.

@nashquant
Copy link
Contributor

Thank you, when I find sometime I'll create a PR for the formatting fix.

@YimingZhang07
Copy link
Author

Thanks for looking at this. If we confirm the current methodology is right, I strongly recommend refreshing the related notebooks too see the impacts if possible. As I see, the valuation difference can be as large as 15-20% for example in FINIBORSWAP_DefiningAFixedFloatingSwap.ipynb. What's more, since swap is fundamental in building curves, e.g. in CDS valuation, I wonder if our results could still tie with Markit.

I am willing to help on this as well, but in coming weeks.

@domokane
Copy link
Owner

domokane commented Jul 11, 2023 via email

This was referenced Jul 30, 2023
Open
Merged
@Nollad Nollad mentioned this issue Aug 14, 2023
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@domokane @YimingZhang07 @nashquant