-
Notifications
You must be signed in to change notification settings - Fork 196
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
Calls to CreditDefaultSwap.fair_upfront crash Python #169
Comments
fair_upfront throws unless you build a cds with upfront which you can't do right now with pyql (See https://github.com/thrasibule/QuantLib/blob/master/ql/instruments/creditdefaultswap.cpp#L179). Now we should raise an exception in python instead of aborting. |
Thank you for this, it's very helpful. Apologies in advance because this would be much more straightforward if I had a good working knowledge of quantlib. After looking through the quantlib code I did notice that fairSpread() "does not take any upfront into account, even if one was given", which rules out my intended use for specifying an upfront in the first place - i.e. as way to back out the fair spread given only the upfront. Is there a common industry equivalent use-case for specifying the upfront as implemented by quantlib? In any event, I was playing around with the C++ CDS example in quantlib and noticed that if you specify a protection startDate and an upfrontDate of today, then subsequent calls to fairUpfront() return the 'fair upfront not available' error that you referenced in your last post. If you change the upfrontDate = T+1 or later then fairUpfront() computes the correct upfront, which obviously ignores the provided upfront so I don't really understand the logic behind this behavior. If I move the accrual date, protection start date and upfront date all forward to T+1 and leave the evaluation date on T then it also works so I'm guessing this is associated with the includeTodaysCashFlows option in Settings but have not has a chance to investigate yet. When I try the same from pyql using your branch, and creating the CDS with:
and then call:
I get an error message which is much more informative than the prior crashes:
this behaviour matches the C++ implementation, however when I advance the upfrontDate to todays_date+1, it crashes Python like before. I'm not worried about a day or so of PV-ing difference ... this version will work perfectly fine for me, but I wanted to let you know the behaviour I was seeing in case you were ultimately planning to merge this back into the master branch. Many thanks for the help. |
@tangent360 thanks for your detailed notes. The best for debugging such issue is to provide a minimal script that reproduces the bug. Is this something you could share? I suspect we do have a c++ exception raised that we don't manage properly in pyql and that the fix should be quick and easy to implement (adding some |
You're right, if you want to get the upfront equivalent, you can just look at the npv of the cds. |
Thank you both for the responses. My output:
My test script:
|
I've tried your script. It runs fine for me with my latest branch if I replace exec_info by exc_info (there is a typo there), and it catches the runtime exception. However it shows the same upfront as before, since obviously the cds is not updated. Are you positive you can build a cds with these parameters in C++? Can you share that C++ code as well if that's the case? |
I was missing a second boolean value in the argument list to
Many thanks for all the help on this. Here is my new output and test script: Output:
Script:
|
Hey,
I attempted to modify pyql/examples/cds.py to get it working with the latest version of the library. I'm new to pyql and Quantlib so I may well have made an error but all the tests seem to execute fine. However, when I tried to call fair_upfront it crashes Python (The function is not called by any of the pyql examples but I saw it in the Quantlib docs and I see it listed as a property in instruments/credit_default_swap.pyx).
The problem line in the code below is the very last line, everything else runs fine:
print(" Upfront: ", cds_2y.fair_upfront)
I've tried this on two different machines and get the same result - Win 10 and Win 7 (64bit).
I've attached a debugger from pyCharm but it just crashes too whenever I try to inspect the cds_2y object.
I've tried ipython and python, I've tried launching from inside the IDE and from the command line ... always the same result.
Some info that may be useful:
I have also applied the singelton patch to line 37 of Settings.hpp and all the tests run fine but I'm experiencing the Heston numerical errors that others have noticed (Issues #64 and #161).
Appreciate any help. Thanks.
The text was updated successfully, but these errors were encountered: