quantlib-dev — Discussion of QuantLib development

[Quantlib-dev] QuantLib 1.11 released

[Luigi B. <lui...@gm...>]

Hello everybody,
    QuantLib 1.11 has been released and is available for download at
http://quantlib.org/download.shtml.

The list of changes for this release is at
http://quantlib.org/reference/history.html.

Please report any problems you have with this release to the QuantLib
mailing list (qua...@li...), or open a GitHub issue
at https://github.com/lballabio/quantlib/issues.

-- The QuantLib group

[Quantlib-dev] ObjectHandler's exampleStatic.xls example

[redlamp <red...@ya...>]

I compiled  ObjectHandler_vc12.sln and successfully generated
"ExampleXllStatic-vc120-mt-1_9_0.xll" in order to make the example
spreadsheet, exampleStatic.xls, run with this new addin; but, with new addin
added in the spreadsheet, after I run Alt-Xtrl-F9, I kept getting "#VALUE!"
for those cells interested.

Who has any idea what I can do to make the spreadsheet run ? 

Thanks.



--
Sent from: http://quantlib.10058.n7.nabble.com/quantlib-dev-f8818.html

Re: [Quantlib-dev] QuantLibXL enhancements

[Eric E. <eri...@re...>]

Yes that would be much appreciated.

I still need to package a 1.10 release, I will include your changes.

On 2017-09-21 18:50, Francois Botha wrote:
> Thanks. I just remembered I have an outstanding PR at 
> https://github.com/eehlers/quantlib-old/pulls . Should I migrate that 
> to https://github.com/eehlers/QuantLibAddin-Old 
> <https://github.com/eehlers/QuantLibAddin-Old> too?
>
> Francois Botha
>
> On 21 September 2017 at 15:45, Eric Ehlers <eri...@re... 
> <mailto:eri...@re...>> wrote:
>
>     Hi Francois,
>
>     You can commit it to mine.
>
>     https://github.com/eehlers/QuantLibAddin-Old
>     <https://github.com/eehlers/QuantLibAddin-Old>
>
>     I'm behind on the release management, but struggling desperately
>     to catch up!
>
>     Regards,
>     Eric
>
>
>     On 2017-09-21 15:08, Francois Botha wrote:
>
>         Hi,
>
>         If I want to submit PRs for enhancements to QuantLibXL, to
>         which repo should I make it?
>
>         thanks
>         Francois Botha
>
>
>

Re: [Quantlib-dev] QuantLibXL enhancements

[Francois B. <ig...@gm...>]

Thanks. I just remembered I have an outstanding PR at
https://github.com/eehlers/quantlib-old/pulls . Should I migrate that to
https://github.com/eehlers/QuantLibAddin-Old too?

Francois Botha

On 21 September 2017 at 15:45, Eric Ehlers <eri...@re...> wrote:

> Hi Francois,
>
> You can commit it to mine.
>
> https://github.com/eehlers/QuantLibAddin-Old
>
> I'm behind on the release management, but struggling desperately to catch
> up!
>
> Regards,
> Eric
>
>
> On 2017-09-21 15:08, Francois Botha wrote:
>
>> Hi,
>>
>> If I want to submit PRs for enhancements to QuantLibXL, to which repo
>> should I make it?
>>
>> thanks
>> Francois Botha
>>
>
>

Re: [Quantlib-dev] QuantLibXL enhancements

[Eric E. <eri...@re...>]

Hi Francois,

You can commit it to mine.

https://github.com/eehlers/QuantLibAddin-Old

I'm behind on the release management, but struggling desperately to 
catch up!

Regards,
Eric

On 2017-09-21 15:08, Francois Botha wrote:
> Hi,
>
> If I want to submit PRs for enhancements to QuantLibXL, to which repo 
> should I make it?
>
> thanks
> Francois Botha

[Quantlib-dev] QuantLibXL enhancements

[Francois B. <ig...@gm...>]

Hi,

If I want to submit PRs for enhancements to QuantLibXL, to which repo
should I make it?

thanks
Francois Botha

[Quantlib-dev] Deriscope 2.1.1 released

[Ioannis R. <qua...@de...>]

Hi,

Deriscope 2.1.1 has been released so that it stays at sync with the 
recently released QuantLib version 1.10.1

You may download it from https://www.deriscope.com/freedownload.php

Version history available at https://www.deriscope.com/versionhistory.html

With regard to any issue you may contact Deriscope at 
https://www.deriscope.com/support.html

Regards,

Ioannis


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

[Quantlib-dev] QuantLib 1.10.1 released

[Luigi B. <lui...@gm...>]

Hello,
    QuantLib 1.10.1 has been released and is available for download at
http://quantlib.org/download.shtml.  It is a bug-fix release for version
1.10; the (short) list of changes is available at
http://quantlib.org/reference/history.html.

Please post any problems you have with this release to the QuantLib mailing
list (<qua...@li...>), or open a GitHub issue at
https://github.com/lballabio/quantlib/issues.

Re: [Quantlib-dev] Transfer of ORE/QuantExt functionalities

[Luigi B. <lui...@gm...>]

No problems on my side.

Luigi


On Tue, Jul 25, 2017 at 3:09 PM Fabrice Lecuyer <fab...@gm...>
wrote:

> Hi all,
>
>
>
> I’m looking into building a C# wrapper around the QuantExt project of the
> fine people at Quaternion. The best approach would be to transfer the
> functionalities I need (mostly rate helpers and indexes absent from
> QuantLib) to QuantLib and build interface files within the QuantLib-SWIG
> project.
>
> The people at Quaternion seem fine with that approach:
> http://www.opensourcerisk.org/forums/topic/swig-port/#post-6183
>
> In order to avoid any friction, I’d like to know if there is any concern
> here with that approach so I can get started?
>
>
>
> Regards,
>
> Fabrice
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>

[Quantlib-dev] Transfer of ORE/QuantExt functionalities

[Fabrice L. <fab...@gm...>]

Hi all,

 

I'm looking into building a C# wrapper around the QuantExt project of the
fine people at Quaternion. The best approach would be to transfer the
functionalities I need (mostly rate helpers and indexes absent from
QuantLib) to QuantLib and build interface files within the QuantLib-SWIG
project.

The people at Quaternion seem fine with that approach:
http://www.opensourcerisk.org/forums/topic/swig-port/#post-6183

In order to avoid any friction, I'd like to know if there is any concern
here with that approach so I can get started?

 

Regards,

Fabrice

Re: [Quantlib-dev] Ex-coupon adjustment based on unadjusted coupon dates

[Francois B. <ig...@gm...>]

Sorry, ignore this.

I'll just calculate my own adjusted ex-coupon period when required and pass
that through.

regards

Francois Botha

On 19 July 2017 at 11:55, Francois Botha <ig...@gm...> wrote:

> Hi all,
>
> In South Africa, bond settlement is T+3 trading days and the ex-coupon
> period is 10 calendar days from the UNadjusted coupon payment date.
>
> So for a trade date of 2017-06-30 the settlement date is 2017-07-05 (over
> a weekend).
>
> One specific bond, the R207, has a coupon payable on 2017-07-15 (a
> Saturday), which is adjusted to Monday (BDC = Following).
>
> The correct ex-coupon date should be 2017-07-15 - 10 calendar days =
> 2017-07-05, which means on the trade date of 2017-06-30 that coupon was
> already ex.
>
> However, I see in fixedratecoupon.cpp, line 154+ that the ex-coupon date
> is calculated based on the adjusted coupon payment date (line 166).
>
> Unless there is a better alternative, I'd like to add a parameter to the
> ex-coupon details to enable the calculation of the ex-coupon date based on
> the UNadjusted coupon payment date. If you are happy with this, I'll submit
> a PR, but I just wanted to confirm with you first.
>
> thanks
> Francois Botha
>

Re: [Quantlib-dev] Ex-coupon adjustment based on unadjusted coupon dates

[NickG <ng...@bg...>]

Hi Francois,

When I added the ex-coupon code, it was primarily with European government
bonds in mind.  These either have adjusted coupons (eg Italian BTP) or
ex-dividend dates (eg UK Gilts) but not both.

I wonder if there are any other situations outside of SA, where both
coincide.
An extra parameter certainly wont hurt.

Nick



--
View this message in context: http://quantlib.10058.n7.nabble.com/Ex-coupon-adjustment-based-on-unadjusted-coupon-dates-tp18430p18431.html
Sent from the quantlib-dev mailing list archive at Nabble.com.

[Quantlib-dev] Ex-coupon adjustment based on unadjusted coupon dates

[Francois B. <ig...@gm...>]

Hi all,

In South Africa, bond settlement is T+3 trading days and the ex-coupon
period is 10 calendar days from the UNadjusted coupon payment date.

So for a trade date of 2017-06-30 the settlement date is 2017-07-05 (over a
weekend).

One specific bond, the R207, has a coupon payable on 2017-07-15 (a
Saturday), which is adjusted to Monday (BDC = Following).

The correct ex-coupon date should be 2017-07-15 - 10 calendar days =
2017-07-05, which means on the trade date of 2017-06-30 that coupon was
already ex.

However, I see in fixedratecoupon.cpp, line 154+ that the ex-coupon date is
calculated based on the adjusted coupon payment date (line 166).

Unless there is a better alternative, I'd like to add a parameter to the
ex-coupon details to enable the calculation of the ex-coupon date based on
the UNadjusted coupon payment date. If you are happy with this, I'll submit
a PR, but I just wanted to confirm with you first.

thanks
Francois Botha

Re: [Quantlib-dev] Removing Boost dependency from QuantLib

[Hao Z. <ha...@ha...>]

Hi Johannes,

Thank you very much. Actually I am working on that right now... There are more than 3000 lines that need to be changed (including the test suites). Regular expression replacement can help, but there is still quite a lot of labor. I think I've replaced about 3/4 of the operator new already, and I should be able to finish replacing all of them by this weekend. 

Best Regards,

