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

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

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

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