Hi folks,
We are happy to announce the release of PyQL [1], a new set of Python wrappers for QuantLib.
The project is available here :
* URL: http://github.com/enthought/pyql
* License: BSD license.
* Authors: Didrik Pinte, Enthought and Patrick Henaff, IAE Paris.
Why another set of Python wrappers for QuantLib?
The SWIG wrappers provide a very good coverage of the library but have
a number of pain points:
- few Pythonic optimisation in the syntax: the code a user must writeon the Python side looks like the C++ version
- no docstring or function signature available on the Python side
- complex debugging and complex customization of the wrappers
- monolithic build process
- complete loss of the C++ code organisation with a flat namespace in Python
- SWIG typemaps development is not that fun
For those reasons and to have the ability to expose some of the
QuantLib internals that could be very useful on the Python side, we
chosed another road. PyQL is build on top of Cython and creates a thin
Pythonic layer on top of QuantLib. It allows a tight control on the
wrapping and provides higher level Python integration.
Features:
- Integration with standard datatypes (like datetime objects) and numpy arrays
- Simplifed API on the Python side (e.g. usage of Handles completely hidden from the user)
- Support full docstring and expose detailed function signatures to Python
- Code organised in subpackages to provide a decent namespace, very close to the C++ code organisation
- Easy extendibility thanks to Cython and shorter build time when adding new functionnalities
- Sphinx documentation
It supports QuantLib >= 1.1 and currently builds very nicely on MacOSX
and Linux. The Windows builds will be there soon. Regarding the build
process, make sure you read the build instruction!
(Cython 0.15 needs a simple patch available in the repo)
The library comes with a decent test suite and many examples: from the
very basic option valuation to more complex heston model calibration
within an IPython notebook.
For more details, take a look at the code, contact the authors, or
discuss on the list!
We are looking forward questions, comments, contributions.
[1] The name is still subject to modification as PyQL is already used
by other projects unrelated to QuantLib. Suggestions are welcome!
Things and thoughts 
How bout PyQuant?
I was scrolling down do leave PyQuant as a suggestion, too! So I’ll officially be the second vote for that name.
I have zero experience with Cython, but I’ve used QuantLib and the SWIG Python bindings a good bit…you’re list of shortcomings is on point, if not generously brief. Two questions, though, about your project:
1) I’ve heard good things about Cython and performance…have you benchmarked any of the converted projects against the SWIG bindings?
2) I assume your objective is to preserve the structure of QuantLib, rather than add to it…is that accurate?
I note the second PyQuant vote then 😉
Regarding your questions :
1) I have made a very miminmal benchmark just on the Date object wrapped with SWIG and Cython. The Cython wrappers are 4 to 5 times faster than the SWIG wrappers. The test is in the documentation.
2) For the low level part, yes. We try to stay as close as possible to the QuantLib C++ code structure. We plan a higher level layer that will be much more Pythonic and much closer to many of the day to day applications. That layer will add a number of functions on top of the existing QuantLib structure.
Could you kindly guide me on how to install this? There is no documentation at all, if there is I can’t find it. I installed quantlib, visual studio 9.0. I have python and cython setup in my system.
I am on Windows 7. I downloaded the repo from the github and gave the command
python setup.py install
I got the following output:
C:\Python27\lib\distutils\extension.py:133: UserWarning: Unknown Extension options: ‘pyrex_directives’
warnings.warn(msg)
running install
running bdist_egg
running egg_info
writing requirements to quantlib.egg-info\requires.txt
writing quantlib.egg-info\PKG-INFO
writing top-level names to quantlib.egg-info\top_level.txt
writing dependency_links to quantlib.egg-info\dependency_links.txt
reading manifest file ‘quantlib.egg-info\SOURCES.txt’
writing manifest file ‘quantlib.egg-info\SOURCES.txt’
installing library code to build\bdist.win32\egg
running install_lib
running build_py
running build_ext
building ‘*’ extension
c:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\BIN\cl.exe /c /nologo /Ox /MD /W3 /GS- /DNDEBUG -DHAVE_CONFIG_H -D__WIN32__ -DWIN32 -DNDEBUG -D_WINDOWS
-DNOMINMAX -DWINNT -D_WINDLL -D_SCL_SECURE_NO_DEPRECATE -D_CRT_SECURE_NO_DEPRECATE -D_SCL_SECURE_NO_WARNINGS -IE:\tmp\QuantLib-1.1 -IE:\tmp\boost_1_46_1 -I.
-I./cpp_layer -IC:\Python27\include -IC:\Python27\PC /Tcquantlib/*.c /Fobuild\temp.win32-2.7\Release\quantlib/*.obj /GR /FD /Zm250 /EHsc
*.c
c1 : fatal error C1083: Cannot open source file: ‘quantlib/*.c’: Invalid argument
error: command ‘”c:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\BIN\cl.exe”‘ failed with exit status 2
Sorry to dump this over here, but I had no idea where else!
Building on Windows is on our todo list. Do you have QuantLib properly built? What is your setup.py file?
I would suggest we discuss that on the issue tracker of the project: https://github.com/enthought/pyql/issues?state=open . Create a new issue and we will try to solve it. It is pretty important for the project
This looks like exactly what I need. Great effort. Where can I find documentation/tutorials for this project?
The “documentation” and “tutorial” are within the doc directory on github. It is pretty sparse so far. You have to build them using sphinx.
Managed to install this on my Snow Leopard. Works great, thank you very much for your work guys !
Just installed under Windows 7, Python 2.7.3 [32 bit] and Visual Studio 2008. Needed to make a few minor changes to setup.py. Happy to share the details if this is still an open issue.
I would love to know what you needed to change to get the install to work. I would like to try PyQL but will be working on Windows 7, Python 2.7.3 64bit. Visual Studio 2010. Thanks in advance.
Simon has the same issue as all the others 😉
Getting the wrappers to build is not too complex. The issue is that the Setting singleton does not seem to be shared by the different pyd files … Still investigating but not much bandwidth currently.
Sorry to ask what maybe a silly question, but does this mean that PyQL is completely unusable on Windows or is it just a subset of the functionality that doesn’t work at present?
Just spent some time working my way through QuantLib and I now understand at least some of the problems that Setting not being a singleton will cause.
Just to add to what Didrik said, my understanding is that each .pyd [.dll under Windows] is compiled with all its dependent objects, so for example the Settings singleton class will be compiled into bonds.pyd as well as settings.pyd, but any code in bonds.pyd will access Settings in its own compilation unit.
It is possible to work around this by creating a custom build step for bonds and including Settings.pyx etc [I’d need to check my repo for the details if you are interested]. You would then need to access Settings in this context.
It’s likely that this issue may exist in other QuantLib classes that derive from the singleton class, or depend on other static data members.
The changes I made to setup.py were to make the defines = [ (‘HAVE_CONFIG_H’, None)] statement not part of the win32 build, and I also commented out the pyrex_directives = CYTHON_DIRECTIVES as I found these were not recognised in my build config.
Also I see you intend to build under Visual Studio 2010 – there are possibly some issues with this as Python itself is compiled under VS2008. It may be possible to recompile under VS2010, but I don’t think it’s a supported config e.g. http://bugs.python.org/issue13210.
Sounds like the pybg guys have found a way to solve the issue. The dependant cpp/hpp file need to be compiled directly with VS and not through distutils as a dependant file from the pyx extension. Will try to test this asap.
Mark or Simon, would you mind assisting me to get this working? I have a similar setup to yours, but use a later version of Visual Studio. Your help is greatly appreciated…
Sorry for the post below, meant to place it within this thread.
Hi Sriram, there will be some issues using a later version of Visual Studio since the Python dist. is compiled with VC9, so there will probably be run time library issues. see http://bugs.python.org/issue13210. It may be possible to recompile the Python source under Visual Studio 2010 – see http://wiki.python.org/moin/VS2010. Which version of Visual Studio are you targeting?
Hey Simon, you can bypass distutils by faking a VS90 install. Just do update the environment variable on your command line like this (making the assumption you have the VS100COMNTOOLS environment variable set):
set VS90COMNTOOLS = %VS100COMNTOOLS%
Simon, would you mind helping out with how to get this working under Windows 7? The only difference between my setup and yours is that I use a later version of Visual Studio. Looking forward to your reply.
I actually compiled the thing on Windows, using x64 since I am running on 64-bit python 2.7. Using the Windows 7 SDK combined with Visual C++ 9.0, via command-line, this seems to work pretty cleanly. Now for the problem that I see:
It doesn’t look like there is support for polymorphism. The C++ QL has at least 6 different ways to initiate a DepositRateHelper, depending on how and which information you are supplying. On the other hand in PyQl it seems that only one of them exists – precisely the one declared in rate_helpers.pyx. Trying to invoke any other version results in a type error or a complete crash of python.
def __init__(self, Rate quote, Period tenor=None, Natural fixing_days=0,
Calendar calendar=None, int convention=ModifiedFollowing,
end_of_month=True, DayCounter deposit_day_counter=None,
IborIndex index=None
):
I do not deeply understand what is going on with the cython here, so what I am missing here?
Thanks.
Hi stas, good to hear you can compile it properly. Could you run the test suite and report the results ? There is a long standing bug with the QuantLib::Settings singleton that should make some of that fail under windows.
For the DepositRateHelper constructor, we currently expose only one. The typical approach there is to create some factory class methods to support the other constructors we need to expose. If you have crashes, please report on the pyql bug tracker with some reproducible code (see http://github.com/enthought/pyql )
Thanks!
Thanks for the reply. I think I understand things better now. I did not notice the test suite, so ran it now. It show that some things don’t work as expected, so I’ll have to dig and figure out what exactly is going on.
Following tests produce errors:
test_bonds.py (fail 2, skip 1)
test_heston_model.py (fail 1)
test_mlab.py (fail 1)
test_piecewise_yield_curve.py (fail 1)
test_vanilla_option.py (fail 3)
I am going to be messing around with this more, so instead of putting up the raw output of failed tests I’ll see if I can figure out what is breaking them first and drop you a better description.
I am writing in this forum after a long time and wanted to update you on some success and challenge. First, I am able to compile quantlib on an AMD 64 bit platform with Python 2.7 using Visual Studio 2012. I’m also able to successfully run setup.py in the pyql distribution. I’d be happy to assist anyone who needs help here.
My interest is in pricing credit default swaps, and I have challenges. I am able to run CDS.exe that comes with the quantlib Visual Studio solution and see reasonable outputs. However, when I run the cds.py that comes with pyql, I don’t get meaningful results.
Similar to stas’s experience below, when I run various components of the test suite, I get failures. the test_cds.py, however, returns an OK status.
Any thoughts or suggestions? I provide the output of cds.py below. I note that within the body of that script is commented some C++ code. It seems that you might be aware of some problems in accessing values from hazard_rate_structure. The 0 values for the default and coupon legs are consistent with 0-valued hazard rates (or null pointers, perhaps).
Thanks–
PS C:\temp\pyql-master\examples> python cds.py
15/05/2008
Some survival probability values:
1Y survival probability: 97.039689%
expected: 97.040000%
2Y survival probability: 99.950750%
expected: 94.180000%
Repricing of quoted CDSs employed for calibration:
3M fair spread: 0.0
NPV: 0.0
default leg: 0.0
coupon leg: 0.0
6M fair spread: 0.0
NPV: 0.0
default leg: 0.0
coupon leg: 0.0
1Y fair spread: 0.0
NPV: 0.0
default leg: 0.0
coupon leg: 0.0
2Y fair spread: 0.0
NPV: 0.0
default leg: 0.0
coupon leg: 0.0
Reporting back some additional findings here… as I mentioned below, I am not getting correct results when I run cds.py. I am not sure if this is anything due to PyQL or otherwise.
So I instead created a DLL of the Quantlib CDS example and then loaded that with the standard library module ctypes. I found the same results– that calling Quantlib, however wrapped (whether cythonized or through ctypes), I cannot get the correct answers. So my feeling is that this has something to do with the C++/Python interaction in general. In all the cases, I have started by setting VS90COMNTOOLS = %VS100COMNTOOLS%, as dpinte suggests above.
Please let me know if there’s something I may have missed.
@Sriram: can you run the entire test suite and send me the results? dpinte at enthought.com The main known issue is with the Settings singletion.
stas, can you explain your steps to getting PyQL compile in your setup? I have the exact same setup. I was able to compile boost and quantlib libraries, and after changing the lib and include locations in the setup.py, I am still not able to get PyQL to compile and getting linker errors such as this one.
Any idea why?
c:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\BIN\link.exe /DLL /nologo /INCREMENTAL:NO /LIBPATH:C:\sr
c\cpp\QuantLib-1.2.1\lib /LIBPATH:C:\src\cpp\boost\stage\lib /LIBPATH:C:\Python27\libs /LIBPATH:C:\Python27\PC
build QuantLib.lib /EXPORT:initcurrency build\temp.win32-2.7\Release\quantlib\currency.obj /OUT:build\lib.win3
2-2.7\quantlib\currency.pyd /IMPLIB:build\temp.win32-2.7\Release\quantlib\currency.lib /MANIFESTFILE:build\tem
p.win32-2.7\Release\quantlib\currency.pyd.manifest /subsystem:windows /machine:I386
msvcprt.lib(MSVCP90.dll) : error LNK2005: “public: __thiscall std::basic_string<char,struct std::char_traits,class std::allocator >::~basic_string<char,struct std::char_traits,class std::allocator
>(void)” (??1?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@QAE@XZ) already defined in QuantLib
.lib(errors.obj)
Hard to tell from the error alone, it it just looks like it can’t resolve references during linking process, but that was obvious …
I am assuming you are trying to compile a 32-bit version, based on what I see here?
One detail I left out above – I am using Cython 0.17, without any patches.
[…] PyQL : a new set of Python wrappers for QuantLib « Things and …Mar 23, 2012 … Hi folks,. We are happy to announce the release of PyQL [1], a new set of Python wrappers for QuantLib. The project is available here : … […]
Hello,
After installing pyql on Ubuntu 14.04 into dist-packages folder of python 2.7, all tests finished with success. But, python don’t see this installation, and I cannot import anything from it.
Have you any idea, what I need to define in addition?
Thanks,
Yigal B.
Great delivery. Soound arguments. Keep up the great spirit.