Has there been any desire to submit pull requests to make QuantExt part of Quantlib itself?

[mrslezak]

I'm just wondering why, I know it's not required by the BSD license, but is there a reason for leaving the QuantExt extensions outside of the QuantLib library itself? If it was pushed to the QuantLib library, there would be many more "eyes" on it from the open source community, and therefore likely more development upon its work. I understand it is the work of the company in support of Open Source Risk, but this would potentially simplify the development ahead for both OSR and QuantLib. And likely reduce maintenance on the side of the OpenSourceRisk project team. I suppose the real question: is it OSR's desire to keep their extensions separate? If they were integrated into QuantLib, along with the test suite, then it would be maintained by QuantLib devs and updates would be automatically done on their side, freeing up the work that OSR devs would have to do with every incremental update of QuantLib. I see there was a session in 2018 where this was discussed, but haven't seen it done yet.

I'm attempting to port it over but I am not exactly a C++ expert. So some of the functions I'm potentially breaking but keeping a list for those that know C++ well so they can fix it properly if they need those functions (I personally don't), mostly by commenting out problematic code segment declarations in MSVC 14.1 (Visual Studio 2017 Community), or adding missing include files that have needed definitions imported. I suppose I'll see if I broke anything by running the QuantExt testsuite against it once I work through the errors. But this would be SO MUCH FASTER if someone well versed in C++ was helping me do it. I'll get the changes into my GitHub fork probably in the next week or so, once I get it compiling as a standalone library.

[mrslezak]

Okay I started the port of QuantExt and resolved the errors on VS2017 Windows 10 with Boost 1.77.0 and QuantLib 1.23, using the Windows 8.1SDK and haven't finished the testsuite. Once the testsuite is done, it should be about ready to merge into QuantLib. If anyone wants to help with this, my repo is here: https://github.com/mrslezak/Engine check the 1st commit there were various issues with the formatting using the code as is posted here on Windows 10, but now it compiles fine. The offline installer for VS2017 Community was failing for me on download so I ended up using this ISO and then adding the C++ needed features afterwards: https://drive.google.com/file/d/1b5lqWOE421vDw-wDPxBBxixEcienyhx2

Anyhow on the testsuite the issues seem to be mostly around missing semicolons and then dategeneration.cpp has quite a few calendars that are not members of QuantLib::DateGeneration such as:

Error C2039 'ThirdThursday': is not a member of 'QuantLib::DateGeneration' QuantExtTestSuite c:\engine\quantext\test\dategeneration.cpp 83
Same thing for ThirdFriday, MondayAfterThirdFriday and TuesdayAfterThirdFriday, basically everything in that dategeneration.cpp

This leads me to believe the QuantLib dategenerationrule.hpp file (they did not include) that ORE is using is a modified version, as the mentioned rules are not inside the latest file. Does anyone have the file with these undeclared calendar rules??? You can see the latest file is missing all of these rules: https://github.com/lballabio/QuantLib/blob/master/ql/time/dategenerationrule.hpp

[pcaspers]

We use our own fork of QuantLib (as a git submodule of this repo) with a few extensions and patches. The date generation rule you mention is defined here

https://github.com/OpenSourceRisk/QuantLib/blob/77ecf0a9d573234f5db7a02f75a3caa65ab57662/ql/time/dategenerationrule.hpp

We strive to get our patches into the main QuantLib repo over time, so that our submodule shows minimal and only temporary differences to the official QuantLib release.

[mrslezak]

My true interest in all of this is to actually make a better Python interface to all the libraries. As the SWIG interface is a little archaic, I imagine that https://github.com/StatisKit/AutoWIG which auto-wraps to a Boost.Python interface would be cleaner. Not to say it's auto-wrapping will work perfectly without any tweaks, but it would help port it over. It also can wrap to PyBind11 but I'm not so sure that would work without removing the Boost dependencies from QuantLib (which hasn't been done since v1.10 here: https://github.com/haozhangphd/QuantLib-noBoost) and is unlikely to be embraced by the QuantLib project... Since they knew of its existence, but never extended it further in some older emails on the QuantLib discussion forums. What all has changed in v1.23 I'm not sure but that's quite a bit newer.