Hao
On Thursday, July 13, 2017 2:04:22 PM MDT you wrote:
> Hi Hao,
> 
> at last I got my new laptop up and running and tried the compile with VisualStudio 2017 - nothing to report, just ran out of the box. Very nice! If you like, I would work on using std::make_shared instead of std::shared_ptr<..>(new …)
> 
> Kind regards,
> Johannes
> 
> > On 7. Jul 2017, at 22:50, Hao Zhang via QuantLib-dev <qua...@li...> wrote:
> > 
> > Hi Peter,
> > 
> > I just removed some GCC-specific code, and made it compile and run under Visual Studio 2017. Unfortunately I do not have access to a Mac, thus I cannot do any testing on macOS. If you have time, can you please try compiling the code again on Mac and send me the error message? I suppose Clang is more similar to GCC than to MSVC, thus if MSVC accept the code, making it run with Clang shouldn't be that hard...  
> > 
> > P.S. std::cyl_bessel_il is not too difficult to overcome. We already have modifiedBesselFunction_i and modifiedBesselFunction_k implemented in QuantLib. These functions just need to be modified for cases when the arguments become very large.
> > 
> > Thanks and Best Regards,
> > 
> > Hao
> > On Friday, July 7, 2017 2:23:00 PM EDT Peter Caspers wrote:
> >> Hi Hao, with the standard compiler on OS X El Capitan (Apple clang 8.0.0) there doesn’t seem to be much hope to get it built.  I also tried the LLVM clang 4.0.1 which is the latest release. That works much better, but there are still issues with C++17 support, some of which are easy to fix (missing template parameters) others not so easy (e.g. there is no support yet for std::cyl_bessel_il). gcc 7 seems to be the better alternative currently.
> >> Best Regards
> >> Peter
> >> 
> >>> On 05 Jul 2017, at 23:03, Hao Zhang <ha...@ha...> wrote:
> >>> 
> >>> Hi Peter,
> >>> 
> >>> As I mentioned in the GitHub README, I have only tested the project with GCC7 on Linux as of now. I plan to make the project compatible with at least Windows and macOS in the near future, but the code will certainly not able to compile on these other platforms before some major changes are made.
> >>> 
> >>> For your specific error, I think the reason is that with GCC the <limits> header is pulled in by <cmath> included by <ql/mathconstants.hpp>. On other platforms <cmath> may not include <limits>. I will include <limits> explicitly in the code, but I'm sure there are many other error messages remaining to be fixed with a non-GCC compiler.
> > 
> >>> 
> >>> Hao
> >>> On Wednesday, July 5, 2017 2:57:07 PM EDT Peter Caspers wrote:
> >>>> Hi Hao, I am trying to build your project (on OSX with clang), I get the following weird error message though. Any idea where this could come from?
> >>>> 
> >>>> make[1]: Entering directory `/Users/peter/QuantLib-noBoost/build'
> >>>> make[2]: Entering directory `/Users/peter/QuantLib-noBoost/build'
> >>>> make[2]: Leaving directory `/Users/peter/QuantLib-noBoost/build'
> >>>> make[2]: Entering directory `/Users/peter/QuantLib-noBoost/build'
> >>>> [  1%] Building CXX object ql/CMakeFiles/QuantLib.dir/cashflow.cpp.o
> >>>> [  1%] Building CXX object ql/CMakeFiles/QuantLib.dir/cashflows/averagebmacoupon.cpp.o
> >>>> [  1%] Building CXX object ql/CMakeFiles/QuantLib.dir/cashflows/capflooredcoupon.cpp.o
> >>>> [  1%] Building CXX object ql/CMakeFiles/QuantLib.dir/cashflows/capflooredinflationcoupon.cpp.o
> >>>> [  1%] Building CXX object ql/CMakeFiles/QuantLib.dir/cashflows/cashflows.cpp.o
> >>>> [  1%] Building CXX object ql/CMakeFiles/QuantLib.dir/cashflows/cashflowvectors.cpp.o
> >>>> [  1%] Building CXX object ql/CMakeFiles/QuantLib.dir/cashflows/cmscoupon.cpp.o
> >>>> [  1%] Building CXX object ql/CMakeFiles/QuantLib.dir/cashflows/conundrumpricer.cpp.o
> >>>> In file included from /Users/peter/QuantLib-noBoost/ql/cashflow.cpp:21:
> >>>> In file included from /Users/peter/QuantLib-noBoost/ql/cashflow.hpp:28:
> >>>> In file included from /Users/peter/QuantLib-noBoost/ql/event.hpp:28:
> >>>> In file included from /Users/peter/QuantLib-noBoost/ql/time/date.hpp:35:
> >>>> /Users/peter/QuantLib-noBoost/ql/utilities/null.hpp:58:24: error: no member named 'numeric_limits' in namespace 'std'
> >>>>               return QL_NULL_REAL;
> >>>>                      ^~~~~~~~~~~~
> >>>> /Users/peter/QuantLib-noBoost/ql/qldefines.hpp:126:39: note: expanded from macro 'QL_NULL_REAL'
> >>>> #define QL_NULL_REAL           ((std::numeric_limits<float>::max)())
> >>>>                                ~~~~~^
> >>>> 
> >>>> 
> >>>>> On 04 Jul 2017, at 21:28, Hao Zhang <ha...@ha...> wrote:
> >>>>> 
> >>>>> Hi Peter and Luigi,
> >>>>> 
> >>>>> Thank you very much for your support! No, the performance gain is not from 
> >>>>> MKL, as MKL is not used in the default setting. I am sorry that I cannot 
> >>>>> pinpoint the exact source of performance gain yet. My hunch is that many 
> >>>>> Boost modules are quite general, and provide features that's not used by 
> >>>>> QuantLib. There are also safety checks in Boost that's not relevant to 
> >>>>> QuantLib. By targeting only QuantLib, I do not need to write many 
> >>>>> redundant features and safety checks, and avoid some extra instructions. 
> >>>>> Also the move semantics in modern C++ may also help with speed. I 
> >>>>> apologize that I cannot answer your question in more detail at this point. 
> >>>>> 
> >>>>> Best Regards,
> >>>>> 
> >>>>> Hao
> >>>>> On Tuesday, July 4, 2017 11:38:00 AM EDT Peter Caspers wrote:
> >>>>>> Hi Hao, that's very interesting. Do you know where the performance gain
> >>>>>> is coming from, is it mostly MKL vs. UBLAS? Or are there other drivers
> >>>>>> as well? I'd also be interested in the motivation to do this in the
> >>>>>> first place, I never thought boost as such was a bad thing? The upgrade
> >>>>>> to C++17 is surely nice and makes sense, no doubt. Best Regards
> >>>>>> Peter
> >>>>>> 
> >>>>>>> On 04 Jul 2017, at 09:42, Luigi Ballabio <lui...@gm...>
> >>>>>>> wrote:
> >>>>>>> 
> >>>>>>> Hello Hao,
> >>>>>>> 
> >>>>>>>  that's great news---I've been wondering myself if this was
> >>>>>>>  possible.  I'll be sure to check out your project.> 
> >>>>>>> I suggest you also post to quantlib-users for greater exposure.
> >>>>>>> 
> >>>>>>> Later,
> >>>>>>> 
> >>>>>>>  Luigi
> >>>>>>> 
> >>>>>>> On Tue, Jul 4, 2017 at 5:24 AM Hao Zhang via QuantLib-dev
> >>>>>>> <qua...@li...
> >>>>>>> <mailto:qua...@li... <mailto:qua...@li...> <mailto:qua...@li... <mailto:qua...@li...>>>> wrote: Hello Everyone,
> >>>>>>> 
> >>>>>>> I have removed all Boost dependency from QuantLib, and ported QuantLib
> >>>>>>> to C++17. The code is hosted on GitHub
> >>>>>>> (https://github.com/haozhangphd/ <https://github.com/haozhangphd/> <https://github.com/haozhangphd/ <https://github.com/haozhangphd/>> QuantLib-noBoost
> >>>>>>> <https://github.com/haozhangphd/QuantLib-noBoost <https://github.com/haozhangphd/QuantLib-noBoost> <https://github.com/haozhangphd/QuantLib-noBoost <https://github.com/haozhangphd/QuantLib-noBoost>>>).
> >>>>>>> 
> >>>>>>> The ported code passes all test cases, and there are significant
> >>>>>>> performance improvements in SOME functionalities. Using the QuantLib
> >>>>>>> Benchmark Suite, Quantlib-noBoost gives 3425 mflops (running time
> >>>>>>> 13.15s), while unmodified QuantLib gives 1440 mflops (running time
> >>>>>>> 44.8s) on my Dell Inspiron 13 i7348 laptop, both running under
> >>>>>>> identical conditions with identical compiler flags. The total running
> >>>>>>> time of the whole test suite is also shorter by ~10% after Boost is
> >>>>>>> removed.
> >>>>>>> 
> >>>>>>> I will continue maintaining this project, and regularly backporting
> >>>>>>> latest commits from QuantLib. I will also make this project work on
> >>>>>>> other compilers besides GCC in the near future.
> >>>>>>> 
> >>>>>>> Best Regards,
> >>>>>>> 
> >>>>>>> Hao
> >>>>>>> 
> >>>>>>> ----------------------------------------------------------------------
> >>>>>>> -------- Check out the vibrant tech community on one of the world's
> >>>>>>> most engaging tech sites, Slashdot.org <http://slashdot.org/> <http://slashdot.org/ <http://slashdot.org/>>! http://sdm.link/slashdot <http://sdm.link/slashdot><http://sdm.link/slashdot <http://sdm.link/slashdot>>
> >>>>>>> <http://sdm.link/slashdot <http://sdm.link/slashdot> <http://sdm.link/slashdot <http://sdm.link/slashdot>>>
> >>>>>>> _______________________________________________
> >>>>>>> QuantLib-dev mailing list
> >>>>>>> Qua...@li... <mailto:Qua...@li...> <mailto:Qua...@li... <mailto:Qua...@li...>>
> >>>>>>> <mailto:Qua...@li... <mailto:Qua...@li...> <mailto:Qua...@li... <mailto:Qua...@li...>>>
> >>>>>>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev <https://lists.sourceforge.net/lists/listinfo/quantlib-dev> <https://lists.sourceforge.net/lists/listinfo/quantlib-dev <https://lists.sourceforge.net/lists/listinfo/quantlib-dev>>
> >>>>>>> <https://lists.sourceforge.net/lists/listinfo/quantlib-dev>
> >>>>>>> ---------------------------------------------------------------------
> >>>>>>> --------- Check out the vibrant tech community on one of the world's
> >>>>>>> most engaging tech sites, Slashdot.org!
> >>>>>>> http://sdm.link/slashdot_____________________________________________
> >>>>>>> __ QuantLib-dev mailing list
> >>>>>>> Qua...@li...
> >>>>>>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
> >> 
> > 
> > 
> > 
> > ------------------------------------------------------------------------------
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > _______________________________________________
> > QuantLib-dev mailing list
> > Qua...@li...
> > https://lists.sourceforge.net/lists/listinfo/quantlib-dev
> 

Re: [Quantlib-dev] Removing Boost dependency from QuantLib

[Peter C. <pca...@gm...>]

Hi Hao, no problem at all, the benchmark results are by far not all that makes the project interesting, it’s great stuff.
Best Regards, Peter

> On 09 Jul 2017, at 20:11, Hao Zhang <ha...@ha...> wrote:
> 
> Hi Peter,
> 
> Thank you very much for helping. So the earlier benchmark results were clearly wrong. I really apologize for the overstated benchmark results. That was not intentional and I have removed the overstated values from README.md.
> 
> Best Regards,
> 
> Hao
> On Sunday, July 9, 2017 8:50:01 AM EDT Peter Caspers wrote:
>> Thanks a lot Hao, it also builds on OS X now. I looked a bit closer at the benchmark results and I think there is an issue in the port of the code to catch, causing the first case to be executed n times instead of each of the n original cases once. I’ll send a merge request with a fix.
>> Best Regards, Peter
>> 
>>> On 09 Jul 2017, at 01:51, Hao Zhang <ha...@ha...> wrote:
>>> 
>>> Hi Peter,
>>> 
>>> Thank you for your suggestion. The code now compiles and runs under Clang 4 and libc++ 4.
>>> 
>>> Best Regards,
>>> 
>>> Hao
>>> On Saturday, July 8, 2017 2:33:17 AM MDT you wrote:
>>>> Hi Hao,
>>>> 
>>>> in my opinion cyl_bessel_il is a case where it would be natural to use its precursor in boost for compilers that do not yet support it in C++17 (i.e. have a check in the configure step for this). After a while you could just switch to the std:: version without much ado. But that’s again going back to my original question about avoiding boost for its own sake vs modernising the code to more recent C++ standards.
>>>> 
>>>> For clang you can check out its source code and build the latest release (or even the current master) on Linux yourself. That works well for me on Ubuntu. I guess when your QuantLib-noBoost builds with clang on Linux there won’t be issues on OS X (with the LLVM clang) either.
>>>> 
>>>> I would still be most interested in where the performance gain comes from exactly and if we can benefit from it in QuantLib classic as well, without C++17: It’s easy to say, let’s allow for 11, 14, 17, but there are still places where you have to work with MSVC 2010. In this situation you are happy that QL is still on 03 and you don’t have to backport it or use an older version. I’d be in favour of allowing 11 in QuantLib classic, but ideally maintaining a 03 branch which receives bug fixes, calendar updates etc.
>>>> 
>>>> Best Regards
>>>> Peter
>>>> 
>>>>> On 07 Jul 2017, at 22:50, Hao Zhang <ha...@ha...> wrote:
>>>>> 
>>>>> Hi Peter,
>>>>> 
>>>>> I just removed some GCC-specific code, and made it compile and run under Visual Studio 2017. Unfortunately I do not have access to a Mac, thus I cannot do any testing on macOS. If you have time, can you please try compiling the code again on Mac and send me the error message? I suppose Clang is more similar to GCC than to MSVC, thus if MSVC accept the code, making it run with Clang shouldn't be that hard...  
>>>>> 
>>>>> P.S. std::cyl_bessel_il is not too difficult to overcome. We already have modifiedBesselFunction_i and modifiedBesselFunction_k implemented in QuantLib. These functions just need to be modified for cases when the arguments become very large.
>>>>> 
>>>>> Thanks and Best Regards,
>>>>> 
>>>>> Hao
>>>>> On Friday, July 7, 2017 2:23:00 PM EDT Peter Caspers wrote:
>>>>>> Hi Hao, with the standard compiler on OS X El Capitan (Apple clang 8.0.0) there doesn’t seem to be much hope to get it built.  I also tried the LLVM clang 4.0.1 which is the latest release. That works much better, but there are still issues with C++17 support, some of which are easy to fix (missing template parameters) others not so easy (e.g. there is no support yet for std::cyl_bessel_il). gcc 7 seems to be the better alternative currently.
>>>>>> Best Regards
>>>>>> Peter
>>>>>> 
>>>>>>> On 05 Jul 2017, at 23:03, Hao Zhang <ha...@ha...> wrote:
>>>>>>> 
>>>>>>> Hi Peter,
>>>>>>> 
>>>>>>> As I mentioned in the GitHub README, I have only tested the project with GCC7 on Linux as of now. I plan to make the project compatible with at least Windows and macOS in the near future, but the code will certainly not able to compile on these other platforms before some major changes are made.
>>>>>>> 
>>>>>>> For your specific error, I think the reason is that with GCC the <limits> header is pulled in by <cmath> included by <ql/mathconstants.hpp>. On other platforms <cmath> may not include <limits>. I will include <limits> explicitly in the code, but I'm sure there are many other error messages remaining to be fixed with a non-GCC compiler.
>>>>> 
>>>>>>> 
>>>>>>> Hao
>>>>>>> On Wednesday, July 5, 2017 2:57:07 PM EDT Peter Caspers wrote:
>>>>>>>> Hi Hao, I am trying to build your project (on OSX with clang), I get the following weird error message though. Any idea where this could come from?
>>>>>>>> 
>>>>>>>> make[1]: Entering directory `/Users/peter/QuantLib-noBoost/build'
>>>>>>>> make[2]: Entering directory `/Users/peter/QuantLib-noBoost/build'
>>>>>>>> make[2]: Leaving directory `/Users/peter/QuantLib-noBoost/build'
>>>>>>>> make[2]: Entering directory `/Users/peter/QuantLib-noBoost/build'
>>>>>>>> [  1%] Building CXX object ql/CMakeFiles/QuantLib.dir/cashflow.cpp.o
>>>>>>>> [  1%] Building CXX object ql/CMakeFiles/QuantLib.dir/cashflows/averagebmacoupon.cpp.o
>>>>>>>> [  1%] Building CXX object ql/CMakeFiles/QuantLib.dir/cashflows/capflooredcoupon.cpp.o
>>>>>>>> [  1%] Building CXX object ql/CMakeFiles/QuantLib.dir/cashflows/capflooredinflationcoupon.cpp.o
>>>>>>>> [  1%] Building CXX object ql/CMakeFiles/QuantLib.dir/cashflows/cashflows.cpp.o
>>>>>>>> [  1%] Building CXX object ql/CMakeFiles/QuantLib.dir/cashflows/cashflowvectors.cpp.o
>>>>>>>> [  1%] Building CXX object ql/CMakeFiles/QuantLib.dir/cashflows/cmscoupon.cpp.o
>>>>>>>> [  1%] Building CXX object ql/CMakeFiles/QuantLib.dir/cashflows/conundrumpricer.cpp.o
>>>>>>>> In file included from /Users/peter/QuantLib-noBoost/ql/cashflow.cpp:21:
>>>>>>>> In file included from /Users/peter/QuantLib-noBoost/ql/cashflow.hpp:28:
>>>>>>>> In file included from /Users/peter/QuantLib-noBoost/ql/event.hpp:28:
>>>>>>>> In file included from /Users/peter/QuantLib-noBoost/ql/time/date.hpp:35:
>>>>>>>> /Users/peter/QuantLib-noBoost/ql/utilities/null.hpp:58:24: error: no member named 'numeric_limits' in namespace 'std'
>>>>>>>>             return QL_NULL_REAL;
>>>>>>>>                    ^~~~~~~~~~~~
>>>>>>>> /Users/peter/QuantLib-noBoost/ql/qldefines.hpp:126:39: note: expanded from macro 'QL_NULL_REAL'
>>>>>>>> #define QL_NULL_REAL           ((std::numeric_limits<float>::max)())
>>>>>>>>                              ~~~~~^
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> On 04 Jul 2017, at 21:28, Hao Zhang <ha...@ha...> wrote:
>>>>>>>>> 
>>>>>>>>> Hi Peter and Luigi,
>>>>>>>>> 
>>>>>>>>> Thank you very much for your support! No, the performance gain is not from 
>>>>>>>>> MKL, as MKL is not used in the default setting. I am sorry that I cannot 
>>>>>>>>> pinpoint the exact source of performance gain yet. My hunch is that many 
>>>>>>>>> Boost modules are quite general, and provide features that's not used by 
>>>>>>>>> QuantLib. There are also safety checks in Boost that's not relevant to 
>>>>>>>>> QuantLib. By targeting only QuantLib, I do not need to write many 
>>>>>>>>> redundant features and safety checks, and avoid some extra instructions. 
>>>>>>>>> Also the move semantics in modern C++ may also help with speed. I 
>>>>>>>>> apologize that I cannot answer your question in more detail at this point. 
>>>>>>>>> 
>>>>>>>>> Best Regards,
>>>>>>>>> 
>>>>>>>>> Hao
>>>>>>>>> On Tuesday, July 4, 2017 11:38:00 AM EDT Peter Caspers wrote:
>>>>>>>>>> Hi Hao, that's very interesting. Do you know where the performance gain
>>>>>>>>>> is coming from, is it mostly MKL vs. UBLAS? Or are there other drivers
>>>>>>>>>> as well? I'd also be interested in the motivation to do this in the
>>>>>>>>>> first place, I never thought boost as such was a bad thing? The upgrade
>>>>>>>>>> to C++17 is surely nice and makes sense, no doubt. Best Regards
>>>>>>>>>> Peter
>>>>>>>>>> 
>>>>>>>>>>> On 04 Jul 2017, at 09:42, Luigi Ballabio <lui...@gm...>
>>>>>>>>>>> wrote:
>>>>>>>>>>> 
>>>>>>>>>>> Hello Hao,
>>>>>>>>>>> 
>>>>>>>>>>> that's great news---I've been wondering myself if this was
>>>>>>>>>>> possible.  I'll be sure to check out your project.> 
>>>>>>>>>>> I suggest you also post to quantlib-users for greater exposure.
>>>>>>>>>>> 
>>>>>>>>>>> Later,
>>>>>>>>>>> 
>>>>>>>>>>> Luigi
>>>>>>>>>>> 
>>>>>>>>>>> On Tue, Jul 4, 2017 at 5:24 AM Hao Zhang via QuantLib-dev
>>>>>>>>>>> <qua...@li...
>>>>>>>>>>> <mailto:qua...@li... <mailto:qua...@li...> <mailto:qua...@li... <mailto:qua...@li...>>>> wrote: Hello Everyone,
>>>>>>>>>>> 
>>>>>>>>>>> I have removed all Boost dependency from QuantLib, and ported QuantLib
>>>>>>>>>>> to C++17. The code is hosted on GitHub
>>>>>>>>>>> (https://github.com/haozhangphd/ <https://github.com/haozhangphd/> <https://github.com/haozhangphd/ <https://github.com/haozhangphd/>> QuantLib-noBoost
>>>>>>>>>>> <https://github.com/haozhangphd/QuantLib-noBoost <https://github.com/haozhangphd/QuantLib-noBoost> <https://github.com/haozhangphd/QuantLib-noBoost <https://github.com/haozhangphd/QuantLib-noBoost>>>).
>>>>>>>>>>> 
>>>>>>>>>>> The ported code passes all test cases, and there are significant
>>>>>>>>>>> performance improvements in SOME functionalities. Using the QuantLib
>>>>>>>>>>> Benchmark Suite, Quantlib-noBoost gives 3425 mflops (running time
>>>>>>>>>>> 13.15s), while unmodified QuantLib gives 1440 mflops (running time
>>>>>>>>>>> 44.8s) on my Dell Inspiron 13 i7348 laptop, both running under
>>>>>>>>>>> identical conditions with identical compiler flags. The total running
>>>>>>>>>>> time of the whole test suite is also shorter by ~10% after Boost is
>>>>>>>>>>> removed.
>>>>>>>>>>> 
>>>>>>>>>>> I will continue maintaining this project, and regularly backporting
>>>>>>>>>>> latest commits from QuantLib. I will also make this project work on
>>>>>>>>>>> other compilers besides GCC in the near future.
>>>>>>>>>>> 
>>>>>>>>>>> Best Regards,
>>>>>>>>>>> 
>>>>>>>>>>> Hao
>>>>>>>>>>> 
>>>>>>>>>>> ----------------------------------------------------------------------
>>>>>>>>>>> -------- Check out the vibrant tech community on one of the world's
>>>>>>>>>>> most engaging tech sites, Slashdot.org <http://slashdot.org/> <http://slashdot.org/ <http://slashdot.org/>>! http://sdm.link/slashdot <http://sdm.link/slashdot><http://sdm.link/slashdot <http://sdm.link/slashdot>>
>>>>>>>>>>> <http://sdm.link/slashdot <http://sdm.link/slashdot> <http://sdm.link/slashdot <http://sdm.link/slashdot>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> QuantLib-dev mailing list
>>>>>>>>>>> Qua...@li... <mailto:Qua...@li...> <mailto:Qua...@li... <mailto:Qua...@li...>>
>>>>>>>>>>> <mailto:Qua...@li... <mailto:Qua...@li...> <mailto:Qua...@li... <mailto:Qua...@li...>>>
>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev <https://lists.sourceforge.net/lists/listinfo/quantlib-dev> <https://lists.sourceforge.net/lists/listinfo/quantlib-dev <https://lists.sourceforge.net/lists/listinfo/quantlib-dev>>
>>>>>>>>>>> <https://lists.sourceforge.net/lists/listinfo/quantlib-dev>
>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>> --------- Check out the vibrant tech community on one of the world's
>>>>>>>>>>> most engaging tech sites, Slashdot.org!
>>>>>>>>>>> http://sdm.link/slashdot_____________________________________________
>>>>>>>>>>> __ QuantLib-dev mailing list
>>>>>>>>>>> Qua...@li...
>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>>>>>> 
>>>>> 
>>>>> 
>>>> 
>>> 
>>> 
>> 
> 
> 

Re: [Quantlib-dev] Removing Boost dependency from QuantLib

[Hao Z. <ha...@ha...>]

Hi Peter,

Thank you very much for helping. So the earlier benchmark results were clearly wrong. I really apologize for the overstated benchmark results. That was not intentional and I have removed the overstated values from README.md.

Best Regards,

Hao
On Sunday, July 9, 2017 8:50:01 AM EDT Peter Caspers wrote:
> Thanks a lot Hao, it also builds on OS X now. I looked a bit closer at the benchmark results and I think there is an issue in the port of the code to catch, causing the first case to be executed n times instead of each of the n original cases once. I’ll send a merge request with a fix.
> Best Regards, Peter
> 
> > On 09 Jul 2017, at 01:51, Hao Zhang <ha...@ha...> wrote:
> > 
> > Hi Peter,
> > 
> > Thank you for your suggestion. The code now compiles and runs under Clang 4 and libc++ 4.
> > 
> > Best Regards,
> > 
> > Hao
> > On Saturday, July 8, 2017 2:33:17 AM MDT you wrote:
> >> Hi Hao,
> >> 
> >> in my opinion cyl_bessel_il is a case where it would be natural to use its precursor in boost for compilers that do not yet support it in C++17 (i.e. have a check in the configure step for this). After a while you could just switch to the std:: version without much ado. But that’s again going back to my original question about avoiding boost for its own sake vs modernising the code to more recent C++ standards.
> >> 
> >> For clang you can check out its source code and build the latest release (or even the current master) on Linux yourself. That works well for me on Ubuntu. I guess when your QuantLib-noBoost builds with clang on Linux there won’t be issues on OS X (with the LLVM clang) either.
> >> 
> >> I would still be most interested in where the performance gain comes from exactly and if we can benefit from it in QuantLib classic as well, without C++17: It’s easy to say, let’s allow for 11, 14, 17, but there are still places where you have to work with MSVC 2010. In this situation you are happy that QL is still on 03 and you don’t have to backport it or use an older version. I’d be in favour of allowing 11 in QuantLib classic, but ideally maintaining a 03 branch which receives bug fixes, calendar updates etc.
> >> 
> >> Best Regards
> >> Peter
> >> 
> >>> On 07 Jul 2017, at 22:50, Hao Zhang <ha...@ha...> wrote:
> >>> 
> >>> Hi Peter,
> >>> 
> >>> I just removed some GCC-specific code, and made it compile and run under Visual Studio 2017. Unfortunately I do not have access to a Mac, thus I cannot do any testing on macOS. If you have time, can you please try compiling the code again on Mac and send me the error message? I suppose Clang is more similar to GCC than to MSVC, thus if MSVC accept the code, making it run with Clang shouldn't be that hard...  
> >>> 
> >>> P.S. std::cyl_bessel_il is not too difficult to overcome. We already have modifiedBesselFunction_i and modifiedBesselFunction_k implemented in QuantLib. These functions just need to be modified for cases when the arguments become very large.
> >>> 
> >>> Thanks and Best Regards,
> >>> 
> >>> Hao
> >>> On Friday, July 7, 2017 2:23:00 PM EDT Peter Caspers wrote:
> >>>> Hi Hao, with the standard compiler on OS X El Capitan (Apple clang 8.0.0) there doesn’t seem to be much hope to get it built.  I also tried the LLVM clang 4.0.1 which is the latest release. That works much better, but there are still issues with C++17 support, some of which are easy to fix (missing template parameters) others not so easy (e.g. there is no support yet for std::cyl_bessel_il). gcc 7 seems to be the better alternative currently.
> >>>> Best Regards
> >>>> Peter
> >>>> 
> >>>>> On 05 Jul 2017, at 23:03, Hao Zhang <ha...@ha...> wrote:
> >>>>> 
> >>>>> Hi Peter,
> >>>>> 
> >>>>> As I mentioned in the GitHub README, I have only tested the project with GCC7 on Linux as of now. I plan to make the project compatible with at least Windows and macOS in the near future, but the code will certainly not able to compile on these other platforms before some major changes are made.
> >>>>> 
> >>>>> For your specific error, I think the reason is that with GCC the <limits> header is pulled in by <cmath> included by <ql/mathconstants.hpp>. On other platforms <cmath> may not include <limits>. I will include <limits> explicitly in the code, but I'm sure there are many other error messages remaining to be fixed with a non-GCC compiler.
> >>> 
> >>>>> 
> >>>>> Hao
> >>>>> On Wednesday, July 5, 2017 2:57:07 PM EDT Peter Caspers wrote:
> >>>>>> Hi Hao, I am trying to build your project (on OSX with clang), I get the following weird error message though. Any idea where this could come from?
> >>>>>> 
> >>>>>> make[1]: Entering directory `/Users/peter/QuantLib-noBoost/build'
> >>>>>> make[2]: Entering directory `/Users/peter/QuantLib-noBoost/build'
> >>>>>> make[2]: Leaving directory `/Users/peter/QuantLib-noBoost/build'
> >>>>>> make[2]: Entering directory `/Users/peter/QuantLib-noBoost/build'
> >>>>>> [  1%] Building CXX object ql/CMakeFiles/QuantLib.dir/cashflow.cpp.o
> >>>>>> [  1%] Building CXX object ql/CMakeFiles/QuantLib.dir/cashflows/averagebmacoupon.cpp.o
> >>>>>> [  1%] Building CXX object ql/CMakeFiles/QuantLib.dir/cashflows/capflooredcoupon.cpp.o
> >>>>>> [  1%] Building CXX object ql/CMakeFiles/QuantLib.dir/cashflows/capflooredinflationcoupon.cpp.o
> >>>>>> [  1%] Building CXX object ql/CMakeFiles/QuantLib.dir/cashflows/cashflows.cpp.o
> >>>>>> [  1%] Building CXX object ql/CMakeFiles/QuantLib.dir/cashflows/cashflowvectors.cpp.o
> >>>>>> [  1%] Building CXX object ql/CMakeFiles/QuantLib.dir/cashflows/cmscoupon.cpp.o
> >>>>>> [  1%] Building CXX object ql/CMakeFiles/QuantLib.dir/cashflows/conundrumpricer.cpp.o
> >>>>>> In file included from /Users/peter/QuantLib-noBoost/ql/cashflow.cpp:21:
> >>>>>> In file included from /Users/peter/QuantLib-noBoost/ql/cashflow.hpp:28:
> >>>>>> In file included from /Users/peter/QuantLib-noBoost/ql/event.hpp:28:
> >>>>>> In file included from /Users/peter/QuantLib-noBoost/ql/time/date.hpp:35:
> >>>>>> /Users/peter/QuantLib-noBoost/ql/utilities/null.hpp:58:24: error: no member named 'numeric_limits' in namespace 'std'
> >>>>>>              return QL_NULL_REAL;
> >>>>>>                     ^~~~~~~~~~~~
> >>>>>> /Users/peter/QuantLib-noBoost/ql/qldefines.hpp:126:39: note: expanded from macro 'QL_NULL_REAL'
> >>>>>> #define QL_NULL_REAL           ((std::numeric_limits<float>::max)())
> >>>>>>                               ~~~~~^
> >>>>>> 
> >>>>>> 
> >>>>>>> On 04 Jul 2017, at 21:28, Hao Zhang <ha...@ha...> wrote:
> >>>>>>> 
> >>>>>>> Hi Peter and Luigi,
> >>>>>>> 
> >>>>>>> Thank you very much for your support! No, the performance gain is not from 
> >>>>>>> MKL, as MKL is not used in the default setting. I am sorry that I cannot 
> >>>>>>> pinpoint the exact source of performance gain yet. My hunch is that many 
> >>>>>>> Boost modules are quite general, and provide features that's not used by 
> >>>>>>> QuantLib. There are also safety checks in Boost that's not relevant to 
> >>>>>>> QuantLib. By targeting only QuantLib, I do not need to write many 
> >>>>>>> redundant features and safety checks, and avoid some extra instructions. 
> >>>>>>> Also the move semantics in modern C++ may also help with speed. I 
> >>>>>>> apologize that I cannot answer your question in more detail at this point. 
> >>>>>>> 
> >>>>>>> Best Regards,
> >>>>>>> 
> >>>>>>> Hao
> >>>>>>> On Tuesday, July 4, 2017 11:38:00 AM EDT Peter Caspers wrote:
> >>>>>>>> Hi Hao, that's very interesting. Do you know where the performance gain
> >>>>>>>> is coming from, is it mostly MKL vs. UBLAS? Or are there other drivers
> >>>>>>>> as well? I'd also be interested in the motivation to do this in the
> >>>>>>>> first place, I never thought boost as such was a bad thing? The upgrade
> >>>>>>>> to C++17 is surely nice and makes sense, no doubt. Best Regards
> >>>>>>>> Peter
> >>>>>>>> 
> >>>>>>>>> On 04 Jul 2017, at 09:42, Luigi Ballabio <lui...@gm...>
> >>>>>>>>> wrote:
> >>>>>>>>> 
> >>>>>>>>> Hello Hao,
> >>>>>>>>> 
> >>>>>>>>> that's great news---I've been wondering myself if this was
> >>>>>>>>> possible.  I'll be sure to check out your project.> 
> >>>>>>>>> I suggest you also post to quantlib-users for greater exposure.
> >>>>>>>>> 
> >>>>>>>>> Later,
> >>>>>>>>> 
> >>>>>>>>> Luigi
> >>>>>>>>> 
> >>>>>>>>> On Tue, Jul 4, 2017 at 5:24 AM Hao Zhang via QuantLib-dev
> >>>>>>>>> <qua...@li...
> >>>>>>>>> <mailto:qua...@li... <mailto:qua...@li...> <mailto:qua...@li... <mailto:qua...@li...>>>> wrote: Hello Everyone,
> >>>>>>>>> 
> >>>>>>>>> I have removed all Boost dependency from QuantLib, and ported QuantLib
> >>>>>>>>> to C++17. The code is hosted on GitHub
> >>>>>>>>> (https://github.com/haozhangphd/ <https://github.com/haozhangphd/> <https://github.com/haozhangphd/ <https://github.com/haozhangphd/>> QuantLib-noBoost
> >>>>>>>>> <https://github.com/haozhangphd/QuantLib-noBoost <https://github.com/haozhangphd/QuantLib-noBoost> <https://github.com/haozhangphd/QuantLib-noBoost <https://github.com/haozhangphd/QuantLib-noBoost>>>).
> >>>>>>>>> 
> >>>>>>>>> The ported code passes all test cases, and there are significant
> >>>>>>>>> performance improvements in SOME functionalities. Using the QuantLib
> >>>>>>>>> Benchmark Suite, Quantlib-noBoost gives 3425 mflops (running time
> >>>>>>>>> 13.15s), while unmodified QuantLib gives 1440 mflops (running time
> >>>>>>>>> 44.8s) on my Dell Inspiron 13 i7348 laptop, both running under
> >>>>>>>>> identical conditions with identical compiler flags. The total running
> >>>>>>>>> time of the whole test suite is also shorter by ~10% after Boost is
> >>>>>>>>> removed.
> >>>>>>>>> 
> >>>>>>>>> I will continue maintaining this project, and regularly backporting
> >>>>>>>>> latest commits from QuantLib. I will also make this project work on
> >>>>>>>>> other compilers besides GCC in the near future.
> >>>>>>>>> 
> >>>>>>>>> Best Regards,
> >>>>>>>>> 
> >>>>>>>>> Hao
> >>>>>>>>> 
> >>>>>>>>> ----------------------------------------------------------------------
> >>>>>>>>> -------- Check out the vibrant tech community on one of the world's
> >>>>>>>>> most engaging tech sites, Slashdot.org <http://slashdot.org/> <http://slashdot.org/ <http://slashdot.org/>>! http://sdm.link/slashdot <http://sdm.link/slashdot><http://sdm.link/slashdot <http://sdm.link/slashdot>>
> >>>>>>>>> <http://sdm.link/slashdot <http://sdm.link/slashdot> <http://sdm.link/slashdot <http://sdm.link/slashdot>>>
> >>>>>>>>> _______________________________________________
> >>>>>>>>> QuantLib-dev mailing list
> >>>>>>>>> Qua...@li... <mailto:Qua...@li...> <mailto:Qua...@li... <mailto:Qua...@li...>>
> >>>>>>>>> <mailto:Qua...@li... <mailto:Qua...@li...> <mailto:Qua...@li... <mailto:Qua...@li...>>>
> >>>>>>>>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev <https://lists.sourceforge.net/lists/listinfo/quantlib-dev> <https://lists.sourceforge.net/lists/listinfo/quantlib-dev <https://lists.sourceforge.net/lists/listinfo/quantlib-dev>>
> >>>>>>>>> <https://lists.sourceforge.net/lists/listinfo/quantlib-dev>
> >>>>>>>>> ---------------------------------------------------------------------
> >>>>>>>>> --------- Check out the vibrant tech community on one of the world's
> >>>>>>>>> most engaging tech sites, Slashdot.org!
> >>>>>>>>> http://sdm.link/slashdot_____________________________________________
> >>>>>>>>> __ QuantLib-dev mailing list
> >>>>>>>>> Qua...@li...
> >>>>>>>>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
> >>>> 
> >>> 
> >>> 
> >> 
> > 
> > 
> 

Re: [Quantlib-dev] Removing Boost dependency from QuantLib

[Peter C. <pca...@gm...>]

Thanks a lot Hao, it also builds on OS X now. I looked a bit closer at the benchmark results and I think there is an issue in the port of the code to catch, causing the first case to be executed n times instead of each of the n original cases once. I’ll send a merge request with a fix.
Best Regards, Peter

> On 09 Jul 2017, at 01:51, Hao Zhang <ha...@ha...> wrote:
> 
> Hi Peter,
> 
> Thank you for your suggestion. The code now compiles and runs under Clang 4 and libc++ 4.
> 
> Best Regards,
> 
> Hao
> On Saturday, July 8, 2017 2:33:17 AM MDT you wrote:
>> Hi Hao,
>> 
>> in my opinion cyl_bessel_il is a case where it would be natural to use its precursor in boost for compilers that do not yet support it in C++17 (i.e. have a check in the configure step for this). After a while you could just switch to the std:: version without much ado. But that’s again going back to my original question about avoiding boost for its own sake vs modernising the code to more recent C++ standards.
>> 
>> For clang you can check out its source code and build the latest release (or even the current master) on Linux yourself. That works well for me on Ubuntu. I guess when your QuantLib-noBoost builds with clang on Linux there won’t be issues on OS X (with the LLVM clang) either.
>> 
>> I would still be most interested in where the performance gain comes from exactly and if we can benefit from it in QuantLib classic as well, without C++17: It’s easy to say, let’s allow for 11, 14, 17, but there are still places where you have to work with MSVC 2010. In this situation you are happy that QL is still on 03 and you don’t have to backport it or use an older version. I’d be in favour of allowing 11 in QuantLib classic, but ideally maintaining a 03 branch which receives bug fixes, calendar updates etc.
>> 
>> Best Regards
>> Peter
>> 
>>> On 07 Jul 2017, at 22:50, Hao Zhang <ha...@ha...> wrote:
>>> 
>>> Hi Peter,
>>> 
>>> I just removed some GCC-specific code, and made it compile and run under Visual Studio 2017. Unfortunately I do not have access to a Mac, thus I cannot do any testing on macOS. If you have time, can you please try compiling the code again on Mac and send me the error message? I suppose Clang is more similar to GCC than to MSVC, thus if MSVC accept the code, making it run with Clang shouldn't be that hard...  
>>> 
>>> P.S. std::cyl_bessel_il is not too difficult to overcome. We already have modifiedBesselFunction_i and modifiedBesselFunction_k implemented in QuantLib. These functions just need to be modified for cases when the arguments become very large.
>>> 
>>> Thanks and Best Regards,
>>> 
>>> Hao
>>> On Friday, July 7, 2017 2:23:00 PM EDT Peter Caspers wrote:
>>>> Hi Hao, with the standard compiler on OS X El Capitan (Apple clang 8.0.0) there doesn’t seem to be much hope to get it built.  I also tried the LLVM clang 4.0.1 which is the latest release. That works much better, but there are still issues with C++17 support, some of which are easy to fix (missing template parameters) others not so easy (e.g. there is no support yet for std::cyl_bessel_il). gcc 7 seems to be the better alternative currently.
>>>> Best Regards
>>>> Peter
>>>> 
>>>>> On 05 Jul 2017, at 23:03, Hao Zhang <ha...@ha...> wrote:
>>>>> 
>>>>> Hi Peter,
>>>>> 
>>>>> As I mentioned in the GitHub README, I have only tested the project with GCC7 on Linux as of now. I plan to make the project compatible with at least Windows and macOS in the near future, but the code will certainly not able to compile on these other platforms before some major changes are made.
>>>>> 
>>>>> For your specific error, I think the reason is that with GCC the <limits> header is pulled in by <cmath> included by <ql/mathconstants.hpp>. On other platforms <cmath> may not include <limits>. I will include <limits> explicitly in the code, but I'm sure there are many other error messages remaining to be fixed with a non-GCC compiler.
>>> 
>>>>> 
>>>>> Hao
>>>>> On Wednesday, July 5, 2017 2:57:07 PM EDT Peter Caspers wrote:
>>>>>> Hi Hao, I am trying to build your project (on OSX with clang), I get the following weird error message though. Any idea where this could come from?
>>>>>> 
>>>>>> make[1]: Entering directory `/Users/peter/QuantLib-noBoost/build'
>>>>>> make[2]: Entering directory `/Users/peter/QuantLib-noBoost/build'
>>>>>> make[2]: Leaving directory `/Users/peter/QuantLib-noBoost/build'
>>>>>> make[2]: Entering directory `/Users/peter/QuantLib-noBoost/build'
>>>>>> [  1%] Building CXX object ql/CMakeFiles/QuantLib.dir/cashflow.cpp.o
>>>>>> [  1%] Building CXX object ql/CMakeFiles/QuantLib.dir/cashflows/averagebmacoupon.cpp.o
>>>>>> [  1%] Building CXX object ql/CMakeFiles/QuantLib.dir/cashflows/capflooredcoupon.cpp.o
>>>>>> [  1%] Building CXX object ql/CMakeFiles/QuantLib.dir/cashflows/capflooredinflationcoupon.cpp.o
>>>>>> [  1%] Building CXX object ql/CMakeFiles/QuantLib.dir/cashflows/cashflows.cpp.o
>>>>>> [  1%] Building CXX object ql/CMakeFiles/QuantLib.dir/cashflows/cashflowvectors.cpp.o
>>>>>> [  1%] Building CXX object ql/CMakeFiles/QuantLib.dir/cashflows/cmscoupon.cpp.o
>>>>>> [  1%] Building CXX object ql/CMakeFiles/QuantLib.dir/cashflows/conundrumpricer.cpp.o
>>>>>> In file included from /Users/peter/QuantLib-noBoost/ql/cashflow.cpp:21:
>>>>>> In file included from /Users/peter/QuantLib-noBoost/ql/cashflow.hpp:28:
>>>>>> In file included from /Users/peter/QuantLib-noBoost/ql/event.hpp:28:
>>>>>> In file included from /Users/peter/QuantLib-noBoost/ql/time/date.hpp:35:
>>>>>> /Users/peter/QuantLib-noBoost/ql/utilities/null.hpp:58:24: error: no member named 'numeric_limits' in namespace 'std'
>>>>>>              return QL_NULL_REAL;
>>>>>>                     ^~~~~~~~~~~~
>>>>>> /Users/peter/QuantLib-noBoost/ql/qldefines.hpp:126:39: note: expanded from macro 'QL_NULL_REAL'
>>>>>> #define QL_NULL_REAL           ((std::numeric_limits<float>::max)())
>>>>>>                               ~~~~~^
>>>>>> 
>>>>>> 
>>>>>>> On 04 Jul 2017, at 21:28, Hao Zhang <ha...@ha...> wrote:
>>>>>>> 
>>>>>>> Hi Peter and Luigi,
>>>>>>> 
>>>>>>> Thank you very much for your support! No, the performance gain is not from 
>>>>>>> MKL, as MKL is not used in the default setting. I am sorry that I cannot 
>>>>>>> pinpoint the exact source of performance gain yet. My hunch is that many 
>>>>>>> Boost modules are quite general, and provide features that's not used by 
>>>>>>> QuantLib. There are also safety checks in Boost that's not relevant to 
>>>>>>> QuantLib. By targeting only QuantLib, I do not need to write many 
>>>>>>> redundant features and safety checks, and avoid some extra instructions. 
>>>>>>> Also the move semantics in modern C++ may also help with speed. I 
>>>>>>> apologize that I cannot answer your question in more detail at this point. 
>>>>>>> 
>>>>>>> Best Regards,
>>>>>>> 
>>>>>>> Hao
>>>>>>> On Tuesday, July 4, 2017 11:38:00 AM EDT Peter Caspers wrote:
>>>>>>>> Hi Hao, that's very interesting. Do you know where the performance gain
>>>>>>>> is coming from, is it mostly MKL vs. UBLAS? Or are there other drivers
>>>>>>>> as well? I'd also be interested in the motivation to do this in the
>>>>>>>> first place, I never thought boost as such was a bad thing? The upgrade
>>>>>>>> to C++17 is surely nice and makes sense, no doubt. Best Regards
>>>>>>>> Peter
>>>>>>>> 
>>>>>>>>> On 04 Jul 2017, at 09:42, Luigi Ballabio <lui...@gm...>
>>>>>>>>> wrote:
>>>>>>>>> 
>>>>>>>>> Hello Hao,
>>>>>>>>> 
>>>>>>>>> that's great news---I've been wondering myself if this was
>>>>>>>>> possible.  I'll be sure to check out your project.> 
>>>>>>>>> I suggest you also post to quantlib-users for greater exposure.
>>>>>>>>> 
>>>>>>>>> Later,
>>>>>>>>> 
>>>>>>>>> Luigi
>>>>>>>>> 
>>>>>>>>> On Tue, Jul 4, 2017 at 5:24 AM Hao Zhang via QuantLib-dev
>>>>>>>>> <qua...@li...
>>>>>>>>> <mailto:qua...@li... <mailto:qua...@li...> <mailto:qua...@li... <mailto:qua...@li...>>>> wrote: Hello Everyone,
>>>>>>>>> 
>>>>>>>>> I have removed all Boost dependency from QuantLib, and ported QuantLib
>>>>>>>>> to C++17. The code is hosted on GitHub
>>>>>>>>> (https://github.com/haozhangphd/ <https://github.com/haozhangphd/> <https://github.com/haozhangphd/ <https://github.com/haozhangphd/>> QuantLib-noBoost
>>>>>>>>> <https://github.com/haozhangphd/QuantLib-noBoost <https://github.com/haozhangphd/QuantLib-noBoost> <https://github.com/haozhangphd/QuantLib-noBoost <https://github.com/haozhangphd/QuantLib-noBoost>>>).
>>>>>>>>> 
>>>>>>>>> The ported code passes all test cases, and there are significant
>>>>>>>>> performance improvements in SOME functionalities. Using the QuantLib
>>>>>>>>> Benchmark Suite, Quantlib-noBoost gives 3425 mflops (running time
>>>>>>>>> 13.15s), while unmodified QuantLib gives 1440 mflops (running time
>>>>>>>>> 44.8s) on my Dell Inspiron 13 i7348 laptop, both running under
>>>>>>>>> identical conditions with identical compiler flags. The total running
>>>>>>>>> time of the whole test suite is also shorter by ~10% after Boost is
>>>>>>>>> removed.
>>>>>>>>> 
>>>>>>>>> I will continue maintaining this project, and regularly backporting
>>>>>>>>> latest commits from QuantLib. I will also make this project work on
>>>>>>>>> other compilers besides GCC in the near future.
>>>>>>>>> 
>>>>>>>>> Best Regards,
>>>>>>>>> 
>>>>>>>>> Hao
>>>>>>>>> 
>>>>>>>>> ----------------------------------------------------------------------
>>>>>>>>> -------- Check out the vibrant tech community on one of the world's
>>>>>>>>> most engaging tech sites, Slashdot.org <http://slashdot.org/> <http://slashdot.org/ <http://slashdot.org/>>! http://sdm.link/slashdot <http://sdm.link/slashdot><http://sdm.link/slashdot <http://sdm.link/slashdot>>
>>>>>>>>> <http://sdm.link/slashdot <http://sdm.link/slashdot> <http://sdm.link/slashdot <http://sdm.link/slashdot>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> QuantLib-dev mailing list
>>>>>>>>> Qua...@li... <mailto:Qua...@li...> <mailto:Qua...@li... <mailto:Qua...@li...>>
>>>>>>>>> <mailto:Qua...@li... <mailto:Qua...@li...> <mailto:Qua...@li... <mailto:Qua...@li...>>>
>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev <https://lists.sourceforge.net/lists/listinfo/quantlib-dev> <https://lists.sourceforge.net/lists/listinfo/quantlib-dev <https://lists.sourceforge.net/lists/listinfo/quantlib-dev>>
>>>>>>>>> <https://lists.sourceforge.net/lists/listinfo/quantlib-dev>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> --------- Check out the vibrant tech community on one of the world's
>>>>>>>>> most engaging tech sites, Slashdot.org!
>>>>>>>>> http://sdm.link/slashdot_____________________________________________
>>>>>>>>> __ QuantLib-dev mailing list
>>>>>>>>> Qua...@li...
>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>>>> 
>>> 
>>> 
>> 
> 
> 

Re: [Quantlib-dev] Removing Boost dependency from QuantLib

[Hao Z. <ha...@ha...>]

Hi Peter,

Thank you for your suggestion. The code now compiles and runs under Clang 4 and libc++ 4.

Best Regards,

Hao
On Saturday, July 8, 2017 2:33:17 AM MDT you wrote:
> Hi Hao,
> 
> in my opinion cyl_bessel_il is a case where it would be natural to use its precursor in boost for compilers that do not yet support it in C++17 (i.e. have a check in the configure step for this). After a while you could just switch to the std:: version without much ado. But that’s again going back to my original question about avoiding boost for its own sake vs modernising the code to more recent C++ standards.
> 
> For clang you can check out its source code and build the latest release (or even the current master) on Linux yourself. That works well for me on Ubuntu. I guess when your QuantLib-noBoost builds with clang on Linux there won’t be issues on OS X (with the LLVM clang) either.
> 
> I would still be most interested in where the performance gain comes from exactly and if we can benefit from it in QuantLib classic as well, without C++17: It’s easy to say, let’s allow for 11, 14, 17, but there are still places where you have to work with MSVC 2010. In this situation you are happy that QL is still on 03 and you don’t have to backport it or use an older version. I’d be in favour of allowing 11 in QuantLib classic, but ideally maintaining a 03 branch which receives bug fixes, calendar updates etc.
> 
> Best Regards
> Peter
> 
> > On 07 Jul 2017, at 22:50, Hao Zhang <ha...@ha...> wrote:
> > 
> > Hi Peter,
> > 
> > I just removed some GCC-specific code, and made it compile and run under Visual Studio 2017. Unfortunately I do not have access to a Mac, thus I cannot do any testing on macOS. If you have time, can you please try compiling the code again on Mac and send me the error message? I suppose Clang is more similar to GCC than to MSVC, thus if MSVC accept the code, making it run with Clang shouldn't be that hard...  
> > 
> > P.S. std::cyl_bessel_il is not too difficult to overcome. We already have modifiedBesselFunction_i and modifiedBesselFunction_k implemented in QuantLib. These functions just need to be modified for cases when the arguments become very large.
> > 
> > Thanks and Best Regards,
> > 
> > Hao
> > On Friday, July 7, 2017 2:23:00 PM EDT Peter Caspers wrote:
> >> Hi Hao, with the standard compiler on OS X El Capitan (Apple clang 8.0.0) there doesn’t seem to be much hope to get it built.  I also tried the LLVM clang 4.0.1 which is the latest release. That works much better, but there are still issues with C++17 support, some of which are easy to fix (missing template parameters) others not so easy (e.g. there is no support yet for std::cyl_bessel_il). gcc 7 seems to be the better alternative currently.
> >> Best Regards
> >> Peter
> >> 
> >>> On 05 Jul 2017, at 23:03, Hao Zhang <ha...@ha...> wrote:
> >>> 
> >>> Hi Peter,
> >>> 
> >>> As I mentioned in the GitHub README, I have only tested the project with GCC7 on Linux as of now. I plan to make the project compatible with at least Windows and macOS in the near future, but the code will certainly not able to compile on these other platforms before some major changes are made.
> >>> 
> >>> For your specific error, I think the reason is that with GCC the <limits> header is pulled in by <cmath> included by <ql/mathconstants.hpp>. On other platforms <cmath> may not include <limits>. I will include <limits> explicitly in the code, but I'm sure there are many other error messages remaining to be fixed with a non-GCC compiler.
> > 
> >>> 
> >>> Hao
> >>> On Wednesday, July 5, 2017 2:57:07 PM EDT Peter Caspers wrote:
> >>>> Hi Hao, I am trying to build your project (on OSX with clang), I get the following weird error message though. Any idea where this could come from?
> >>>> 
> >>>> make[1]: Entering directory `/Users/peter/QuantLib-noBoost/build'
> >>>> make[2]: Entering directory `/Users/peter/QuantLib-noBoost/build'
> >>>> make[2]: Leaving directory `/Users/peter/QuantLib-noBoost/build'
> >>>> make[2]: Entering directory `/Users/peter/QuantLib-noBoost/build'
> >>>> [  1%] Building CXX object ql/CMakeFiles/QuantLib.dir/cashflow.cpp.o
> >>>> [  1%] Building CXX object ql/CMakeFiles/QuantLib.dir/cashflows/averagebmacoupon.cpp.o
> >>>> [  1%] Building CXX object ql/CMakeFiles/QuantLib.dir/cashflows/capflooredcoupon.cpp.o
> >>>> [  1%] Building CXX object ql/CMakeFiles/QuantLib.dir/cashflows/capflooredinflationcoupon.cpp.o
> >>>> [  1%] Building CXX object ql/CMakeFiles/QuantLib.dir/cashflows/cashflows.cpp.o
> >>>> [  1%] Building CXX object ql/CMakeFiles/QuantLib.dir/cashflows/cashflowvectors.cpp.o
> >>>> [  1%] Building CXX object ql/CMakeFiles/QuantLib.dir/cashflows/cmscoupon.cpp.o
> >>>> [  1%] Building CXX object ql/CMakeFiles/QuantLib.dir/cashflows/conundrumpricer.cpp.o
> >>>> In file included from /Users/peter/QuantLib-noBoost/ql/cashflow.cpp:21:
> >>>> In file included from /Users/peter/QuantLib-noBoost/ql/cashflow.hpp:28:
> >>>> In file included from /Users/peter/QuantLib-noBoost/ql/event.hpp:28:
> >>>> In file included from /Users/peter/QuantLib-noBoost/ql/time/date.hpp:35:
> >>>> /Users/peter/QuantLib-noBoost/ql/utilities/null.hpp:58:24: error: no member named 'numeric_limits' in namespace 'std'
> >>>>               return QL_NULL_REAL;
> >>>>                      ^~~~~~~~~~~~
> >>>> /Users/peter/QuantLib-noBoost/ql/qldefines.hpp:126:39: note: expanded from macro 'QL_NULL_REAL'
> >>>> #define QL_NULL_REAL           ((std::numeric_limits<float>::max)())
> >>>>                                ~~~~~^
> >>>> 
> >>>> 
> >>>>> On 04 Jul 2017, at 21:28, Hao Zhang <ha...@ha...> wrote:
> >>>>> 
> >>>>> Hi Peter and Luigi,
> >>>>> 
> >>>>> Thank you very much for your support! No, the performance gain is not from 
> >>>>> MKL, as MKL is not used in the default setting. I am sorry that I cannot 
> >>>>> pinpoint the exact source of performance gain yet. My hunch is that many 
> >>>>> Boost modules are quite general, and provide features that's not used by 
> >>>>> QuantLib. There are also safety checks in Boost that's not relevant to 
> >>>>> QuantLib. By targeting only QuantLib, I do not need to write many 
> >>>>> redundant features and safety checks, and avoid some extra instructions. 
> >>>>> Also the move semantics in modern C++ may also help with speed. I 
> >>>>> apologize that I cannot answer your question in more detail at this point. 
> >>>>> 
> >>>>> Best Regards,
> >>>>> 
> >>>>> Hao
> >>>>> On Tuesday, July 4, 2017 11:38:00 AM EDT Peter Caspers wrote:
> >>>>>> Hi Hao, that's very interesting. Do you know where the performance gain
> >>>>>> is coming from, is it mostly MKL vs. UBLAS? Or are there other drivers
> >>>>>> as well? I'd also be interested in the motivation to do this in the
> >>>>>> first place, I never thought boost as such was a bad thing? The upgrade
> >>>>>> to C++17 is surely nice and makes sense, no doubt. Best Regards
> >>>>>> Peter
> >>>>>> 
> >>>>>>> On 04 Jul 2017, at 09:42, Luigi Ballabio <lui...@gm...>
> >>>>>>> wrote:
> >>>>>>> 
> >>>>>>> Hello Hao,
> >>>>>>> 
> >>>>>>>  that's great news---I've been wondering myself if this was
> >>>>>>>  possible.  I'll be sure to check out your project.> 
> >>>>>>> I suggest you also post to quantlib-users for greater exposure.
> >>>>>>> 
> >>>>>>> Later,
> >>>>>>> 
> >>>>>>>  Luigi
> >>>>>>> 
> >>>>>>> On Tue, Jul 4, 2017 at 5:24 AM Hao Zhang via QuantLib-dev
> >>>>>>> <qua...@li...
> >>>>>>> <mailto:qua...@li... <mailto:qua...@li...> <mailto:qua...@li... <mailto:qua...@li...>>>> wrote: Hello Everyone,
> >>>>>>> 
> >>>>>>> I have removed all Boost dependency from QuantLib, and ported QuantLib
> >>>>>>> to C++17. The code is hosted on GitHub
> >>>>>>> (https://github.com/haozhangphd/ <https://github.com/haozhangphd/> <https://github.com/haozhangphd/ <https://github.com/haozhangphd/>> QuantLib-noBoost
> >>>>>>> <https://github.com/haozhangphd/QuantLib-noBoost <https://github.com/haozhangphd/QuantLib-noBoost> <https://github.com/haozhangphd/QuantLib-noBoost <https://github.com/haozhangphd/QuantLib-noBoost>>>).
> >>>>>>> 
> >>>>>>> The ported code passes all test cases, and there are significant
> >>>>>>> performance improvements in SOME functionalities. Using the QuantLib
> >>>>>>> Benchmark Suite, Quantlib-noBoost gives 3425 mflops (running time
> >>>>>>> 13.15s), while unmodified QuantLib gives 1440 mflops (running time
> >>>>>>> 44.8s) on my Dell Inspiron 13 i7348 laptop, both running under
> >>>>>>> identical conditions with identical compiler flags. The total running
> >>>>>>> time of the whole test suite is also shorter by ~10% after Boost is
> >>>>>>> removed.
> >>>>>>> 
> >>>>>>> I will continue maintaining this project, and regularly backporting
> >>>>>>> latest commits from QuantLib. I will also make this project work on
> >>>>>>> other compilers besides GCC in the near future.
> >>>>>>> 
> >>>>>>> Best Regards,
> >>>>>>> 
> >>>>>>> Hao
> >>>>>>> 
> >>>>>>> ----------------------------------------------------------------------
> >>>>>>> -------- Check out the vibrant tech community on one of the world's
> >>>>>>> most engaging tech sites, Slashdot.org <http://slashdot.org/> <http://slashdot.org/ <http://slashdot.org/>>! http://sdm.link/slashdot <http://sdm.link/slashdot><http://sdm.link/slashdot <http://sdm.link/slashdot>>
> >>>>>>> <http://sdm.link/slashdot <http://sdm.link/slashdot> <http://sdm.link/slashdot <http://sdm.link/slashdot>>>
> >>>>>>> _______________________________________________
> >>>>>>> QuantLib-dev mailing list
> >>>>>>> Qua...@li... <mailto:Qua...@li...> <mailto:Qua...@li... <mailto:Qua...@li...>>
> >>>>>>> <mailto:Qua...@li... <mailto:Qua...@li...> <mailto:Qua...@li... <mailto:Qua...@li...>>>
> >>>>>>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev <https://lists.sourceforge.net/lists/listinfo/quantlib-dev> <https://lists.sourceforge.net/lists/listinfo/quantlib-dev <https://lists.sourceforge.net/lists/listinfo/quantlib-dev>>
> >>>>>>> <https://lists.sourceforge.net/lists/listinfo/quantlib-dev>
> >>>>>>> ---------------------------------------------------------------------
> >>>>>>> --------- Check out the vibrant tech community on one of the world's
> >>>>>>> most engaging tech sites, Slashdot.org!
> >>>>>>> http://sdm.link/slashdot_____________________________________________
> >>>>>>> __ QuantLib-dev mailing list
> >>>>>>> Qua...@li...
> >>>>>>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
> >> 
> > 
> > 
> 

Re: [Quantlib-dev] Removing Boost dependency from QuantLib

[Peter C. <pca...@gm...>]

Hi Hao,

in my opinion cyl_bessel_il is a case where it would be natural to use its precursor in boost for compilers that do not yet support it in C++17 (i.e. have a check in the configure step for this). After a while you could just switch to the std:: version without much ado. But that’s again going back to my original question about avoiding boost for its own sake vs modernising the code to more recent C++ standards.

For clang you can check out its source code and build the latest release (or even the current master) on Linux yourself. That works well for me on Ubuntu. I guess when your QuantLib-noBoost builds with clang on Linux there won’t be issues on OS X (with the LLVM clang) either.

I would still be most interested in where the performance gain comes from exactly and if we can benefit from it in QuantLib classic as well, without C++17: It’s easy to say, let’s allow for 11, 14, 17, but there are still places where you have to work with MSVC 2010. In this situation you are happy that QL is still on 03 and you don’t have to backport it or use an older version. I’d be in favour of allowing 11 in QuantLib classic, but ideally maintaining a 03 branch which receives bug fixes, calendar updates etc.

Best Regards
Peter

> On 07 Jul 2017, at 22:50, Hao Zhang <ha...@ha...> wrote:
> 
> Hi Peter,
> 
> I just removed some GCC-specific code, and made it compile and run under Visual Studio 2017. Unfortunately I do not have access to a Mac, thus I cannot do any testing on macOS. If you have time, can you please try compiling the code again on Mac and send me the error message? I suppose Clang is more similar to GCC than to MSVC, thus if MSVC accept the code, making it run with Clang shouldn't be that hard...  
> 
> P.S. std::cyl_bessel_il is not too difficult to overcome. We already have modifiedBesselFunction_i and modifiedBesselFunction_k implemented in QuantLib. These functions just need to be modified for cases when the arguments become very large.
> 
> Thanks and Best Regards,
> 
> Hao
> On Friday, July 7, 2017 2:23:00 PM EDT Peter Caspers wrote:
>> Hi Hao, with the standard compiler on OS X El Capitan (Apple clang 8.0.0) there doesn’t seem to be much hope to get it built.  I also tried the LLVM clang 4.0.1 which is the latest release. That works much better, but there are still issues with C++17 support, some of which are easy to fix (missing template parameters) others not so easy (e.g. there is no support yet for std::cyl_bessel_il). gcc 7 seems to be the better alternative currently.
>> Best Regards
>> Peter
>> 
>>> On 05 Jul 2017, at 23:03, Hao Zhang <ha...@ha...> wrote:
>>> 
>>> Hi Peter,
>>> 
>>> As I mentioned in the GitHub README, I have only tested the project with GCC7 on Linux as of now. I plan to make the project compatible with at least Windows and macOS in the near future, but the code will certainly not able to compile on these other platforms before some major changes are made.
>>> 
>>> For your specific error, I think the reason is that with GCC the <limits> header is pulled in by <cmath> included by <ql/mathconstants.hpp>. On other platforms <cmath> may not include <limits>. I will include <limits> explicitly in the code, but I'm sure there are many other error messages remaining to be fixed with a non-GCC compiler.
> 
>>> 
>>> Hao
>>> On Wednesday, July 5, 2017 2:57:07 PM EDT Peter Caspers wrote:
>>>> Hi Hao, I am trying to build your project (on OSX with clang), I get the following weird error message though. Any idea where this could come from?
>>>> 
>>>> make[1]: Entering directory `/Users/peter/QuantLib-noBoost/build'
>>>> make[2]: Entering directory `/Users/peter/QuantLib-noBoost/build'
>>>> make[2]: Leaving directory `/Users/peter/QuantLib-noBoost/build'
>>>> make[2]: Entering directory `/Users/peter/QuantLib-noBoost/build'
>>>> [  1%] Building CXX object ql/CMakeFiles/QuantLib.dir/cashflow.cpp.o
>>>> [  1%] Building CXX object ql/CMakeFiles/QuantLib.dir/cashflows/averagebmacoupon.cpp.o
>>>> [  1%] Building CXX object ql/CMakeFiles/QuantLib.dir/cashflows/capflooredcoupon.cpp.o
>>>> [  1%] Building CXX object ql/CMakeFiles/QuantLib.dir/cashflows/capflooredinflationcoupon.cpp.o
>>>> [  1%] Building CXX object ql/CMakeFiles/QuantLib.dir/cashflows/cashflows.cpp.o
>>>> [  1%] Building CXX object ql/CMakeFiles/QuantLib.dir/cashflows/cashflowvectors.cpp.o
>>>> [  1%] Building CXX object ql/CMakeFiles/QuantLib.dir/cashflows/cmscoupon.cpp.o
>>>> [  1%] Building CXX object ql/CMakeFiles/QuantLib.dir/cashflows/conundrumpricer.cpp.o
>>>> In file included from /Users/peter/QuantLib-noBoost/ql/cashflow.cpp:21:
>>>> In file included from /Users/peter/QuantLib-noBoost/ql/cashflow.hpp:28:
>>>> In file included from /Users/peter/QuantLib-noBoost/ql/event.hpp:28:
>>>> In file included from /Users/peter/QuantLib-noBoost/ql/time/date.hpp:35:
>>>> /Users/peter/QuantLib-noBoost/ql/utilities/null.hpp:58:24: error: no member named 'numeric_limits' in namespace 'std'
>>>>               return QL_NULL_REAL;
>>>>                      ^~~~~~~~~~~~
>>>> /Users/peter/QuantLib-noBoost/ql/qldefines.hpp:126:39: note: expanded from macro 'QL_NULL_REAL'
>>>> #define QL_NULL_REAL           ((std::numeric_limits<float>::max)())
>>>>                                ~~~~~^
>>>> 
>>>> 
>>>>> On 04 Jul 2017, at 21:28, Hao Zhang <ha...@ha...> wrote:
>>>>> 
>>>>> Hi Peter and Luigi,
>>>>> 
>>>>> Thank you very much for your support! No, the performance gain is not from 
>>>>> MKL, as MKL is not used in the default setting. I am sorry that I cannot 
>>>>> pinpoint the exact source of performance gain yet. My hunch is that many 
>>>>> Boost modules are quite general, and provide features that's not used by 
>>>>> QuantLib. There are also safety checks in Boost that's not relevant to 
>>>>> QuantLib. By targeting only QuantLib, I do not need to write many 
>>>>> redundant features and safety checks, and avoid some extra instructions. 
>>>>> Also the move semantics in modern C++ may also help with speed. I 
>>>>> apologize that I cannot answer your question in more detail at this point. 
>>>>> 
>>>>> Best Regards,
>>>>> 
>>>>> Hao
>>>>> On Tuesday, July 4, 2017 11:38:00 AM EDT Peter Caspers wrote:
>>>>>> Hi Hao, that's very interesting. Do you know where the performance gain
>>>>>> is coming from, is it mostly MKL vs. UBLAS? Or are there other drivers
>>>>>> as well? I'd also be interested in the motivation to do this in the
>>>>>> first place, I never thought boost as such was a bad thing? The upgrade
>>>>>> to C++17 is surely nice and makes sense, no doubt. Best Regards
>>>>>> Peter
>>>>>> 
>>>>>>> On 04 Jul 2017, at 09:42, Luigi Ballabio <lui...@gm...>
>>>>>>> wrote:
>>>>>>> 
>>>>>>> Hello Hao,
>>>>>>> 
>>>>>>>  that's great news---I've been wondering myself if this was
>>>>>>>  possible.  I'll be sure to check out your project.> 
>>>>>>> I suggest you also post to quantlib-users for greater exposure.
>>>>>>> 
>>>>>>> Later,
>>>>>>> 
>>>>>>>  Luigi
>>>>>>> 
>>>>>>> On Tue, Jul 4, 2017 at 5:24 AM Hao Zhang via QuantLib-dev
>>>>>>> <qua...@li...
>>>>>>> <mailto:qua...@li... <mailto:qua...@li...> <mailto:qua...@li... <mailto:qua...@li...>>>> wrote: Hello Everyone,
>>>>>>> 
>>>>>>> I have removed all Boost dependency from QuantLib, and ported QuantLib
>>>>>>> to C++17. The code is hosted on GitHub
>>>>>>> (https://github.com/haozhangphd/ <https://github.com/haozhangphd/> <https://github.com/haozhangphd/ <https://github.com/haozhangphd/>> QuantLib-noBoost
>>>>>>> <https://github.com/haozhangphd/QuantLib-noBoost <https://github.com/haozhangphd/QuantLib-noBoost> <https://github.com/haozhangphd/QuantLib-noBoost <https://github.com/haozhangphd/QuantLib-noBoost>>>).
>>>>>>> 
>>>>>>> The ported code passes all test cases, and there are significant
>>>>>>> performance improvements in SOME functionalities. Using the QuantLib
>>>>>>> Benchmark Suite, Quantlib-noBoost gives 3425 mflops (running time
>>>>>>> 13.15s), while unmodified QuantLib gives 1440 mflops (running time
>>>>>>> 44.8s) on my Dell Inspiron 13 i7348 laptop, both running under
>>>>>>> identical conditions with identical compiler flags. The total running
>>>>>>> time of the whole test suite is also shorter by ~10% after Boost is
>>>>>>> removed.
>>>>>>> 
>>>>>>> I will continue maintaining this project, and regularly backporting
>>>>>>> latest commits from QuantLib. I will also make this project work on
>>>>>>> other compilers besides GCC in the near future.
>>>>>>> 
>>>>>>> Best Regards,
>>>>>>> 
>>>>>>> Hao
>>>>>>> 
>>>>>>> ----------------------------------------------------------------------
>>>>>>> -------- Check out the vibrant tech community on one of the world's
>>>>>>> most engaging tech sites, Slashdot.org <http://slashdot.org/> <http://slashdot.org/ <http://slashdot.org/>>! http://sdm.link/slashdot <http://sdm.link/slashdot><http://sdm.link/slashdot <http://sdm.link/slashdot>>
>>>>>>> <http://sdm.link/slashdot <http://sdm.link/slashdot> <http://sdm.link/slashdot <http://sdm.link/slashdot>>>
>>>>>>> _______________________________________________
>>>>>>> QuantLib-dev mailing list
>>>>>>> Qua...@li... <mailto:Qua...@li...> <mailto:Qua...@li... <mailto:Qua...@li...>>
>>>>>>> <mailto:Qua...@li... <mailto:Qua...@li...> <mailto:Qua...@li... <mailto:Qua...@li...>>>
>>>>>>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev <https://lists.sourceforge.net/lists/listinfo/quantlib-dev> <https://lists.sourceforge.net/lists/listinfo/quantlib-dev <https://lists.sourceforge.net/lists/listinfo/quantlib-dev>>
>>>>>>> <https://lists.sourceforge.net/lists/listinfo/quantlib-dev>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> --------- Check out the vibrant tech community on one of the world's
>>>>>>> most engaging tech sites, Slashdot.org!
>>>>>>> http://sdm.link/slashdot_____________________________________________
>>>>>>> __ QuantLib-dev mailing list
>>>>>>> Qua...@li...
>>>>>>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>> 
> 
> 

Re: [Quantlib-dev] Removing Boost dependency from QuantLib

[Hao Z. <ha...@ha...>]

Hi Peter,

I just removed some GCC-specific code, and made it compile and run under Visual Studio 2017. Unfortunately I do not have access to a Mac, thus I cannot do any testing on macOS. If you have time, can you please try compiling the code again on Mac and send me the error message? I suppose Clang is more similar to GCC than to MSVC, thus if MSVC accept the code, making it run with Clang shouldn't be that hard...  

P.S. std::cyl_bessel_il is not too difficult to overcome. We already have modifiedBesselFunction_i and modifiedBesselFunction_k implemented in QuantLib. These functions just need to be modified for cases when the arguments become very large.

Thanks and Best Regards,

Hao
On Friday, July 7, 2017 2:23:00 PM EDT Peter Caspers wrote:
> Hi Hao, with the standard compiler on OS X El Capitan (Apple clang 8.0.0) there doesn’t seem to be much hope to get it built.  I also tried the LLVM clang 4.0.1 which is the latest release. That works much better, but there are still issues with C++17 support, some of which are easy to fix (missing template parameters) others not so easy (e.g. there is no support yet for std::cyl_bessel_il). gcc 7 seems to be the better alternative currently.
> Best Regards
> Peter
> 
> > On 05 Jul 2017, at 23:03, Hao Zhang <ha...@ha...> wrote:
> > 
> > Hi Peter,
> > 
> > As I mentioned in the GitHub README, I have only tested the project with GCC7 on Linux as of now. I plan to make the project compatible with at least Windows and macOS in the near future, but the code will certainly not able to compile on these other platforms before some major changes are made.
> > 
> > For your specific error, I think the reason is that with GCC the <limits> header is pulled in by <cmath> included by <ql/mathconstants.hpp>. On other platforms <cmath> may not include <limits>. I will include <limits> explicitly in the code, but I'm sure there are many other error messages remaining to be fixed with a non-GCC compiler.

> > 
> > Hao
> > On Wednesday, July 5, 2017 2:57:07 PM EDT Peter Caspers wrote:
> >> Hi Hao, I am trying to build your project (on OSX with clang), I get the following weird error message though. Any idea where this could come from?
> >> 
> >> make[1]: Entering directory `/Users/peter/QuantLib-noBoost/build'
> >> make[2]: Entering directory `/Users/peter/QuantLib-noBoost/build'
> >> make[2]: Leaving directory `/Users/peter/QuantLib-noBoost/build'
> >> make[2]: Entering directory `/Users/peter/QuantLib-noBoost/build'
> >> [  1%] Building CXX object ql/CMakeFiles/QuantLib.dir/cashflow.cpp.o
> >> [  1%] Building CXX object ql/CMakeFiles/QuantLib.dir/cashflows/averagebmacoupon.cpp.o
> >> [  1%] Building CXX object ql/CMakeFiles/QuantLib.dir/cashflows/capflooredcoupon.cpp.o
> >> [  1%] Building CXX object ql/CMakeFiles/QuantLib.dir/cashflows/capflooredinflationcoupon.cpp.o
> >> [  1%] Building CXX object ql/CMakeFiles/QuantLib.dir/cashflows/cashflows.cpp.o
> >> [  1%] Building CXX object ql/CMakeFiles/QuantLib.dir/cashflows/cashflowvectors.cpp.o
> >> [  1%] Building CXX object ql/CMakeFiles/QuantLib.dir/cashflows/cmscoupon.cpp.o
> >> [  1%] Building CXX object ql/CMakeFiles/QuantLib.dir/cashflows/conundrumpricer.cpp.o
> >> In file included from /Users/peter/QuantLib-noBoost/ql/cashflow.cpp:21:
> >> In file included from /Users/peter/QuantLib-noBoost/ql/cashflow.hpp:28:
> >> In file included from /Users/peter/QuantLib-noBoost/ql/event.hpp:28:
> >> In file included from /Users/peter/QuantLib-noBoost/ql/time/date.hpp:35:
> >> /Users/peter/QuantLib-noBoost/ql/utilities/null.hpp:58:24: error: no member named 'numeric_limits' in namespace 'std'
> >>                return QL_NULL_REAL;
> >>                       ^~~~~~~~~~~~
> >> /Users/peter/QuantLib-noBoost/ql/qldefines.hpp:126:39: note: expanded from macro 'QL_NULL_REAL'
> >> #define QL_NULL_REAL           ((std::numeric_limits<float>::max)())
> >>                                 ~~~~~^
> >> 
> >> 
> >>> On 04 Jul 2017, at 21:28, Hao Zhang <ha...@ha...> wrote:
> >>> 
> >>> Hi Peter and Luigi,
> >>> 
> >>> Thank you very much for your support! No, the performance gain is not from 
> >>> MKL, as MKL is not used in the default setting. I am sorry that I cannot 
> >>> pinpoint the exact source of performance gain yet. My hunch is that many 
> >>> Boost modules are quite general, and provide features that's not used by 
> >>> QuantLib. There are also safety checks in Boost that's not relevant to 
> >>> QuantLib. By targeting only QuantLib, I do not need to write many 
> >>> redundant features and safety checks, and avoid some extra instructions. 
> >>> Also the move semantics in modern C++ may also help with speed. I 
> >>> apologize that I cannot answer your question in more detail at this point. 
> >>> 
> >>> Best Regards,
> >>> 
> >>> Hao
> >>> On Tuesday, July 4, 2017 11:38:00 AM EDT Peter Caspers wrote:
> >>>> Hi Hao, that's very interesting. Do you know where the performance gain
> >>>> is coming from, is it mostly MKL vs. UBLAS? Or are there other drivers
> >>>> as well? I'd also be interested in the motivation to do this in the
> >>>> first place, I never thought boost as such was a bad thing? The upgrade
> >>>> to C++17 is surely nice and makes sense, no doubt. Best Regards
> >>>> Peter
> >>>> 
> >>>>> On 04 Jul 2017, at 09:42, Luigi Ballabio <lui...@gm...>
> >>>>> wrote:
> >>>>> 
> >>>>> Hello Hao,
> >>>>> 
> >>>>>   that's great news---I've been wondering myself if this was
> >>>>>   possible.  I'll be sure to check out your project.> 
> >>>>> I suggest you also post to quantlib-users for greater exposure.
> >>>>> 
> >>>>> Later,
> >>>>> 
> >>>>>   Luigi
> >>>>> 
> >>>>> On Tue, Jul 4, 2017 at 5:24 AM Hao Zhang via QuantLib-dev
> >>>>> <qua...@li...
> >>>>> <mailto:qua...@li... <mailto:qua...@li...> <mailto:qua...@li... <mailto:qua...@li...>>>> wrote: Hello Everyone,
> >>>>> 
> >>>>> I have removed all Boost dependency from QuantLib, and ported QuantLib
> >>>>> to C++17. The code is hosted on GitHub
> >>>>> (https://github.com/haozhangphd/ <https://github.com/haozhangphd/> <https://github.com/haozhangphd/ <https://github.com/haozhangphd/>> QuantLib-noBoost
> >>>>> <https://github.com/haozhangphd/QuantLib-noBoost <https://github.com/haozhangphd/QuantLib-noBoost> <https://github.com/haozhangphd/QuantLib-noBoost <https://github.com/haozhangphd/QuantLib-noBoost>>>).
> >>>>> 
> >>>>> The ported code passes all test cases, and there are significant
> >>>>> performance improvements in SOME functionalities. Using the QuantLib
> >>>>> Benchmark Suite, Quantlib-noBoost gives 3425 mflops (running time
> >>>>> 13.15s), while unmodified QuantLib gives 1440 mflops (running time
> >>>>> 44.8s) on my Dell Inspiron 13 i7348 laptop, both running under
> >>>>> identical conditions with identical compiler flags. The total running
> >>>>> time of the whole test suite is also shorter by ~10% after Boost is
> >>>>> removed.
> >>>>> 
> >>>>> I will continue maintaining this project, and regularly backporting
> >>>>> latest commits from QuantLib. I will also make this project work on
> >>>>> other compilers besides GCC in the near future.
> >>>>> 
> >>>>> Best Regards,
> >>>>> 
> >>>>> Hao
> >>>>> 
> >>>>> ----------------------------------------------------------------------
> >>>>> -------- Check out the vibrant tech community on one of the world's
> >>>>> most engaging tech sites, Slashdot.org <http://slashdot.org/> <http://slashdot.org/ <http://slashdot.org/>>! http://sdm.link/slashdot <http://sdm.link/slashdot><http://sdm.link/slashdot <http://sdm.link/slashdot>>
> >>>>> <http://sdm.link/slashdot <http://sdm.link/slashdot> <http://sdm.link/slashdot <http://sdm.link/slashdot>>>
> >>>>> _______________________________________________
> >>>>> QuantLib-dev mailing list
> >>>>> Qua...@li... <mailto:Qua...@li...> <mailto:Qua...@li... <mailto:Qua...@li...>>
> >>>>> <mailto:Qua...@li... <mailto:Qua...@li...> <mailto:Qua...@li... <mailto:Qua...@li...>>>
> >>>>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev <https://lists.sourceforge.net/lists/listinfo/quantlib-dev> <https://lists.sourceforge.net/lists/listinfo/quantlib-dev <https://lists.sourceforge.net/lists/listinfo/quantlib-dev>>
> >>>>> <https://lists.sourceforge.net/lists/listinfo/quantlib-dev>
> >>>>> ---------------------------------------------------------------------
> >>>>> --------- Check out the vibrant tech community on one of the world's
> >>>>> most engaging tech sites, Slashdot.org!
> >>>>> http://sdm.link/slashdot_____________________________________________
> >>>>> __ QuantLib-dev mailing list
> >>>>> Qua...@li...
> >>>>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
> 

Re: [Quantlib-dev] Removing Boost dependency from QuantLib

[Peter C. <pca...@gm...>]

Hi Hao, with the standard compiler on OS X El Capitan (Apple clang 8.0.0) there doesn’t seem to be much hope to get it built.  I also tried the LLVM clang 4.0.1 which is the latest release. That works much better, but there are still issues with C++17 support, some of which are easy to fix (missing template parameters) others not so easy (e.g. there is no support yet for std::cyl_bessel_il). gcc 7 seems to be the better alternative currently.
Best Regards
Peter

> On 05 Jul 2017, at 23:03, Hao Zhang <ha...@ha...> wrote:
> 
> Hi Peter,
> 
> As I mentioned in the GitHub README, I have only tested the project with GCC7 on Linux as of now. I plan to make the project compatible with at least Windows and macOS in the near future, but the code will certainly not able to compile on these other platforms before some major changes are made.
> 
> For your specific error, I think the reason is that with GCC the <limits> header is pulled in by <cmath> included by <ql/mathconstants.hpp>. On other platforms <cmath> may not include <limits>. I will include <limits> explicitly in the code, but I'm sure there are many other error messages remaining to be fixed with a non-GCC compiler.
> 
> Hao
> On Wednesday, July 5, 2017 2:57:07 PM EDT Peter Caspers wrote:
>> Hi Hao, I am trying to build your project (on OSX with clang), I get the following weird error message though. Any idea where this could come from?
>> 
>> make[1]: Entering directory `/Users/peter/QuantLib-noBoost/build'
>> make[2]: Entering directory `/Users/peter/QuantLib-noBoost/build'
>> make[2]: Leaving directory `/Users/peter/QuantLib-noBoost/build'
>> make[2]: Entering directory `/Users/peter/QuantLib-noBoost/build'
>> [  1%] Building CXX object ql/CMakeFiles/QuantLib.dir/cashflow.cpp.o
>> [  1%] Building CXX object ql/CMakeFiles/QuantLib.dir/cashflows/averagebmacoupon.cpp.o
>> [  1%] Building CXX object ql/CMakeFiles/QuantLib.dir/cashflows/capflooredcoupon.cpp.o
>> [  1%] Building CXX object ql/CMakeFiles/QuantLib.dir/cashflows/capflooredinflationcoupon.cpp.o
>> [  1%] Building CXX object ql/CMakeFiles/QuantLib.dir/cashflows/cashflows.cpp.o
>> [  1%] Building CXX object ql/CMakeFiles/QuantLib.dir/cashflows/cashflowvectors.cpp.o
>> [  1%] Building CXX object ql/CMakeFiles/QuantLib.dir/cashflows/cmscoupon.cpp.o
>> [  1%] Building CXX object ql/CMakeFiles/QuantLib.dir/cashflows/conundrumpricer.cpp.o
>> In file included from /Users/peter/QuantLib-noBoost/ql/cashflow.cpp:21:
>> In file included from /Users/peter/QuantLib-noBoost/ql/cashflow.hpp:28:
>> In file included from /Users/peter/QuantLib-noBoost/ql/event.hpp:28:
>> In file included from /Users/peter/QuantLib-noBoost/ql/time/date.hpp:35:
>> /Users/peter/QuantLib-noBoost/ql/utilities/null.hpp:58:24: error: no member named 'numeric_limits' in namespace 'std'
>>                return QL_NULL_REAL;
>>                       ^~~~~~~~~~~~
>> /Users/peter/QuantLib-noBoost/ql/qldefines.hpp:126:39: note: expanded from macro 'QL_NULL_REAL'
>> #define QL_NULL_REAL           ((std::numeric_limits<float>::max)())
>>                                 ~~~~~^
>> 
>> 
>>> On 04 Jul 2017, at 21:28, Hao Zhang <ha...@ha...> wrote:
>>> 
>>> Hi Peter and Luigi,
>>> 
>>> Thank you very much for your support! No, the performance gain is not from 
>>> MKL, as MKL is not used in the default setting. I am sorry that I cannot 
>>> pinpoint the exact source of performance gain yet. My hunch is that many 
>>> Boost modules are quite general, and provide features that's not used by 
>>> QuantLib. There are also safety checks in Boost that's not relevant to 
>>> QuantLib. By targeting only QuantLib, I do not need to write many 
>>> redundant features and safety checks, and avoid some extra instructions. 
>>> Also the move semantics in modern C++ may also help with speed. I 
>>> apologize that I cannot answer your question in more detail at this point. 
>>> 
>>> Best Regards,
>>> 
>>> Hao
>>> On Tuesday, July 4, 2017 11:38:00 AM EDT Peter Caspers wrote:
>>>> Hi Hao, that's very interesting. Do you know where the performance gain
>>>> is coming from, is it mostly MKL vs. UBLAS? Or are there other drivers
>>>> as well? I'd also be interested in the motivation to do this in the
>>>> first place, I never thought boost as such was a bad thing? The upgrade
>>>> to C++17 is surely nice and makes sense, no doubt. Best Regards
>>>> Peter
>>>> 
>>>>> On 04 Jul 2017, at 09:42, Luigi Ballabio <lui...@gm...>
>>>>> wrote:
>>>>> 
>>>>> Hello Hao,
>>>>> 
>>>>>   that's great news---I've been wondering myself if this was
>>>>>   possible.  I'll be sure to check out your project.> 
>>>>> I suggest you also post to quantlib-users for greater exposure.
>>>>> 
>>>>> Later,
>>>>> 
>>>>>   Luigi
>>>>> 
>>>>> On Tue, Jul 4, 2017 at 5:24 AM Hao Zhang via QuantLib-dev
>>>>> <qua...@li...
>>>>> <mailto:qua...@li... <mailto:qua...@li...> <mailto:qua...@li... <mailto:qua...@li...>>>> wrote: Hello Everyone,
>>>>> 
>>>>> I have removed all Boost dependency from QuantLib, and ported QuantLib
>>>>> to C++17. The code is hosted on GitHub
>>>>> (https://github.com/haozhangphd/ <https://github.com/haozhangphd/> <https://github.com/haozhangphd/ <https://github.com/haozhangphd/>> QuantLib-noBoost
>>>>> <https://github.com/haozhangphd/QuantLib-noBoost <https://github.com/haozhangphd/QuantLib-noBoost> <https://github.com/haozhangphd/QuantLib-noBoost <https://github.com/haozhangphd/QuantLib-noBoost>>>).
>>>>> 
>>>>> The ported code passes all test cases, and there are significant
>>>>> performance improvements in SOME functionalities. Using the QuantLib
>>>>> Benchmark Suite, Quantlib-noBoost gives 3425 mflops (running time
>>>>> 13.15s), while unmodified QuantLib gives 1440 mflops (running time
>>>>> 44.8s) on my Dell Inspiron 13 i7348 laptop, both running under
>>>>> identical conditions with identical compiler flags. The total running
>>>>> time of the whole test suite is also shorter by ~10% after Boost is
>>>>> removed.
>>>>> 
>>>>> I will continue maintaining this project, and regularly backporting
>>>>> latest commits from QuantLib. I will also make this project work on
>>>>> other compilers besides GCC in the near future.
>>>>> 
>>>>> Best Regards,
>>>>> 
>>>>> Hao
>>>>> 
>>>>> ----------------------------------------------------------------------
>>>>> -------- Check out the vibrant tech community on one of the world's
>>>>> most engaging tech sites, Slashdot.org <http://slashdot.org/> <http://slashdot.org/ <http://slashdot.org/>>! http://sdm.link/slashdot <http://sdm.link/slashdot><http://sdm.link/slashdot <http://sdm.link/slashdot>>
>>>>> <http://sdm.link/slashdot <http://sdm.link/slashdot> <http://sdm.link/slashdot <http://sdm.link/slashdot>>>
>>>>> _______________________________________________
>>>>> QuantLib-dev mailing list
>>>>> Qua...@li... <mailto:Qua...@li...> <mailto:Qua...@li... <mailto:Qua...@li...>>
>>>>> <mailto:Qua...@li... <mailto:Qua...@li...> <mailto:Qua...@li... <mailto:Qua...@li...>>>
>>>>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev <https://lists.sourceforge.net/lists/listinfo/quantlib-dev> <https://lists.sourceforge.net/lists/listinfo/quantlib-dev <https://lists.sourceforge.net/lists/listinfo/quantlib-dev>>
>>>>> <https://lists.sourceforge.net/lists/listinfo/quantlib-dev>
>>>>> ---------------------------------------------------------------------
>>>>> --------- Check out the vibrant tech community on one of the world's
>>>>> most engaging tech sites, Slashdot.org!
>>>>> http://sdm.link/slashdot_____________________________________________
>>>>> __ QuantLib-dev mailing list
>>>>> Qua...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev

[Quantlib-dev] Amortizing caps and floors pricing

[aubertseba <seb...@gm...>]

Hello,

I would like to know if QuantlibXL 1.9 offers the possibility to price
amortizing caps and floors in a negative interest rates environment ? That
implies the impossibility to use the Black-Scholes model.

Thanks in advance for your answer.

Yours sincerely,

Sébastien



--
View this message in context: http://quantlib.10058.n7.nabble.com/Amortizing-caps-and-floors-pricing-tp18413.html
Sent from the quantlib-dev mailing list archive at Nabble.com.

Re: [Quantlib-dev] Removing Boost dependency from QuantLib

[Hao Z. <ha...@ha...>]

Hi Klaus,

Thank you very much for your support. I try my best to only use standard-compliant C++ in my code, and avoid using any GNU extensions (in the default configuration at least). Thus it is not impossible to make it work on any platforms with a C++17-standard-compliant compiler. 

Best Regards,

Hao
On Wednesday, July 5, 2017 3:54:18 PM EDT Klaus Spanderen wrote:
> Hi,
> 
> Awesome work. The major achievement for me is the lift to C++17 - even subtle 
> details like the thread-safe observer pattern have been ported !  I wouldn't 
> mind if boost is stilled present for some minor use cases. It will be difficult 
> to replace all of it on all supported platforms.
> 
> I would also appreciate if we move completely to a modern C++ version after 
> 10++ years of C++03.
> 
> best regards
> Klaus
> 
> On Mittwoch, 5. Juli 2017 12:02:20 CEST Johannes Göttker-Schnetmann wrote:
> > Hi Hao, Peter,
> > 
> > I also find this very interesting. Since C++ is moving at a better pace for
> > some time we need at some point decide how QuantLib reacts to this.
> > Personally I am using modern compilers and like the features modern C++
> > provides. Therefore I would appreciate if QuantLib decides to fork or move
> > completely to a modern C++ version.
> > 
> > Boost is in part an incubator of ideas, which at some point might make it
> > into the C++ standard. For QuantLib the most prominent instances are
> > boost::shared_pointer and boost:unique_pointer which are both in the
> > standard for quite some time now. I would prefer to use the standard
> > libraries instead of boost in those cases.
> > 
> > Kind regards,
> > Johannes
> > 
> > On 4. Jul 2017, at 17:38, Peter Caspers <pca...@gm...> wrote:
> > 
> > Hi Hao, that’s very interesting. Do you know where the performance gain is
> > coming from, is it mostly MKL vs. UBLAS? Or are there other drivers as
> > well?
> > I’d also be interested in the motivation to do this in the first place, I
> > never thought boost as such was a bad thing?
> > The upgrade to C++17 is surely nice and makes sense, no doubt.
> > Best Regards
> > Peter
> > 
> > On 04 Jul 2017, at 09:42, Luigi Ballabio <lui...@gm...> wrote:
> > 
> > Hello Hao,
> >     that's great news---I've been wondering myself if this was possible.
> > I'll be sure to check out your project.
> > I suggest you also post to quantlib-users for greater exposure.
> > 
> > Later,
> >     Luigi
> > 
> > 
> > On Tue, Jul 4, 2017 at 5:24 AM Hao Zhang via QuantLib-dev <
> > 
> > qua...@li...> wrote:
> > > Hello Everyone,
> > > 
> > > I have removed all Boost dependency from QuantLib, and ported QuantLib to
> > > C++17. The code is hosted on GitHub (https://github.com/haozhangphd/
> > > QuantLib-noBoost <https://github.com/haozhangphd/QuantLib-noBoost>).
> > > 
> > > The ported code passes all test cases, and there are significant
> > > performance improvements in SOME functionalities. Using the QuantLib
> > > Benchmark Suite, Quantlib-noBoost gives 3425 mflops (running time 13.15s),
> > > while unmodified QuantLib gives 1440 mflops (running time 44.8s) on my
> > > Dell
> > > Inspiron 13 i7348 laptop, both running under identical conditions with
> > > identical compiler flags. The total running time of the whole test suite
> > > is
> > > also shorter by ~10% after Boost is removed.
> > > 
> > > I will continue maintaining this project, and regularly backporting latest
> > > commits from QuantLib. I will also make this project work on other
> > > compilers besides GCC in the near future.
> > > 
> > > Best Regards,
> > > 
> > > Hao
> > > 
> > > ------------------------------------------------------------
> > > ------------------
> > > Check out the vibrant tech community on one of the world's most
> > > engaging tech sites, Slashdot.org <http://slashdot.org/>!
> > > http://sdm.link/slashdot
> > > _______________________________________________
> > > QuantLib-dev mailing list
> > > Qua...@li...
> > > https://lists.sourceforge.net/lists/listinfo/quantlib-dev
> > 
> > ------------------------------------------------------------
> > ------------------
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, Slashdot.org <http://slashdot.org/>!
> > http://sdm.link/slashdot_______________________________________________
> > QuantLib-dev mailing list
> > Qua...@li...
> > https://lists.sourceforge.net/lists/listinfo/quantlib-dev
> > 
> > 
> > ------------------------------------------------------------
> > ------------------
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot______
> > _________________________________________
> > QuantLib-dev mailing list
> > Qua...@li...
> > https://lists.sourceforge.net/lists/listinfo/quantlib-dev
> 
> 
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
> 

Re: [Quantlib-dev] Removing Boost dependency from QuantLib

[Hao Z. <ha...@ha...>]

Hi Peter,

As I mentioned in the GitHub README, I have only tested the project with GCC7 on Linux as of now. I plan to make the project compatible with at least Windows and macOS in the near future, but the code will certainly not able to compile on these other platforms before some major changes are made.

For your specific error, I think the reason is that with GCC the <limits> header is pulled in by <cmath> included by <ql/mathconstants.hpp>. On other platforms <cmath> may not include <limits>. I will include <limits> explicitly in the code, but I'm sure there are many other error messages remaining to be fixed with a non-GCC compiler.

Hao
On Wednesday, July 5, 2017 2:57:07 PM EDT Peter Caspers wrote:
> Hi Hao, I am trying to build your project (on OSX with clang), I get the following weird error message though. Any idea where this could come from?
> 
> make[1]: Entering directory `/Users/peter/QuantLib-noBoost/build'
> make[2]: Entering directory `/Users/peter/QuantLib-noBoost/build'
> make[2]: Leaving directory `/Users/peter/QuantLib-noBoost/build'
> make[2]: Entering directory `/Users/peter/QuantLib-noBoost/build'
> [  1%] Building CXX object ql/CMakeFiles/QuantLib.dir/cashflow.cpp.o
> [  1%] Building CXX object ql/CMakeFiles/QuantLib.dir/cashflows/averagebmacoupon.cpp.o
> [  1%] Building CXX object ql/CMakeFiles/QuantLib.dir/cashflows/capflooredcoupon.cpp.o
> [  1%] Building CXX object ql/CMakeFiles/QuantLib.dir/cashflows/capflooredinflationcoupon.cpp.o
> [  1%] Building CXX object ql/CMakeFiles/QuantLib.dir/cashflows/cashflows.cpp.o
> [  1%] Building CXX object ql/CMakeFiles/QuantLib.dir/cashflows/cashflowvectors.cpp.o
> [  1%] Building CXX object ql/CMakeFiles/QuantLib.dir/cashflows/cmscoupon.cpp.o
> [  1%] Building CXX object ql/CMakeFiles/QuantLib.dir/cashflows/conundrumpricer.cpp.o
> In file included from /Users/peter/QuantLib-noBoost/ql/cashflow.cpp:21:
> In file included from /Users/peter/QuantLib-noBoost/ql/cashflow.hpp:28:
> In file included from /Users/peter/QuantLib-noBoost/ql/event.hpp:28:
> In file included from /Users/peter/QuantLib-noBoost/ql/time/date.hpp:35:
> /Users/peter/QuantLib-noBoost/ql/utilities/null.hpp:58:24: error: no member named 'numeric_limits' in namespace 'std'
>                 return QL_NULL_REAL;
>                        ^~~~~~~~~~~~
> /Users/peter/QuantLib-noBoost/ql/qldefines.hpp:126:39: note: expanded from macro 'QL_NULL_REAL'
> #define QL_NULL_REAL           ((std::numeric_limits<float>::max)())
>                                  ~~~~~^
> 
> 
> > On 04 Jul 2017, at 21:28, Hao Zhang <ha...@ha...> wrote:
> > 
> > Hi Peter and Luigi,
> > 
> > Thank you very much for your support! No, the performance gain is not from 
> > MKL, as MKL is not used in the default setting. I am sorry that I cannot 
> > pinpoint the exact source of performance gain yet. My hunch is that many 
> > Boost modules are quite general, and provide features that's not used by 
> > QuantLib. There are also safety checks in Boost that's not relevant to 
> > QuantLib. By targeting only QuantLib, I do not need to write many 
> > redundant features and safety checks, and avoid some extra instructions. 
> > Also the move semantics in modern C++ may also help with speed. I 
> > apologize that I cannot answer your question in more detail at this point. 
> > 
> > Best Regards,
> > 
> > Hao
> > On Tuesday, July 4, 2017 11:38:00 AM EDT Peter Caspers wrote:
> >> Hi Hao, that's very interesting. Do you know where the performance gain
> >> is coming from, is it mostly MKL vs. UBLAS? Or are there other drivers
> >> as well? I'd also be interested in the motivation to do this in the
> >> first place, I never thought boost as such was a bad thing? The upgrade
> >> to C++17 is surely nice and makes sense, no doubt. Best Regards
> >> Peter
> >> 
> >>> On 04 Jul 2017, at 09:42, Luigi Ballabio <lui...@gm...>
> >>> wrote:
> >>> 
> >>> Hello Hao,
> >>> 
> >>>    that's great news---I've been wondering myself if this was
> >>>    possible.  I'll be sure to check out your project.> 
> >>> I suggest you also post to quantlib-users for greater exposure.
> >>> 
> >>> Later,
> >>> 
> >>>    Luigi
> >>> 
> >>> On Tue, Jul 4, 2017 at 5:24 AM Hao Zhang via QuantLib-dev
> >>> <qua...@li...
> >>> <mailto:qua...@li... <mailto:qua...@li...>>> wrote: Hello Everyone,
> >>> 
> >>> I have removed all Boost dependency from QuantLib, and ported QuantLib
> >>> to C++17. The code is hosted on GitHub
> >>> (https://github.com/haozhangphd/ <https://github.com/haozhangphd/> QuantLib-noBoost
> >>> <https://github.com/haozhangphd/QuantLib-noBoost <https://github.com/haozhangphd/QuantLib-noBoost>>).
> >>> 
> >>> The ported code passes all test cases, and there are significant
> >>> performance improvements in SOME functionalities. Using the QuantLib
> >>> Benchmark Suite, Quantlib-noBoost gives 3425 mflops (running time
> >>> 13.15s), while unmodified QuantLib gives 1440 mflops (running time
> >>> 44.8s) on my Dell Inspiron 13 i7348 laptop, both running under
> >>> identical conditions with identical compiler flags. The total running
> >>> time of the whole test suite is also shorter by ~10% after Boost is
> >>> removed.
> >>> 
> >>> I will continue maintaining this project, and regularly backporting
> >>> latest commits from QuantLib. I will also make this project work on
> >>> other compilers besides GCC in the near future.
> >>> 
> >>> Best Regards,
> >>> 
> >>> Hao
> >>> 
> >>> ----------------------------------------------------------------------
> >>> -------- Check out the vibrant tech community on one of the world's
> >>> most engaging tech sites, Slashdot.org <http://slashdot.org/>! http://sdm.link/slashdot <http://sdm.link/slashdot>
> >>> <http://sdm.link/slashdot <http://sdm.link/slashdot>>
> >>> _______________________________________________
> >>> QuantLib-dev mailing list
> >>> Qua...@li... <mailto:Qua...@li...>
> >>> <mailto:Qua...@li... <mailto:Qua...@li...>>
> >>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev <https://lists.sourceforge.net/lists/listinfo/quantlib-dev>
> >>> <https://lists.sourceforge.net/lists/listinfo/quantlib-dev>
> >>> ---------------------------------------------------------------------
> >>> --------- Check out the vibrant tech community on one of the world's
> >>> most engaging tech sites, Slashdot.org!
> >>> http://sdm.link/slashdot_____________________________________________
> >>> __ QuantLib-dev mailing list
> >>> Qua...@li...
> >>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
> 

Re: [Quantlib-dev] Removing Boost dependency from QuantLib

[Klaus S. <kl...@sp...>]

Hi,

Awesome work. The major achievement for me is the lift to C++17 - even subtle 
details like the thread-safe observer pattern have been ported !  I wouldn't 
mind if boost is stilled present for some minor use cases. It will be difficult 
to replace all of it on all supported platforms.

I would also appreciate if we move completely to a modern C++ version after 
10++ years of C++03.

best regards
Klaus

On Mittwoch, 5. Juli 2017 12:02:20 CEST Johannes Göttker-Schnetmann wrote:
> Hi Hao, Peter,
> 
> I also find this very interesting. Since C++ is moving at a better pace for
> some time we need at some point decide how QuantLib reacts to this.
> Personally I am using modern compilers and like the features modern C++
> provides. Therefore I would appreciate if QuantLib decides to fork or move
> completely to a modern C++ version.
> 
> Boost is in part an incubator of ideas, which at some point might make it
> into the C++ standard. For QuantLib the most prominent instances are
> boost::shared_pointer and boost:unique_pointer which are both in the
> standard for quite some time now. I would prefer to use the standard
> libraries instead of boost in those cases.
> 
> Kind regards,
> Johannes
> 
> On 4. Jul 2017, at 17:38, Peter Caspers <pca...@gm...> wrote:
> 
> Hi Hao, that’s very interesting. Do you know where the performance gain is
> coming from, is it mostly MKL vs. UBLAS? Or are there other drivers as
> well?
> I’d also be interested in the motivation to do this in the first place, I
> never thought boost as such was a bad thing?
> The upgrade to C++17 is surely nice and makes sense, no doubt.
> Best Regards
> Peter
> 
> On 04 Jul 2017, at 09:42, Luigi Ballabio <lui...@gm...> wrote:
> 
> Hello Hao,
>     that's great news---I've been wondering myself if this was possible.
> I'll be sure to check out your project.
> I suggest you also post to quantlib-users for greater exposure.
> 
> Later,
>     Luigi
> 
> 
> On Tue, Jul 4, 2017 at 5:24 AM Hao Zhang via QuantLib-dev <
> 
> qua...@li...> wrote:
> > Hello Everyone,
> > 
> > I have removed all Boost dependency from QuantLib, and ported QuantLib to
> > C++17. The code is hosted on GitHub (https://github.com/haozhangphd/
> > QuantLib-noBoost <https://github.com/haozhangphd/QuantLib-noBoost>).
> > 
> > The ported code passes all test cases, and there are significant
> > performance improvements in SOME functionalities. Using the QuantLib
> > Benchmark Suite, Quantlib-noBoost gives 3425 mflops (running time 13.15s),
> > while unmodified QuantLib gives 1440 mflops (running time 44.8s) on my
> > Dell
> > Inspiron 13 i7348 laptop, both running under identical conditions with
> > identical compiler flags. The total running time of the whole test suite
> > is
> > also shorter by ~10% after Boost is removed.
> > 
> > I will continue maintaining this project, and regularly backporting latest
> > commits from QuantLib. I will also make this project work on other
> > compilers besides GCC in the near future.
> > 
> > Best Regards,
> > 
> > Hao
> > 
> > ------------------------------------------------------------
> > ------------------
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, Slashdot.org <http://slashdot.org/>!
> > http://sdm.link/slashdot
> > _______________________________________________
> > QuantLib-dev mailing list
> > Qua...@li...
> > https://lists.sourceforge.net/lists/listinfo/quantlib-dev
> 
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org <http://slashdot.org/>!
> http://sdm.link/slashdot_______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
> 
> 
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot______
> _________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev