SWIG port

[Anonymous]

Hi team,

First, congrats on a great tool and your choice to make the source code available to all.
I’ve been building a C# wrapper using QuantLib-SWIG, but QuantLib misses some functionalities which I could find in QuantExt. Unfortunately they don’t seem to have associated SWIG interface files.
Is developing a SWIG interface on your roadmap? Alternatively, how open would you be to transfer some of the QuantExt functionalities to QuantLib and build the interface in QuantLib-SWIG?

Fabrice

[Anonymous]

Hi Fabrice,

Thanks.

It’s not on the immediate roadmap but is something we have thought about and we are open to contributions. The aim was to focus initially on the core functionality and then see what people thought.

Are you just interested in exposing QuantExt or all of ORE?

Regards,
Niall.

[Anonymous]

Hi Niall,

Thanks for your answer.
While I might be interested in using other ORE functionalities (specifically OREData) in the future, for now I’m only looking at QuantExt (and only a few classes there honestly).
I’d be keen to contribute, however I would prefer to build on QuantLib-SWIG instead of duplicating the various artefacts of that project. In order to do that, I would first transfer some of the functionality I need to QuantLib (if all parties agree to it of course) and then add SWIG interface files in QuantLib-SWIG.
I understand that you might be reluctant to encourage the transfer of your fine work into another repository, and also that you might want to look into an initial framework which would include all of ORE. I’d like to avoid as much friction as possible between myself, the ORE team, and the QuantLib team, so I’m keen to hear your thoughts.

Regards,
Fabrice

[Anonymous]

Hi Fabrice,

In some areas there is allot of overlap between QuantLib and QuantExt, that is true, it’s an open question if some things should be moved over, for example we added a few additional Calendar classes and some other volatility term structures that worked with a floating reference date. Also we have added to QuantLib itself over the years, so we have no problem with both approaches.

We have deliberately kept QuantExt to be C++98 compliant so it is compatible with QuantLib. OREData and Analytics use C++11.

Our initial motivation was to release ORE that worked out of the box with a fully released QuantLib, to avoid any conflicts and dependancies it was easier for us to just add classes to QuantExt. Then we would see what people thought (including the QuantLib community of course) and see what the best thing to do was, so in that sense I’m interested in your feedback, and so your point about SWIG is a good one.

Can you tell us what specifically what classes you were looking at in QuantExt? I’m not sure they would all be suited to QuantLib, but it’s a matter of opinion.

Regards,
Niall.

[Anonymous]

Niall,

For now, I’m looking at some rate helpers (AverageOISRateHelper, CrossCcyBasisSwapHelper, OIBSHelper, OICCBSHelper, OISRateHelper, TenorBasisSwapHelper), their associated instruments & engines (and whatever needs to be transferred to properly compile really) & some indexes (although I could use IborIndex for everything).
I’m at the early days of building a wrapper in C# to construct various curves, and I hope to move on to volatility surfaces in the future, so this list is by no means set in stone and is bound to grow.

I most definitely understand the reasons why you build QuantExt outside of QuantLib. Not being tied to the QuantLib release cycle, avoiding conflicts and dependencies, and some more specific extensions around market simulation models being less suited to be in QuantLib are all fair points.
However I would be partisan for as much of the QuantExt functionalities as possible to be transferred to QuantLib for the following reasons (some might be a bit self centered, my apologies):
– The already existing QuantLib-SWIG project I mention in my previous post,
– Duplication of functionality: back in the days when you released ORE, I was contributing to QuantLib some AUD BBSW indexes. I saw that you had them to in QuantExt after contributing them. Ideally, one set should go away, however while adding classes is easy, removing them after they start being used is much harder I’m sure you’ll agree.
– Duplication of work: work has been done in QuantLib to enable VS2017. I don’t think it has been done in QuantExt yet, and it would consist of pretty much the same tasks.
– Extended peer review: I found a compilation error in QuantExt when using a modified userconfig.hpp, which I’m sure the (wider?) QuantLib community would have spotted and corrected much earlier.
– Currently the Engine repository points to commit fed85cc of QuantLib (20/09/2016). For this and some of the reasons above, I have QuantExt refer to my own clone of QuantLib, not the one provided in the ORE repository. I’m not familiar with Git submodules, but it seems to put the effort of keeping QuantLib updated on you, which has pros (out of the box ORE) and cons (old QuantLib version).

It’s a bit of a mishmash, and not all those issues would be completely solved by transferring the functionalities I’m looking at to QuantLib. However I do believe there is a case for most “natural” (whatever that means) classes to be transferred over.

Note I intend to contribute fixes to ORE for points 3 & 4 above in the near future.

Regards,
Fabrice

[Anonymous]

Hi Fabrice,

Thanks, they are all valid points.

Regards,
Niall.

[Anonymous]

Thanks Niall,

Can I then go forward and transfer some functionalities? Would you like me to also switch references from QuantExt to QuantLib in ORE (this would require an update of the submodule after or during transfer though I’d think, not 100% certain how to do that) and delete the duplicated QuantExt classes, or do you want them to stay in for now?
I’m not sure how frozen you want your interface to be, but if possible I’d recommend removing from QuantExt whatever we move to QuantLib. Let me know how you wish to proceed.
In any case, I’d be eager to do a trial run first on one class, say TenorBasisSwapHelper.

Regards,
Fabrice

[Anonymous]

Hi Fabrice,

We would prefer to manage this migration ourselves, in consultation with the community (ORE and QL) and taking both release cycles into account. We are currently in the middle of the third release, which will involve additions to QuantExt and I believe QL is in the middle of 1.11. I’d prefer to start planning now but aim to do the actual migration after these two releases.

With that in mind, there are 131 header files in QuantExt, this will grow to nearly 150, can you list all the ones you would like to see in QuantLib? for me the currencies and Ibor indices are the obvious candidates, after that it might get more involved as some of the classes we have are similar to QL ones but have small changes, rather than copying them over maybe the two should be integrated somehow, so it’s not a straight port and there will be some effort required. I know you are mainly interested in the bootstrap helpers now, but do you see your scope growing?

Finally, we need to consider the two licences, I’m not sure we can just lift and shift C++ files from ORE into QL without including the ORE licence, which might not be acceptable to everyone, I’m trying to get an answer on this.

Regards,
Niall.

[Anonymous]

Hi Niall,

Understood. Do you have a rough idea when the 2 releases will be done and the transfer can be started? How long it would take?

Regarding what to transfer, I agree currencies and indices are natural candidate for a straight transfer (although there might already be conflicts for some indexes like AUD BBSW). Maybe consider the math and quotes folders too? They seem pretty self contained.
I’m indeed mainly interested in bootstrap helpers for now. I know that I have a need for:
– tenorbasisswaphelper.hpp,
– oisratehelper.hpp,
– oibasisswaphelper.hpp,
– crossccybasisswaphelper.hpp,
– averageoisratehelper.hpp
Of course, transferring those would also require the transfer of the associated instrument and pricing engine (cashflows? Not sure).
At this stage, I’m uncertain if I would need other bootstrap helpers in the future, but it’s clearly a possibility.
I know my scope will grow to volatility surfaces. A lot of what I see in the termstructures could be helpful, but it’s way too early for me to say what exactly.
I’ll update my list with new requirements in case they arise before you finish the transfer.
Let me know how I can assist, I’m keen to help if possible.

Regards,
Fabrice

[Author]

Posts