Adjoint Greeks
Locked
123
123
 
|
Hi Peter,
I finished the fixed rate bond part and a pull request has been raised. Any comment is welcome, Peter:) Regards, Cheng -----邮件原件----- 发件人: Peter Caspers [mailto:[hidden email]] 发送时间: 2015年2月2日 20:52 收件人: cheng li 抄送: Luigi Ballabio; QuantLib developers 主题: Re: 答复: 答复: 答复: [Quantlib-dev] 答复: Adjoint Greeks Hi Cheng, great, I am looking forward to receive your contributions ! Kind regards Peter On 2 February 2015 at 02:35, cheng li <[hidden email]> wrote: > Hi Peter, > > Thank you for the gifts for all of us. I have tried your example. It looks very promising! > > Now I am following your steps and trying to make my first example. My fist goal is to make FixedRateBond AD available (I am most familiar with bonds part:)). > > When I finished I'll raise a pull request for that change to your trunk. > > Regards, > Cheng > > -----邮件原件----- > 发件人: Peter Caspers [mailto:[hidden email]] > 发送时间: 2015年1月26日 3:06 > 收件人: cheng li > 抄送: Luigi Ballabio; QuantLib developers > 主题: Re: 答复: 答复: [Quantlib-dev] 答复: Adjoint Greeks > > Hello, > > this weekend I have reached a level of conversion that allows to > tackle Vanilla Swaps. This is maybe the first "full-blown" example, so > if you are interested you can find some results in my blog > > http://quantlib.wordpress.com > > Comments are welcome. > > Thanks and best regards > Peter > > On 14 January 2015 at 10:54, Peter Caspers <[hidden email]> wrote: >> unlikely (the optimization level) >> Peter >> >> >> On 14 January 2015 at 02:49, cheng li <[hidden email]> wrote: >>> Hi Peter, >>> >>> I'll definitely have a try. Thank you :) >>> >>> Actually yesterday I tried on another machine with g++ 4.8.2 and O2 setting, then everything works fine. I think my previous problem may be due to O3. >>> >>> Regards, >>> Cheng >>> >>> -----邮件原件----- >>> 发件人: Peter Caspers [mailto:[hidden email]] >>> 发送时间: 2015年1月13日 21:18 >>> 收件人: cheng li >>> 抄送: Luigi Ballabio; QuantLib developers >>> 主题: Re: 答复: [Quantlib-dev] 答复: Adjoint Greeks >>> >>> I will clean up the adjoint branch to make it c++03 compliant. >>> Unless QuantLib 2.0 is out before the adjoint conversion has >>> finished :-) >>> >>> On 13 January 2015 at 02:28, cheng li <[hidden email]> wrote: >>>> Hi Luigi, >>>> >>>> >>>> >>>> I think I can not to avoid to use c++ 11 now.. In Peter’s branch >>>> much >>>> c++ 11 stuff is used, e.g. constexpr… >>>> >>>> >>>> >>>> Regards, >>>> >>>> Cheng >>>> >>>> >>>> >>>> 发件人: Luigi Ballabio [mailto:[hidden email]] >>>> 发送时间: 2015年1月12日 14:28 >>>> 收件人: Cheng Li >>>> 抄送: QuantLib developers; Peter Caspers >>>> 主题: Re: [Quantlib-dev] 答复: Adjoint Greeks >>>> >>>> >>>> >>>> Don't use C++11. >>>> >>>> Luigi >>>> >>>> On Jan 12, 2015 4:53 AM, "cheng li" <[hidden email]> wrote: >>>> >>>> Hi peter, >>>> >>>> I have switched to adjoint brank. However I am still facing some problem... >>>> I use g++ 4.9.2 with parameter "-std=c++11 -O3" >>>> >>>> /bin/bash ../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. >>>> -I../../ql -I../.. -I../.. -std=c++11 -O3 -MT averagebmacoupon.lo -MD -MP >>>> -MF .deps/averagebmacoupon.Tpo -c -o averagebmacoupon.lo >>>> averagebmacoupon.cpp >>>> libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../../ql -I../.. -I../.. >>>> -std=c++11 -O3 -MT averagebmacoupon.lo -MD -MP -MF >>>> .deps/averagebmacoupon.Tpo -c averagebmacoupon.cpp -fPIC -DPIC -o >>>> .libs/averagebmacoupon.o In file included from >>>> ../../ql/patterns/observable.hpp:29:0, >>>> from ../../ql/event.hpp:29, >>>> from ../../ql/cashflow.hpp:28, >>>> from ../../ql/cashflows/coupon.hpp:29, >>>> from ../../ql/cashflows/floatingratecoupon.hpp:33, >>>> from ../../ql/cashflows/averagebmacoupon.hpp:28, >>>> from averagebmacoupon.cpp:21: >>>> ../../ql/patterns/observable.hpp: In member function 'void >>>> QuantLib::Observable::notifyObservers()': >>>> ../../ql/errors.hpp:121:70: error: use of deleted function >>>> 'QuantLib::Error::Error(const QuantLib::Error&)' >>>> >>>> BOOST_CURRENT_FUNCTION,_ql_msg_stream.str()); \ >>>> >>>> ^ >>>> ../../ql/patterns/observable.hpp:139:9: note: in expansion of macro >>>> 'QL_ENSURE' >>>> QL_ENSURE(successful, >>>> ^ >>>> ../../ql/errors.hpp:39:11: note: 'QuantLib::Error::Error(const >>>> QuantLib::Error&)' is implicitly deleted because the default >>>> definition would be ill-formed: >>>> class Error : public std::exception { >>>> ^ >>>> ../../ql/errors.hpp:39:11: error: use of deleted function >>>> 'boost::shared_ptr<std::basic_string<char> >::shared_ptr(const >>>> boost::shared_ptr<std::basic_string<char> >&)' >>>> In file included from /usr/include/boost/shared_ptr.hpp:17:0, >>>> from ../../ql/errors.hpp:31, >>>> from ../../ql/patterns/observable.hpp:29, >>>> from ../../ql/event.hpp:29, >>>> from ../../ql/cashflow.hpp:28, >>>> from ../../ql/cashflows/coupon.hpp:29, >>>> from ../../ql/cashflows/floatingratecoupon.hpp:33, >>>> from ../../ql/cashflows/averagebmacoupon.hpp:28, >>>> from averagebmacoupon.cpp:21: >>>> /usr/include/boost/smart_ptr/shared_ptr.hpp:168:25: note: >>>> 'boost::shared_ptr<std::basic_string<char> >::shared_ptr(const >>>> boost::shared_ptr<std::basic_string<char> >&)' is implicitly >>>> declared as deleted because 'boost::shared_ptr<std::basic_string<char> >' >>>> declares a move constructor or move assignment operator >>>> >>>> Any idea about this? >>>> >>>> Regards, >>>> Cheng >>>> >>>> -----邮件原件----- >>>> 发件人: Peter Caspers [mailto:[hidden email]] >>>> 发送时间: 2015年1月11日 17:34 >>>> 收件人: Cheng Li >>>> 抄送: QuantLib Mailing Lists >>>> 主题: Re: 答复: [Quantlib-dev] Adjoint Greeks >>>> >>>> Hi Cheng, >>>> >>>> you are welcome and many thanks for your interest. However you seem >>>> to work on my master branch which I consider as my private >>>> workspace (with some unfinished things in it). Sorry, I wasn't >>>> expecting guests here :-) >>>> >>>> You probably want to try out the adjoint branch instead. This >>>> should compile. >>>> >>>> Thanks >>>> Peter >>>> >>>> On 11 January 2015 at 10:16, Cheng Li <[hidden email]> wrote: >>>>> Hi Peter, >>>>> >>>>> Thank you for your kindly offer these new stuff for all of us! >>>>> >>>>> I have cloned your branch and tried to build it on my machine. >>>>> When it was building the example/InterestRateSmile, the compiler >>>>> complained as >>>>> following: >>>>> >>>>> InterestRateSmiles.cpp: In function ‘void zabrExamples()’: >>>>> InterestRateSmiles.cpp:64:39: error: type/value mismatch at >>>>> argument >>>>> 1 in template parameter list for ‘template<class T> class boost::shared_ptr’ >>>>> boost::shared_ptr<ZabrSmileSection> zabrln = >>>>> ^ >>>>> InterestRateSmiles.cpp:64:39: error: expected a type, got >>>>> ‘ZabrSmileSection’ >>>>> InterestRateSmiles.cpp:64:48: error: invalid type in declaration >>>>> before ‘=’ token >>>>> boost::shared_ptr<ZabrSmileSection> zabrln = >>>>> ^ >>>>> InterestRateSmiles.cpp:67:13: error: ‘template<class Evaluation> >>>>> class QuantLib::ZabrSmileSection’ used without template parameters >>>>> ZabrSmileSection::ShortMaturityLognormal); >>>>> >>>>> I am not sure what is the problem... Is it due to missing template >>>>> argument for ZabrSmileSection? >>>>> My compiler is g++ 4.8.2 and with parameter "-std=c++11 -O3" >>>>> >>>>> BTW, I found that quadraticlfm.hpp and quadraticlfm.cpp are >>>>> missing from the branch. However when I adjust the makefile.am to >>>>> exclude them out the compiling process works fine. >>>>> >>>>> >>>>> Regards, >>>>> Cheng >>>>> >>>>> -----邮件原件----- >>>>> 发件人: Peter Caspers [mailto:[hidden email]] >>>>> 发送时间: 2015年1月9日 3:57 >>>>> 收件人: Luigi Ballabio >>>>> 抄送: QuantLib Mailing Lists; Ferdinando M. Ametrano >>>>> 主题: Re: [Quantlib-dev] Adjoint Greeks >>>>> >>>>> I thought in a realistic application you would always need both >>>>> worlds, CppAD<double> for adjoint greek engines and double for all >>>>> the rest. I wonder what it would mean in terms of performance and >>>>> memory if you replace double by CppAD<double> in general. I can >>>>> maybe just stress test this a bit though. >>>>> Peter >>>>> >>>>> >>>>> >>>>> On 7 January 2015 at 10:23, Luigi Ballabio >>>>> <[hidden email]> >>>>> wrote: >>>>>> Switching Real would force you to fix compilation problems all >>>>>> over the library, instead of just in the code you're converting. >>>>>> >>>>>> If you wanted to go the route of #defining the type, I guess you >>>>>> could introduce another type (ADReal or something) and switch the >>>>>> coverted code to use it. >>>>>> Which might or might not be a good idea; you wouldn't be forced >>>>>> to templatize the code, but you would have to choose AD or not at >>>>>> compilation time, instead that having the choice to use both for >>>>>> different >>>>> tasks. Hmm... >>>>>> >>>>>> Anyway: yes, very promising. Between Peter, Klaus and Joseph, we >>>>>> got a lot of presents this Christmas :) >>>>>> >>>>>> Luigi >>>>>> >>>>>> >>>>>> >>>>>> On Wed, Jan 7, 2015 at 9:41 AM, Ferdinando M. Ametrano >>>>>> <[hidden email]> wrote: >>>>>>> >>>>>>> Thank you Peter, it sounds exciting and promising. >>>>>>> Why haven't you considered to just change the Real typedef from >>>>>>> double to CppAD::AD<double>? >>>>>>> >>>>>>> On Sun, Jan 4, 2015 at 9:55 PM, Peter Caspers >>>>>>> <[hidden email]> >>>>>>> wrote: >>>>>>>> >>>>>>>> Hello all, >>>>>>>> >>>>>>>> happy new year. >>>>>>>> >>>>>>>> I revisited Ferdinando's comments on adjoint greeks during our >>>>>>>> December workshop and started to play around with that idea. >>>>>>>> >>>>>>>> The approach I am trying to follow is to adapt the ql library >>>>>>>> code so that automatic differentiation _tools_ can be used with >>>>>>>> it in a transparent way. This is opposed to writing special >>>>>>>> adjoint engines by _hand_ like e.g. advocated in Capriotti, >>>>>>>> Giles, Algorithmic >>>>>>>> Differentiation: Adjoint Greeks Made Easy. The relatively small >>>>>>>> and homogeneous code basis of ql seems to allow for this kind >>>>>>>> of more fundamental approach. >>>>>>>> >>>>>>>> I wrote a bit about my first steps in my blog >>>>>>>> >>>>>>>> http://quantlib.wordpress.com/ >>>>>>>> >>>>>>>> and forked a new branch from Luigi's current master on github >>>>>>>> >>>>>>>> https://github.com/pcaspers/quantlib/tree/adjoint >>>>>>>> >>>>>>>> where I started to template'ize the library in order to allow >>>>>>>> for AD tools to hook in. There are already first working >>>>>>>> examples (see the >>>>>>>> blog) and I am starting to feel confident that the approach >>>>>>>> might work as a whole, might be doable in a reasonable amount >>>>>>>> of time and is worthwhile following. >>>>>>>> >>>>>>>> About the feasibility: The library seems to consist of roughly >>>>>>>> 376k lines of code currently (all hpp and cpp files under ql / ). >>>>>>>> From that we can subtract "data" files >>>>>>>> >>>>>>>> 78862 ./math/randomnumbers/sobolrsg.cpp >>>>>>>> 21376 ./math/randomnumbers/primitivepolynomials.cpp >>>>>>>> 14495 ./math/randomnumbers/latticerules.cpp >>>>>>>> 10115 ./experimental/volatility/noarbsabrabsprobs.cpp >>>>>>>> >>>>>>>> which leaves us with 251k lines. It seems that I have already >>>>>>>> reviewed and adapted around 14k lines, which is 5% and which >>>>>>>> took me approximately 60 hours. This gives an estimation of 130 >>>>>>>> person days still left to do. For the whole (!) library where >>>>>>>> already parts will make much sense and give interesting applications. E.g. >>>>>>>> excluding experimental classes (90k) and the market model (25k) >>>>>>>> reduces the estimate already to 65 person days to go. >>>>>>>> >>>>>>>> I would be interested in your opinions on that, in particular >>>>>>>> regarding the design choices to make (better now than later :-) ). >>>>>>>> >>>>>>>> I'd also be grateful for people supporting the development by >>>>>>>> forking the adjoint branch and sending pull requests with >>>>>>>> adapted code >>>>> pieces. >>>>>>>> My personal next steps would be >>>>>>>> - rate deltas for Legs / Swap instruments >>>>>>>> - rate vegas for vanilla interest rate options >>>>>>>> - Hull White model >>>>>>>> >>>>>>>> What do you think ? >>>>>>>> >>>>>>>> Thank you >>>>>>>> Peter >>>>>>>> >>>>>>>> >>>>>>>> --------------------------------------------------------------- >>>>>>>> - >>>>>>>> -- >>>>>>>> - >>>>>>>> - >>>>>>>> ---------- Dive into the World of Parallel Programming! The Go >>>>>>>> Parallel Website, sponsored by Intel and developed in >>>>>>>> partnership with Slashdot Media, is your hub for all things >>>>>>>> parallel software development, from weekly thought leadership >>>>>>>> blogs to news, videos, case studies, tutorials and more. Take a >>>>>>>> look and join the conversation now. >>>>>>>> http://goparallel.sourceforge.net >>>>>>>> _______________________________________________ >>>>>>>> QuantLib-dev mailing list >>>>>>>> [hidden email] >>>>>>>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> ---------------------------------------------------------------- >>>>>>> - >>>>>>> -- >>>>>>> - >>>>>>> - >>>>>>> --------- Dive into the World of Parallel Programming! The Go >>>>>>> Parallel Website, sponsored by Intel and developed in >>>>>>> partnership with Slashdot Media, is your hub for all things >>>>>>> parallel software development, from weekly thought leadership >>>>>>> blogs to news, videos, case studies, tutorials and more. Take a >>>>>>> look and join the conversation now. >>>>>>> http://goparallel.sourceforge.net >>>>>>> _______________________________________________ >>>>>>> QuantLib-dev mailing list >>>>>>> [hidden email] >>>>>>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> <https://implementingquantlib.blogspot.com> >>>>>> <https://twitter.com/lballabio> >>>>> >>>>> ------------------------------------------------------------------ >>>>> - >>>>> -- >>>>> - >>>>> ------ >>>>> -- >>>>> Dive into the World of Parallel Programming! The Go Parallel >>>>> Website, sponsored by Intel and developed in partnership with >>>>> Slashdot Media, is your hub for all things parallel software >>>>> development, from weekly thought leadership blogs to news, videos, >>>>> case studies, tutorials and more. Take a look and join the conversation now. >>>>> http://goparallel.sourceforge.net >>>>> _______________________________________________ >>>>> QuantLib-dev mailing list >>>>> [hidden email] >>>>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev >>>>> >>>> >>>> >>>> >>>> ------------------------------------------------------------------- >>>> - >>>> -- >>>> -------- New Year. New Location. New Benefits. New Data Center in >>>> Ashburn, VA. >>>> GigeNET is offering a free month of service with a new server in Ashburn. >>>> Choose from 2 high performing configs, both with 100TB of bandwidth. >>>> Higher redundancy.Lower latency.Increased capacity.Completely compliant. >>>> vanity: www.gigenet.com >>>> _______________________________________________ >>>> QuantLib-dev mailing list >>>> [hidden email] >>>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev >>> > ------------------------------------------------------------------------------ Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ QuantLib-dev mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/quantlib-dev |
Re: 答复: 答复: 答复: 答复: 答复: Adjoint Greeks
|
|
Hi Cheng,
great, thank you very much. Looks fine to me, I merged your changes into my branch. Send more whenever you feel like it. best regards Peter On 6 February 2015 at 10:12, cheng li <[hidden email]> wrote: > Hi Peter, > > I finished the fixed rate bond part and a pull request has been raised. > > Any comment is welcome, Peter:) > > Regards, > Cheng > > -----邮件原件----- > 发件人: Peter Caspers [mailto:[hidden email]] > 发送时间: 2015年2月2日 20:52 > 收件人: cheng li > 抄送: Luigi Ballabio; QuantLib developers > 主题: Re: 答复: 答复: 答复: [Quantlib-dev] 答复: Adjoint Greeks > > Hi Cheng, > > great, I am looking forward to receive your contributions ! > > Kind regards > Peter > > On 2 February 2015 at 02:35, cheng li <[hidden email]> wrote: >> Hi Peter, >> >> Thank you for the gifts for all of us. I have tried your example. It looks very promising! >> >> Now I am following your steps and trying to make my first example. My fist goal is to make FixedRateBond AD available (I am most familiar with bonds part:)). >> >> When I finished I'll raise a pull request for that change to your trunk. >> >> Regards, >> Cheng >> >> -----邮件原件----- >> 发件人: Peter Caspers [mailto:[hidden email]] >> 发送时间: 2015年1月26日 3:06 >> 收件人: cheng li >> 抄送: Luigi Ballabio; QuantLib developers >> 主题: Re: 答复: 答复: [Quantlib-dev] 答复: Adjoint Greeks >> >> Hello, >> >> this weekend I have reached a level of conversion that allows to >> tackle Vanilla Swaps. This is maybe the first "full-blown" example, so >> if you are interested you can find some results in my blog >> >> http://quantlib.wordpress.com >> >> Comments are welcome. >> >> Thanks and best regards >> Peter >> >> On 14 January 2015 at 10:54, Peter Caspers <[hidden email]> wrote: >>> unlikely (the optimization level) >>> Peter >>> >>> >>> On 14 January 2015 at 02:49, cheng li <[hidden email]> wrote: >>>> Hi Peter, >>>> >>>> I'll definitely have a try. Thank you :) >>>> >>>> Actually yesterday I tried on another machine with g++ 4.8.2 and O2 setting, then everything works fine. I think my previous problem may be due to O3. >>>> >>>> Regards, >>>> Cheng >>>> >>>> -----邮件原件----- >>>> 发件人: Peter Caspers [mailto:[hidden email]] >>>> 发送时间: 2015年1月13日 21:18 >>>> 收件人: cheng li >>>> 抄送: Luigi Ballabio; QuantLib developers >>>> 主题: Re: 答复: [Quantlib-dev] 答复: Adjoint Greeks >>>> >>>> I will clean up the adjoint branch to make it c++03 compliant. >>>> Unless QuantLib 2.0 is out before the adjoint conversion has >>>> finished :-) >>>> >>>> On 13 January 2015 at 02:28, cheng li <[hidden email]> wrote: >>>>> Hi Luigi, >>>>> >>>>> >>>>> >>>>> I think I can not to avoid to use c++ 11 now.. In Peter’s branch >>>>> much >>>>> c++ 11 stuff is used, e.g. constexpr… >>>>> >>>>> >>>>> >>>>> Regards, >>>>> >>>>> Cheng >>>>> >>>>> >>>>> >>>>> 发件人: Luigi Ballabio [mailto:[hidden email]] >>>>> 发送时间: 2015年1月12日 14:28 >>>>> 收件人: Cheng Li >>>>> 抄送: QuantLib developers; Peter Caspers >>>>> 主题: Re: [Quantlib-dev] 答复: Adjoint Greeks >>>>> >>>>> >>>>> >>>>> Don't use C++11. >>>>> >>>>> Luigi >>>>> >>>>> On Jan 12, 2015 4:53 AM, "cheng li" <[hidden email]> wrote: >>>>> >>>>> Hi peter, >>>>> >>>>> I have switched to adjoint brank. However I am still facing some problem... >>>>> I use g++ 4.9.2 with parameter "-std=c++11 -O3" >>>>> >>>>> /bin/bash ../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. >>>>> -I../../ql -I../.. -I../.. -std=c++11 -O3 -MT averagebmacoupon.lo -MD -MP >>>>> -MF .deps/averagebmacoupon.Tpo -c -o averagebmacoupon.lo >>>>> averagebmacoupon.cpp >>>>> libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../../ql -I../.. -I../.. >>>>> -std=c++11 -O3 -MT averagebmacoupon.lo -MD -MP -MF >>>>> .deps/averagebmacoupon.Tpo -c averagebmacoupon.cpp -fPIC -DPIC -o >>>>> .libs/averagebmacoupon.o In file included from >>>>> ../../ql/patterns/observable.hpp:29:0, >>>>> from ../../ql/event.hpp:29, >>>>> from ../../ql/cashflow.hpp:28, >>>>> from ../../ql/cashflows/coupon.hpp:29, >>>>> from ../../ql/cashflows/floatingratecoupon.hpp:33, >>>>> from ../../ql/cashflows/averagebmacoupon.hpp:28, >>>>> from averagebmacoupon.cpp:21: >>>>> ../../ql/patterns/observable.hpp: In member function 'void >>>>> QuantLib::Observable::notifyObservers()': >>>>> ../../ql/errors.hpp:121:70: error: use of deleted function >>>>> 'QuantLib::Error::Error(const QuantLib::Error&)' >>>>> >>>>> BOOST_CURRENT_FUNCTION,_ql_msg_stream.str()); \ >>>>> >>>>> ^ >>>>> ../../ql/patterns/observable.hpp:139:9: note: in expansion of macro >>>>> 'QL_ENSURE' >>>>> QL_ENSURE(successful, >>>>> ^ >>>>> ../../ql/errors.hpp:39:11: note: 'QuantLib::Error::Error(const >>>>> QuantLib::Error&)' is implicitly deleted because the default >>>>> definition would be ill-formed: >>>>> class Error : public std::exception { >>>>> ^ >>>>> ../../ql/errors.hpp:39:11: error: use of deleted function >>>>> 'boost::shared_ptr<std::basic_string<char> >::shared_ptr(const >>>>> boost::shared_ptr<std::basic_string<char> >&)' >>>>> In file included from /usr/include/boost/shared_ptr.hpp:17:0, >>>>> from ../../ql/errors.hpp:31, >>>>> from ../../ql/patterns/observable.hpp:29, >>>>> from ../../ql/event.hpp:29, >>>>> from ../../ql/cashflow.hpp:28, >>>>> from ../../ql/cashflows/coupon.hpp:29, >>>>> from ../../ql/cashflows/floatingratecoupon.hpp:33, >>>>> from ../../ql/cashflows/averagebmacoupon.hpp:28, >>>>> from averagebmacoupon.cpp:21: >>>>> /usr/include/boost/smart_ptr/shared_ptr.hpp:168:25: note: >>>>> 'boost::shared_ptr<std::basic_string<char> >::shared_ptr(const >>>>> boost::shared_ptr<std::basic_string<char> >&)' is implicitly >>>>> declared as deleted because 'boost::shared_ptr<std::basic_string<char> >' >>>>> declares a move constructor or move assignment operator >>>>> >>>>> Any idea about this? >>>>> >>>>> Regards, >>>>> Cheng >>>>> >>>>> -----邮件原件----- >>>>> 发件人: Peter Caspers [mailto:[hidden email]] >>>>> 发送时间: 2015年1月11日 17:34 >>>>> 收件人: Cheng Li >>>>> 抄送: QuantLib Mailing Lists >>>>> 主题: Re: 答复: [Quantlib-dev] Adjoint Greeks >>>>> >>>>> Hi Cheng, >>>>> >>>>> you are welcome and many thanks for your interest. However you seem >>>>> to work on my master branch which I consider as my private >>>>> workspace (with some unfinished things in it). Sorry, I wasn't >>>>> expecting guests here :-) >>>>> >>>>> You probably want to try out the adjoint branch instead. This >>>>> should compile. >>>>> >>>>> Thanks >>>>> Peter >>>>> >>>>> On 11 January 2015 at 10:16, Cheng Li <[hidden email]> wrote: >>>>>> Hi Peter, >>>>>> >>>>>> Thank you for your kindly offer these new stuff for all of us! >>>>>> >>>>>> I have cloned your branch and tried to build it on my machine. >>>>>> When it was building the example/InterestRateSmile, the compiler >>>>>> complained as >>>>>> following: >>>>>> >>>>>> InterestRateSmiles.cpp: In function ‘void zabrExamples()’: >>>>>> InterestRateSmiles.cpp:64:39: error: type/value mismatch at >>>>>> argument >>>>>> 1 in template parameter list for ‘template<class T> class boost::shared_ptr’ >>>>>> boost::shared_ptr<ZabrSmileSection> zabrln = >>>>>> ^ >>>>>> InterestRateSmiles.cpp:64:39: error: expected a type, got >>>>>> ‘ZabrSmileSection’ >>>>>> InterestRateSmiles.cpp:64:48: error: invalid type in declaration >>>>>> before ‘=’ token >>>>>> boost::shared_ptr<ZabrSmileSection> zabrln = >>>>>> ^ >>>>>> InterestRateSmiles.cpp:67:13: error: ‘template<class Evaluation> >>>>>> class QuantLib::ZabrSmileSection’ used without template parameters >>>>>> ZabrSmileSection::ShortMaturityLognormal); >>>>>> >>>>>> I am not sure what is the problem... Is it due to missing template >>>>>> argument for ZabrSmileSection? >>>>>> My compiler is g++ 4.8.2 and with parameter "-std=c++11 -O3" >>>>>> >>>>>> BTW, I found that quadraticlfm.hpp and quadraticlfm.cpp are >>>>>> missing from the branch. However when I adjust the makefile.am to >>>>>> exclude them out the compiling process works fine. >>>>>> >>>>>> >>>>>> Regards, >>>>>> Cheng >>>>>> >>>>>> -----邮件原件----- >>>>>> 发件人: Peter Caspers [mailto:[hidden email]] >>>>>> 发送时间: 2015年1月9日 3:57 >>>>>> 收件人: Luigi Ballabio >>>>>> 抄送: QuantLib Mailing Lists; Ferdinando M. Ametrano >>>>>> 主题: Re: [Quantlib-dev] Adjoint Greeks >>>>>> >>>>>> I thought in a realistic application you would always need both >>>>>> worlds, CppAD<double> for adjoint greek engines and double for all >>>>>> the rest. I wonder what it would mean in terms of performance and >>>>>> memory if you replace double by CppAD<double> in general. I can >>>>>> maybe just stress test this a bit though. >>>>>> Peter >>>>>> >>>>>> >>>>>> >>>>>> On 7 January 2015 at 10:23, Luigi Ballabio >>>>>> <[hidden email]> >>>>>> wrote: >>>>>>> Switching Real would force you to fix compilation problems all >>>>>>> over the library, instead of just in the code you're converting. >>>>>>> >>>>>>> If you wanted to go the route of #defining the type, I guess you >>>>>>> could introduce another type (ADReal or something) and switch the >>>>>>> coverted code to use it. >>>>>>> Which might or might not be a good idea; you wouldn't be forced >>>>>>> to templatize the code, but you would have to choose AD or not at >>>>>>> compilation time, instead that having the choice to use both for >>>>>>> different >>>>>> tasks. Hmm... >>>>>>> >>>>>>> Anyway: yes, very promising. Between Peter, Klaus and Joseph, we >>>>>>> got a lot of presents this Christmas :) >>>>>>> >>>>>>> Luigi >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Wed, Jan 7, 2015 at 9:41 AM, Ferdinando M. Ametrano >>>>>>> <[hidden email]> wrote: >>>>>>>> >>>>>>>> Thank you Peter, it sounds exciting and promising. >>>>>>>> Why haven't you considered to just change the Real typedef from >>>>>>>> double to CppAD::AD<double>? >>>>>>>> >>>>>>>> On Sun, Jan 4, 2015 at 9:55 PM, Peter Caspers >>>>>>>> <[hidden email]> >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Hello all, >>>>>>>>> >>>>>>>>> happy new year. >>>>>>>>> >>>>>>>>> I revisited Ferdinando's comments on adjoint greeks during our >>>>>>>>> December workshop and started to play around with that idea. >>>>>>>>> >>>>>>>>> The approach I am trying to follow is to adapt the ql library >>>>>>>>> code so that automatic differentiation _tools_ can be used with >>>>>>>>> it in a transparent way. This is opposed to writing special >>>>>>>>> adjoint engines by _hand_ like e.g. advocated in Capriotti, >>>>>>>>> Giles, Algorithmic >>>>>>>>> Differentiation: Adjoint Greeks Made Easy. The relatively small >>>>>>>>> and homogeneous code basis of ql seems to allow for this kind >>>>>>>>> of more fundamental approach. >>>>>>>>> >>>>>>>>> I wrote a bit about my first steps in my blog >>>>>>>>> >>>>>>>>> http://quantlib.wordpress.com/ >>>>>>>>> >>>>>>>>> and forked a new branch from Luigi's current master on github >>>>>>>>> >>>>>>>>> https://github.com/pcaspers/quantlib/tree/adjoint >>>>>>>>> >>>>>>>>> where I started to template'ize the library in order to allow >>>>>>>>> for AD tools to hook in. There are already first working >>>>>>>>> examples (see the >>>>>>>>> blog) and I am starting to feel confident that the approach >>>>>>>>> might work as a whole, might be doable in a reasonable amount >>>>>>>>> of time and is worthwhile following. >>>>>>>>> >>>>>>>>> About the feasibility: The library seems to consist of roughly >>>>>>>>> 376k lines of code currently (all hpp and cpp files under ql / ). >>>>>>>>> From that we can subtract "data" files >>>>>>>>> >>>>>>>>> 78862 ./math/randomnumbers/sobolrsg.cpp >>>>>>>>> 21376 ./math/randomnumbers/primitivepolynomials.cpp >>>>>>>>> 14495 ./math/randomnumbers/latticerules.cpp >>>>>>>>> 10115 ./experimental/volatility/noarbsabrabsprobs.cpp >>>>>>>>> >>>>>>>>> which leaves us with 251k lines. It seems that I have already >>>>>>>>> reviewed and adapted around 14k lines, which is 5% and which >>>>>>>>> took me approximately 60 hours. This gives an estimation of 130 >>>>>>>>> person days still left to do. For the whole (!) library where >>>>>>>>> already parts will make much sense and give interesting applications. E.g. >>>>>>>>> excluding experimental classes (90k) and the market model (25k) >>>>>>>>> reduces the estimate already to 65 person days to go. >>>>>>>>> >>>>>>>>> I would be interested in your opinions on that, in particular >>>>>>>>> regarding the design choices to make (better now than later :-) ). >>>>>>>>> >>>>>>>>> I'd also be grateful for people supporting the development by >>>>>>>>> forking the adjoint branch and sending pull requests with >>>>>>>>> adapted code >>>>>> pieces. >>>>>>>>> My personal next steps would be >>>>>>>>> - rate deltas for Legs / Swap instruments >>>>>>>>> - rate vegas for vanilla interest rate options >>>>>>>>> - Hull White model >>>>>>>>> >>>>>>>>> What do you think ? >>>>>>>>> >>>>>>>>> Thank you >>>>>>>>> Peter >>>>>>>>> >>>>>>>>> >>>>>>>>> --------------------------------------------------------------- >>>>>>>>> - >>>>>>>>> -- >>>>>>>>> - >>>>>>>>> - >>>>>>>>> ---------- Dive into the World of Parallel Programming! The Go >>>>>>>>> Parallel Website, sponsored by Intel and developed in >>>>>>>>> partnership with Slashdot Media, is your hub for all things >>>>>>>>> parallel software development, from weekly thought leadership >>>>>>>>> blogs to news, videos, case studies, tutorials and more. Take a >>>>>>>>> look and join the conversation now. >>>>>>>>> http://goparallel.sourceforge.net >>>>>>>>> _______________________________________________ >>>>>>>>> QuantLib-dev mailing list >>>>>>>>> [hidden email] >>>>>>>>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ---------------------------------------------------------------- >>>>>>>> - >>>>>>>> -- >>>>>>>> - >>>>>>>> - >>>>>>>> --------- Dive into the World of Parallel Programming! The Go >>>>>>>> Parallel Website, sponsored by Intel and developed in >>>>>>>> partnership with Slashdot Media, is your hub for all things >>>>>>>> parallel software development, from weekly thought leadership >>>>>>>> blogs to news, videos, case studies, tutorials and more. Take a >>>>>>>> look and join the conversation now. >>>>>>>> http://goparallel.sourceforge.net >>>>>>>> _______________________________________________ >>>>>>>> QuantLib-dev mailing list >>>>>>>> [hidden email] >>>>>>>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> <https://implementingquantlib.blogspot.com> >>>>>>> <https://twitter.com/lballabio> >>>>>> >>>>>> ------------------------------------------------------------------ >>>>>> - >>>>>> -- >>>>>> - >>>>>> ------ >>>>>> -- >>>>>> Dive into the World of Parallel Programming! The Go Parallel >>>>>> Website, sponsored by Intel and developed in partnership with >>>>>> Slashdot Media, is your hub for all things parallel software >>>>>> development, from weekly thought leadership blogs to news, videos, >>>>>> case studies, tutorials and more. Take a look and join the conversation now. >>>>>> http://goparallel.sourceforge.net >>>>>> _______________________________________________ >>>>>> QuantLib-dev mailing list >>>>>> [hidden email] >>>>>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev >>>>>> >>>>> >>>>> >>>>> >>>>> ------------------------------------------------------------------- >>>>> - >>>>> -- >>>>> -------- New Year. New Location. New Benefits. New Data Center in >>>>> Ashburn, VA. >>>>> GigeNET is offering a free month of service with a new server in Ashburn. >>>>> Choose from 2 high performing configs, both with 100TB of bandwidth. >>>>> Higher redundancy.Lower latency.Increased capacity.Completely compliant. >>>>> vanity: www.gigenet.com >>>>> _______________________________________________ >>>>> QuantLib-dev mailing list >>>>> [hidden email] >>>>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev >>>> >> > ------------------------------------------------------------------------------ Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ QuantLib-dev mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/quantlib-dev |
|
|
Hi Peter,
Sure. It is my pleasure. I'll go on with the bonds part. Regards, Cheng 2015-02-07 5:51 GMT+08:00, Peter Caspers <[hidden email]>: > Hi Cheng, > > great, thank you very much. Looks fine to me, I merged your changes > into my branch. Send more whenever you feel like it. > > best regards > Peter > > > On 6 February 2015 at 10:12, cheng li <[hidden email]> wrote: >> Hi Peter, >> >> I finished the fixed rate bond part and a pull request has been raised. >> >> Any comment is welcome, Peter:) >> >> Regards, >> Cheng >> >> -----邮件原件----- >> 发件人: Peter Caspers [mailto:[hidden email]] >> 发送时间: 2015年2月2日 20:52 >> 收件人: cheng li >> 抄送: Luigi Ballabio; QuantLib developers >> 主题: Re: 答复: 答复: 答复: [Quantlib-dev] 答复: Adjoint Greeks >> >> Hi Cheng, >> >> great, I am looking forward to receive your contributions ! >> >> Kind regards >> Peter >> >> On 2 February 2015 at 02:35, cheng li <[hidden email]> >> wrote: >>> Hi Peter, >>> >>> Thank you for the gifts for all of us. I have tried your example. It >>> looks very promising! >>> >>> Now I am following your steps and trying to make my first example. My >>> fist goal is to make FixedRateBond AD available (I am most familiar with >>> bonds part:)). >>> >>> When I finished I'll raise a pull request for that change to your trunk. >>> >>> Regards, >>> Cheng >>> >>> -----邮件原件----- >>> 发件人: Peter Caspers [mailto:[hidden email]] >>> 发送时间: 2015年1月26日 3:06 >>> 收件人: cheng li >>> 抄送: Luigi Ballabio; QuantLib developers >>> 主题: Re: 答复: 答复: [Quantlib-dev] 答复: Adjoint Greeks >>> >>> Hello, >>> >>> this weekend I have reached a level of conversion that allows to >>> tackle Vanilla Swaps. This is maybe the first "full-blown" example, so >>> if you are interested you can find some results in my blog >>> >>> http://quantlib.wordpress.com >>> >>> Comments are welcome. >>> >>> Thanks and best regards >>> Peter >>> >>> On 14 January 2015 at 10:54, Peter Caspers <[hidden email]> >>> wrote: >>>> unlikely (the optimization level) >>>> Peter >>>> >>>> >>>> On 14 January 2015 at 02:49, cheng li <[hidden email]> >>>> wrote: >>>>> Hi Peter, >>>>> >>>>> I'll definitely have a try. Thank you :) >>>>> >>>>> Actually yesterday I tried on another machine with g++ 4.8.2 and O2 >>>>> setting, then everything works fine. I think my previous problem may be >>>>> due to O3. >>>>> >>>>> Regards, >>>>> Cheng >>>>> >>>>> -----邮件原件----- >>>>> 发件人: Peter Caspers [mailto:[hidden email]] >>>>> 发送时间: 2015年1月13日 21:18 >>>>> 收件人: cheng li >>>>> 抄送: Luigi Ballabio; QuantLib developers >>>>> 主题: Re: 答复: [Quantlib-dev] 答复: Adjoint Greeks >>>>> >>>>> I will clean up the adjoint branch to make it c++03 compliant. >>>>> Unless QuantLib 2.0 is out before the adjoint conversion has >>>>> finished :-) >>>>> >>>>> On 13 January 2015 at 02:28, cheng li <[hidden email]> >>>>> wrote: >>>>>> Hi Luigi, >>>>>> >>>>>> >>>>>> >>>>>> I think I can not to avoid to use c++ 11 now.. In Peter’s branch >>>>>> much >>>>>> c++ 11 stuff is used, e.g. constexpr… >>>>>> >>>>>> >>>>>> >>>>>> Regards, >>>>>> >>>>>> Cheng >>>>>> >>>>>> >>>>>> >>>>>> 发件人: Luigi Ballabio [mailto:[hidden email]] >>>>>> 发送时间: 2015年1月12日 14:28 >>>>>> 收件人: Cheng Li >>>>>> 抄送: QuantLib developers; Peter Caspers >>>>>> 主题: Re: [Quantlib-dev] 答复: Adjoint Greeks >>>>>> >>>>>> >>>>>> >>>>>> Don't use C++11. >>>>>> >>>>>> Luigi >>>>>> >>>>>> On Jan 12, 2015 4:53 AM, "cheng li" <[hidden email]> >>>>>> wrote: >>>>>> >>>>>> Hi peter, >>>>>> >>>>>> I have switched to adjoint brank. However I am still facing some >>>>>> problem... >>>>>> I use g++ 4.9.2 with parameter "-std=c++11 -O3" >>>>>> >>>>>> /bin/bash ../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H >>>>>> -I. >>>>>> -I../../ql -I../.. -I../.. -std=c++11 -O3 -MT averagebmacoupon.lo >>>>>> -MD -MP >>>>>> -MF .deps/averagebmacoupon.Tpo -c -o averagebmacoupon.lo >>>>>> averagebmacoupon.cpp >>>>>> libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../../ql -I../.. -I../.. >>>>>> -std=c++11 -O3 -MT averagebmacoupon.lo -MD -MP -MF >>>>>> .deps/averagebmacoupon.Tpo -c averagebmacoupon.cpp -fPIC -DPIC -o >>>>>> .libs/averagebmacoupon.o In file included from >>>>>> ../../ql/patterns/observable.hpp:29:0, >>>>>> from ../../ql/event.hpp:29, >>>>>> from ../../ql/cashflow.hpp:28, >>>>>> from ../../ql/cashflows/coupon.hpp:29, >>>>>> from ../../ql/cashflows/floatingratecoupon.hpp:33, >>>>>> from ../../ql/cashflows/averagebmacoupon.hpp:28, >>>>>> from averagebmacoupon.cpp:21: >>>>>> ../../ql/patterns/observable.hpp: In member function 'void >>>>>> QuantLib::Observable::notifyObservers()': >>>>>> ../../ql/errors.hpp:121:70: error: use of deleted function >>>>>> 'QuantLib::Error::Error(const QuantLib::Error&)' >>>>>> >>>>>> BOOST_CURRENT_FUNCTION,_ql_msg_stream.str()); \ >>>>>> >>>>>> ^ >>>>>> ../../ql/patterns/observable.hpp:139:9: note: in expansion of macro >>>>>> 'QL_ENSURE' >>>>>> QL_ENSURE(successful, >>>>>> ^ >>>>>> ../../ql/errors.hpp:39:11: note: 'QuantLib::Error::Error(const >>>>>> QuantLib::Error&)' is implicitly deleted because the default >>>>>> definition would be ill-formed: >>>>>> class Error : public std::exception { >>>>>> ^ >>>>>> ../../ql/errors.hpp:39:11: error: use of deleted function >>>>>> 'boost::shared_ptr<std::basic_string<char> >::shared_ptr(const >>>>>> boost::shared_ptr<std::basic_string<char> >&)' >>>>>> In file included from /usr/include/boost/shared_ptr.hpp:17:0, >>>>>> from ../../ql/errors.hpp:31, >>>>>> from ../../ql/patterns/observable.hpp:29, >>>>>> from ../../ql/event.hpp:29, >>>>>> from ../../ql/cashflow.hpp:28, >>>>>> from ../../ql/cashflows/coupon.hpp:29, >>>>>> from ../../ql/cashflows/floatingratecoupon.hpp:33, >>>>>> from ../../ql/cashflows/averagebmacoupon.hpp:28, >>>>>> from averagebmacoupon.cpp:21: >>>>>> /usr/include/boost/smart_ptr/shared_ptr.hpp:168:25: note: >>>>>> 'boost::shared_ptr<std::basic_string<char> >::shared_ptr(const >>>>>> boost::shared_ptr<std::basic_string<char> >&)' is implicitly >>>>>> declared as deleted because 'boost::shared_ptr<std::basic_string<char> >>>>>> >' >>>>>> declares a move constructor or move assignment operator >>>>>> >>>>>> Any idea about this? >>>>>> >>>>>> Regards, >>>>>> Cheng >>>>>> >>>>>> -----邮件原件----- >>>>>> 发件人: Peter Caspers [mailto:[hidden email]] >>>>>> 发送时间: 2015年1月11日 17:34 >>>>>> 收件人: Cheng Li >>>>>> 抄送: QuantLib Mailing Lists >>>>>> 主题: Re: 答复: [Quantlib-dev] Adjoint Greeks >>>>>> >>>>>> Hi Cheng, >>>>>> >>>>>> you are welcome and many thanks for your interest. However you seem >>>>>> to work on my master branch which I consider as my private >>>>>> workspace (with some unfinished things in it). Sorry, I wasn't >>>>>> expecting guests here :-) >>>>>> >>>>>> You probably want to try out the adjoint branch instead. This >>>>>> should compile. >>>>>> >>>>>> Thanks >>>>>> Peter >>>>>> >>>>>> On 11 January 2015 at 10:16, Cheng Li <[hidden email]> >>>>>> wrote: >>>>>>> Hi Peter, >>>>>>> >>>>>>> Thank you for your kindly offer these new stuff for all of us! >>>>>>> >>>>>>> I have cloned your branch and tried to build it on my machine. >>>>>>> When it was building the example/InterestRateSmile, the compiler >>>>>>> complained as >>>>>>> following: >>>>>>> >>>>>>> InterestRateSmiles.cpp: In function ‘void zabrExamples()’: >>>>>>> InterestRateSmiles.cpp:64:39: error: type/value mismatch at >>>>>>> argument >>>>>>> 1 in template parameter list for ‘template<class T> class >>>>>>> boost::shared_ptr’ >>>>>>> boost::shared_ptr<ZabrSmileSection> zabrln = >>>>>>> ^ >>>>>>> InterestRateSmiles.cpp:64:39: error: expected a type, got >>>>>>> ‘ZabrSmileSection’ >>>>>>> InterestRateSmiles.cpp:64:48: error: invalid type in declaration >>>>>>> before ‘=’ token >>>>>>> boost::shared_ptr<ZabrSmileSection> zabrln = >>>>>>> ^ >>>>>>> InterestRateSmiles.cpp:67:13: error: ‘template<class Evaluation> >>>>>>> class QuantLib::ZabrSmileSection’ used without template parameters >>>>>>> ZabrSmileSection::ShortMaturityLognormal); >>>>>>> >>>>>>> I am not sure what is the problem... Is it due to missing template >>>>>>> argument for ZabrSmileSection? >>>>>>> My compiler is g++ 4.8.2 and with parameter "-std=c++11 -O3" >>>>>>> >>>>>>> BTW, I found that quadraticlfm.hpp and quadraticlfm.cpp are >>>>>>> missing from the branch. However when I adjust the makefile.am to >>>>>>> exclude them out the compiling process works fine. >>>>>>> >>>>>>> >>>>>>> Regards, >>>>>>> Cheng >>>>>>> >>>>>>> -----邮件原件----- >>>>>>> 发件人: Peter Caspers [mailto:[hidden email]] >>>>>>> 发送时间: 2015年1月9日 3:57 >>>>>>> 收件人: Luigi Ballabio >>>>>>> 抄送: QuantLib Mailing Lists; Ferdinando M. Ametrano >>>>>>> 主题: Re: [Quantlib-dev] Adjoint Greeks >>>>>>> >>>>>>> I thought in a realistic application you would always need both >>>>>>> worlds, CppAD<double> for adjoint greek engines and double for all >>>>>>> the rest. I wonder what it would mean in terms of performance and >>>>>>> memory if you replace double by CppAD<double> in general. I can >>>>>>> maybe just stress test this a bit though. >>>>>>> Peter >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 7 January 2015 at 10:23, Luigi Ballabio >>>>>>> <[hidden email]> >>>>>>> wrote: >>>>>>>> Switching Real would force you to fix compilation problems all >>>>>>>> over the library, instead of just in the code you're converting. >>>>>>>> >>>>>>>> If you wanted to go the route of #defining the type, I guess you >>>>>>>> could introduce another type (ADReal or something) and switch the >>>>>>>> coverted code to use it. >>>>>>>> Which might or might not be a good idea; you wouldn't be forced >>>>>>>> to templatize the code, but you would have to choose AD or not at >>>>>>>> compilation time, instead that having the choice to use both for >>>>>>>> different >>>>>>> tasks. Hmm... >>>>>>>> >>>>>>>> Anyway: yes, very promising. Between Peter, Klaus and Joseph, we >>>>>>>> got a lot of presents this Christmas :) >>>>>>>> >>>>>>>> Luigi >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Wed, Jan 7, 2015 at 9:41 AM, Ferdinando M. Ametrano >>>>>>>> <[hidden email]> wrote: >>>>>>>>> >>>>>>>>> Thank you Peter, it sounds exciting and promising. >>>>>>>>> Why haven't you considered to just change the Real typedef from >>>>>>>>> double to CppAD::AD<double>? >>>>>>>>> >>>>>>>>> On Sun, Jan 4, 2015 at 9:55 PM, Peter Caspers >>>>>>>>> <[hidden email]> >>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> Hello all, >>>>>>>>>> >>>>>>>>>> happy new year. >>>>>>>>>> >>>>>>>>>> I revisited Ferdinando's comments on adjoint greeks during our >>>>>>>>>> December workshop and started to play around with that idea. >>>>>>>>>> >>>>>>>>>> The approach I am trying to follow is to adapt the ql library >>>>>>>>>> code so that automatic differentiation _tools_ can be used with >>>>>>>>>> it in a transparent way. This is opposed to writing special >>>>>>>>>> adjoint engines by _hand_ like e.g. advocated in Capriotti, >>>>>>>>>> Giles, Algorithmic >>>>>>>>>> Differentiation: Adjoint Greeks Made Easy. The relatively small >>>>>>>>>> and homogeneous code basis of ql seems to allow for this kind >>>>>>>>>> of more fundamental approach. >>>>>>>>>> >>>>>>>>>> I wrote a bit about my first steps in my blog >>>>>>>>>> >>>>>>>>>> http://quantlib.wordpress.com/ >>>>>>>>>> >>>>>>>>>> and forked a new branch from Luigi's current master on github >>>>>>>>>> >>>>>>>>>> https://github.com/pcaspers/quantlib/tree/adjoint >>>>>>>>>> >>>>>>>>>> where I started to template'ize the library in order to allow >>>>>>>>>> for AD tools to hook in. There are already first working >>>>>>>>>> examples (see the >>>>>>>>>> blog) and I am starting to feel confident that the approach >>>>>>>>>> might work as a whole, might be doable in a reasonable amount >>>>>>>>>> of time and is worthwhile following. >>>>>>>>>> >>>>>>>>>> About the feasibility: The library seems to consist of roughly >>>>>>>>>> 376k lines of code currently (all hpp and cpp files under ql / ). >>>>>>>>>> From that we can subtract "data" files >>>>>>>>>> >>>>>>>>>> 78862 ./math/randomnumbers/sobolrsg.cpp >>>>>>>>>> 21376 ./math/randomnumbers/primitivepolynomials.cpp >>>>>>>>>> 14495 ./math/randomnumbers/latticerules.cpp >>>>>>>>>> 10115 ./experimental/volatility/noarbsabrabsprobs.cpp >>>>>>>>>> >>>>>>>>>> which leaves us with 251k lines. It seems that I have already >>>>>>>>>> reviewed and adapted around 14k lines, which is 5% and which >>>>>>>>>> took me approximately 60 hours. This gives an estimation of 130 >>>>>>>>>> person days still left to do. For the whole (!) library where >>>>>>>>>> already parts will make much sense and give interesting >>>>>>>>>> applications. E.g. >>>>>>>>>> excluding experimental classes (90k) and the market model (25k) >>>>>>>>>> reduces the estimate already to 65 person days to go. >>>>>>>>>> >>>>>>>>>> I would be interested in your opinions on that, in particular >>>>>>>>>> regarding the design choices to make (better now than later :-) >>>>>>>>>> ). >>>>>>>>>> >>>>>>>>>> I'd also be grateful for people supporting the development by >>>>>>>>>> forking the adjoint branch and sending pull requests with >>>>>>>>>> adapted code >>>>>>> pieces. >>>>>>>>>> My personal next steps would be >>>>>>>>>> - rate deltas for Legs / Swap instruments >>>>>>>>>> - rate vegas for vanilla interest rate options >>>>>>>>>> - Hull White model >>>>>>>>>> >>>>>>>>>> What do you think ? >>>>>>>>>> >>>>>>>>>> Thank you >>>>>>>>>> Peter >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> --------------------------------------------------------------- >>>>>>>>>> - >>>>>>>>>> -- >>>>>>>>>> - >>>>>>>>>> - >>>>>>>>>> ---------- Dive into the World of Parallel Programming! The Go >>>>>>>>>> Parallel Website, sponsored by Intel and developed in >>>>>>>>>> partnership with Slashdot Media, is your hub for all things >>>>>>>>>> parallel software development, from weekly thought leadership >>>>>>>>>> blogs to news, videos, case studies, tutorials and more. Take a >>>>>>>>>> look and join the conversation now. >>>>>>>>>> http://goparallel.sourceforge.net >>>>>>>>>> _______________________________________________ >>>>>>>>>> QuantLib-dev mailing list >>>>>>>>>> [hidden email] >>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> ---------------------------------------------------------------- >>>>>>>>> - >>>>>>>>> -- >>>>>>>>> - >>>>>>>>> - >>>>>>>>> --------- Dive into the World of Parallel Programming! The Go >>>>>>>>> Parallel Website, sponsored by Intel and developed in >>>>>>>>> partnership with Slashdot Media, is your hub for all things >>>>>>>>> parallel software development, from weekly thought leadership >>>>>>>>> blogs to news, videos, case studies, tutorials and more. Take a >>>>>>>>> look and join the conversation now. >>>>>>>>> http://goparallel.sourceforge.net >>>>>>>>> _______________________________________________ >>>>>>>>> QuantLib-dev mailing list >>>>>>>>> [hidden email] >>>>>>>>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> <https://implementingquantlib.blogspot.com> >>>>>>>> <https://twitter.com/lballabio> >>>>>>> >>>>>>> ------------------------------------------------------------------ >>>>>>> - >>>>>>> -- >>>>>>> - >>>>>>> ------ >>>>>>> -- >>>>>>> Dive into the World of Parallel Programming! The Go Parallel >>>>>>> Website, sponsored by Intel and developed in partnership with >>>>>>> Slashdot Media, is your hub for all things parallel software >>>>>>> development, from weekly thought leadership blogs to news, videos, >>>>>>> case studies, tutorials and more. Take a look and join the >>>>>>> conversation now. >>>>>>> http://goparallel.sourceforge.net >>>>>>> _______________________________________________ >>>>>>> QuantLib-dev mailing list >>>>>>> [hidden email] >>>>>>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> ------------------------------------------------------------------- >>>>>> - >>>>>> -- >>>>>> -------- New Year. New Location. New Benefits. New Data Center in >>>>>> Ashburn, VA. >>>>>> GigeNET is offering a free month of service with a new server in >>>>>> Ashburn. >>>>>> Choose from 2 high performing configs, both with 100TB of bandwidth. >>>>>> Higher redundancy.Lower latency.Increased capacity.Completely >>>>>> compliant. >>>>>> vanity: www.gigenet.com >>>>>> _______________________________________________ >>>>>> QuantLib-dev mailing list >>>>>> [hidden email] >>>>>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev >>>>> >>> >> > ------------------------------------------------------------------------------ Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ QuantLib-dev mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/quantlib-dev |
|
|
In reply to this post by Luigi Ballabio
Peter, Luigi, Ferdinando:
I am a bit late joining this discussion. I believe the approach of choosing AD vs. non-AD mode globally at compile time that you have discussed in the two messages quoted below may on the balance be the best choice for a large scale C++ library such as QuantLib. If we try to templatize nearly every class, in addition to the obscure compiler warning problems noted by Peter we will also see a major impact on compilation time, because a lot of the code will recompile the moment we touch any class. Also, as everyone noted earlier, this is not possible to do without a major overhaul of the entire code (turning a lot of .cpp files to .hpp headers and touching a lot of lines of code). Also, if the ultimate goal is to be able to select which type is using AD<double> and which type uses double, it may turn out that in the end the only two settings that will compile will be all-AD or no-AD settings, and the intermediate combinations will be hard to make compile and work. On the other hand, if we simply typedef Real to AD<double> (for CppAD) or adouble (for ADOL-C), and also ensure that a variable which has no tape pointer in it simply uses the internal double, then C++ inlining will likely reduce any performance impact. The advantage, as noted earlier in this thread, is that this can be done with minimal changes to the code base and hopefully can then be pulled into the master branch under a compile time define. Thanks to the great wisdom in using Real from the very beginning, this worked well without massive code changes. When I did the replacement and hit compile, it was about 150,000 line of C++ compiler errors (some lines of code were generating many lines of errors). After some tweaking which I committed to GitHub step by step, we are down to about 1000 errors and I do not see any major showstoppers in completing the conversion in a short period of time. For now I defined all variables as AD<double> except Time, but changed durations from Time to Real. I am currently trying to see if we should bite the bullet and use Real for Time as well, so we only have one type of double within the system. My code is in the following repos (expect rapid changes): Fork of Luigi's master, branch master-adjoint with changes: https://github.com/compatibl/quantlib/commits/master-adjoint Dependencies including a customized version of CppAD: https://github.com/compatibl/quantlib-dependencies To compile in adjoint mode, define QL_AD and put dependencies\cpp in the include path. Note that I had to make a minor change to CppAD. This change to CppAD is in dependencies, so only this version of CppAD wil work for now. If I do not manage to find a workaround will ask Brad Bell to pull my modification under a compile time define. It has to do with a constructor of AD<double> from another type with cast to double, which superseded the conversion we needed for InterestRate to AD<double>. See commit log for details. I will keep posting to this thread as we progress on this. Please let me know any comments, and please contact me if you wish to contribute to further development of this alternative approach, or use this repo. After the code compiles and runs, only then the real work will begin because the code will require considerable amount of AD-specific optimizations to outperform the brute force approach. But I am optimistic that it can be done with QuantLib. Best regards Alexander Sokol CompatibL > On Sun, Jan 11, 2015 at 7:16am, Luigi Ballabio wrote: > > Hi Peter, > you definitely need both double and CppAD<double>. I was wondering > if you needed a given engine if both adjoint and not-adjoint implementation. > If not, you might choose at compile time. Otherwise, we'd have to bite > the bullet and templatize lots of stuff, as you're doing already. > > Luigi > > On Thu, Jan 8, 2015 at 8:56 PM, Peter Caspers wrote: > > I thought in a realistic application you would always need both > worlds, CppAD<double> for adjoint greek engines and double for all the > rest. I wonder what it would mean in terms of performance and memory > if you replace double by CppAD<double> in general. I can maybe just > stress test this a bit though. > Peter |
|
|
Hi Alexander,
I agree with most of your points. With the typedef-approach we surely have less code changes. Also it will be easy to merge them into the original code. What I am not sure about is how to address the performance loss in parts of your application where you do not need AD. Using AD<double> (naively) instead of double slows down my vanilla swap example by 20 - 30 percent. Is that connected to your comment about the AD-specific optimizations needed later on ? Can you be more specific on this part in general maybe ? Concerning your CppAD patch, I did not look into it, but it sounds similar to what I saw when implementing the Null<AD<Base>> class. With templates it's easy to get a clean solution though. A dependency on a patch for an AD framework would not be very nice in my opinion. Well let's see. In any case it will be nice to compare both approaches once working for real life problems, won't it. Best regards Peter On 9 February 2015 at 18:14, Alexander Sokol <[hidden email]> wrote: > Peter, Luigi, Ferdinando: > > I am a bit late joining this discussion. I believe the approach > of choosing AD vs. non-AD mode globally at compile time that > you have discussed in the two messages quoted below may on the > balance be the best choice for a large scale C++ library such as > QuantLib. If we try to templatize nearly every class, in addition > to the obscure compiler warning problems noted by Peter we will > also see a major impact on compilation time, because a lot of > the code will recompile the moment we touch any class. Also, as > everyone noted earlier, this is not possible to do without a major > overhaul of the entire code (turning a lot of .cpp files to .hpp headers > and touching a lot of lines of code). > > Also, if the ultimate goal is to be able to select which type is using > AD<double> and which type uses double, it may turn out that in > the end the only two settings that will compile will be all-AD or > no-AD settings, and the intermediate combinations will be hard > to make compile and work. > > On the other hand, if we simply typedef Real to AD<double> > (for CppAD) or adouble (for ADOL-C), and also ensure that a > variable which has no tape pointer in it simply uses the internal > double, then C++ inlining will likely reduce any performance > impact. The advantage, as noted earlier in this thread, is that > this can be done with minimal changes to the code base and > hopefully can then be pulled into the master branch under > a compile time define. > > Thanks to the great wisdom in using Real from the very > beginning, this worked well without massive code changes. > When I did the replacement and hit compile, it was about > 150,000 line of C++ compiler errors (some lines of code > were generating many lines of errors). After some tweaking > which I committed to GitHub step by step, we are down to > about 1000 errors and I do not see any major showstoppers > in completing the conversion in a short period of time. > > For now I defined all variables as AD<double> except Time, > but changed durations from Time to Real. I am currently > trying to see if we should bite the bullet and use Real for Time > as well, so we only have one type of double within the system. > > My code is in the following repos (expect rapid changes): > > Fork of Luigi's master, branch master-adjoint with changes: > https://github.com/compatibl/quantlib/commits/master-adjoint > > Dependencies including a customized version of CppAD: > https://github.com/compatibl/quantlib-dependencies > > To compile in adjoint mode, define QL_AD and put > dependencies\cpp in the include path. > > Note that I had to make a minor change to CppAD. > This change to CppAD is in dependencies, so only this > version of CppAD wil work for now. > > If I do not manage to find a workaround will ask Brad Bell > to pull my modification under a compile time define. It has > to do with a constructor of AD<double> from another type > with cast to double, which superseded the conversion we > needed for InterestRate to AD<double>. See commit log > for details. > > I will keep posting to this thread as we progress on this. > > Please let me know any comments, and please contact > me if you wish to contribute to further development of > this alternative approach, or use this repo. After the code > compiles and runs, only then the real work will begin > because the code will require considerable amount of > AD-specific optimizations to outperform the brute force > approach. But I am optimistic that it can be done with > QuantLib. > > Best regards > Alexander Sokol > CompatibL > >> On Sun, Jan 11, 2015 at 7:16am, Luigi Ballabio wrote: >> >> Hi Peter, >> you definitely need both double and CppAD<double>. I was wondering >> if you needed a given engine if both adjoint and not-adjoint >> implementation. >> If not, you might choose at compile time. Otherwise, we'd have to bite >> the bullet and templatize lots of stuff, as you're doing already. >> >> Luigi >> >> On Thu, Jan 8, 2015 at 8:56 PM, Peter Caspers wrote: >> >> I thought in a realistic application you would always need both >> worlds, CppAD<double> for adjoint greek engines and double for all the >> rest. I wonder what it would mean in terms of performance and memory >> if you replace double by CppAD<double> in general. I can maybe just >> stress test this a bit though. >> Peter > > > > -- > View this message in context: http://quantlib.10058.n7.nabble.com/Adjoint-Greeks-tp16147p16251.html > Sent from the quantlib-dev mailing list archive at Nabble.com. > > ------------------------------------------------------------------------------ > Dive into the World of Parallel Programming. The Go Parallel Website, > sponsored by Intel and developed in partnership with Slashdot Media, is your > hub for all things parallel software development, from weekly thought > leadership blogs to news, videos, case studies, tutorials and more. Take a > look and join the conversation now. http://goparallel.sourceforge.net/ > _______________________________________________ > QuantLib-dev mailing list > [hidden email] > https://lists.sourceforge.net/lists/listinfo/quantlib-dev ------------------------------------------------------------------------------ Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ QuantLib-dev mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/quantlib-dev |
|
|
Hi Peter:
Thank you for your comments! I think even if manage to integrate AD into the master branch without the disruption of switching to a headers-only QuantLib or massive code changes, and only lose 20-30 percent in performance relative to the optimal assignment of Real vs. double inside each class, it would already be a good result. But I believe the impact in Release mode can be reduced even further by optimizing arithmetic operations that involve AD<double> objects with null tape pointer. We will run performance tests as soon as the conversion is finished. I hope for a less than 20% impact overall once all optimizations are done. Also, if we are comparing to the template based approach, it seems that the optimal assignment of Real vs. double cannot be done purely at the level of the entire class. For example, among multiple parameters that a method takes, depending on how it is used, some may have to be AD<double> and others have to be double. And of course it is not desirable if the code has to be recompiled with different template arguments for every mode of use. It is not clear if the perfect assignment of AD<double> vs double can be achieved in a way that does not compromise convenience for the end user. One more comment - because Luigi, Ferdinando & Co not only had the foresight to introduce Real, but also introduced Time as distinct from Real (which for now I decided to keep as double), we can avoid using AD variables for anything related to the times, schedules, etc. This is a large chunk of the code that will not be using AD<double> needlessly. So overall I am hopeful that the approach will prove viable. Best regards Alex -----Original Message----- From: Peter Caspers [mailto:[hidden email]] Sent: Tuesday, February 10, 2015 12:49 PM To: Alexander Sokol Cc: QuantLib Mailing Lists Subject: Re: [Quantlib-dev] Adjoint Greeks Hi Alexander, I agree with most of your points. With the typedef-approach we surely have less code changes. Also it will be easy to merge them into the original code. What I am not sure about is how to address the performance loss in parts of your application where you do not need AD. Using AD<double> (naively) instead of double slows down my vanilla swap example by 20 - 30 percent. Is that connected to your comment about the AD-specific optimizations needed later on ? Can you be more specific on this part in general maybe ? Concerning your CppAD patch, I did not look into it, but it sounds similar to what I saw when implementing the Null<AD<Base>> class. With templates it's easy to get a clean solution though. A dependency on a patch for an AD framework would not be very nice in my opinion. Well let's see. In any case it will be nice to compare both approaches once working for real life problems, won't it. Best regards Peter ------------------------------------------------------------------------------ Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ QuantLib-dev mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/quantlib-dev |
|
|
Hi Peter and Alexander, apologies for chiming in so late. I've been thinking a bit about this, and as usual I didn't make up my mind, as I seem to agree with both of you :) I agree with Alexander that the typedef approach is surely less scary than templatizing most of the library (especially from my other perspective of having to teach and write about the library from time to time...) but I also see Peter's point of not having to pay for adjoints when one doesn't use them. So, here's a crazy idea. Feel free to punch holes in it as you see fit. In the template approach, AD and Real versions of objects are not really compatible as I understand it; that is, you can't set an engine using AD<Real> to an instrument using Real (is this correct, Peter?) so in a way, it's as if they're part of two different libraries. What if one actually made two different libraries, one compiled with Real and the other with AD<Real>? Using a macro to change the namespace in the second one to something like QuantLibAD should be enough to prevent resolution conflicts when using both. What do you think? About the CppAD patch: yes, having to rely on a patch is kind of awkward. Alexander, did you try looking into Peter's solution for this? (If I remember correctly, it was a specialization of our Null class for AD<double> which you could integrate in your code.) Needless to say, I would be a very happy maintainer if I got the two of you on the same project instead of two competing ones... Later, Luigi On Tue, Feb 10, 2015 at 7:04 PM, Alexander Sokol <[hidden email]> wrote: Hi Peter: ------------------------------------------------------------------------------ Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk _______________________________________________ QuantLib-dev mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/quantlib-dev |
|
|
Hi Luigi, Alex,
even with templates the AD and non-AD worlds would be rather separated. I thought of converting constructors (just typing here, so it might be nonsense) template<class T> template<class S> Class_t<T>::Class_t(const Class_t<S>& other) { /* ... */ } for S (Real) convertible to T (CppAD::AD<Real>). I did not really think it through though. Anyway, what I want to do is to finish the template approach for a well defined subset of the library (like the vanilla rates part including volatility structures and the Gsr and Markov models and the bonds part contributed by Cheng). However, I also think that it would be quite a big thing to merge the changes into the mainstream branch and that in total it may be wiser to follow Alex's approach. I will fork his branch on the weekend and see where I can help. So no need to spend an extra day on generic programming during your next course, Luigi ;-) best regards Peter On 18 February 2015 at 15:30, Luigi Ballabio <[hidden email]> wrote: > Hi Peter and Alexander, > apologies for chiming in so late. I've been thinking a bit about this, > and as usual I didn't make up my mind, as I seem to agree with both of you > :) > I agree with Alexander that the typedef approach is surely less scary than > templatizing most of the library (especially from my other perspective of > having to teach and write about the library from time to time...) but I also > see Peter's point of not having to pay for adjoints when one doesn't use > them. > > So, here's a crazy idea. Feel free to punch holes in it as you see fit. In > the template approach, AD and Real versions of objects are not really > compatible as I understand it; that is, you can't set an engine using > AD<Real> to an instrument using Real (is this correct, Peter?) so in a way, > it's as if they're part of two different libraries. What if one actually > made two different libraries, one compiled with Real and the other with > AD<Real>? Using a macro to change the namespace in the second one to > something like QuantLibAD should be enough to prevent resolution conflicts > when using both. What do you think? > > About the CppAD patch: yes, having to rely on a patch is kind of awkward. > Alexander, did you try looking into Peter's solution for this? (If I > remember correctly, it was a specialization of our Null class for AD<double> > which you could integrate in your code.) > > Needless to say, I would be a very happy maintainer if I got the two of you > on the same project instead of two competing ones... > > Later, > Luigi > > > > On Tue, Feb 10, 2015 at 7:04 PM, Alexander Sokol <[hidden email]> > wrote: >> >> Hi Peter: >> >> Thank you for your comments! I think even if manage to integrate AD into >> the master branch without the disruption of switching to a headers-only >> QuantLib or massive code changes, and only lose 20-30 percent in performance >> relative to the optimal assignment of Real vs. double inside each class, it >> would already be a good result. But I believe the impact in Release mode can >> be reduced even further by optimizing arithmetic operations that involve >> AD<double> objects with null tape pointer. We will run performance tests as >> soon as the conversion is finished. I hope for a less than 20% impact >> overall once all optimizations are done. >> >> Also, if we are comparing to the template based approach, it seems that >> the optimal assignment of Real vs. double cannot be done purely at the level >> of the entire class. For example, among multiple parameters that a method >> takes, depending on how it is used, some may have to be AD<double> and >> others have to be double. And of course it is not desirable if the code has >> to be recompiled with different template arguments for every mode of use. It >> is not clear if the perfect assignment of AD<double> vs double can be >> achieved in a way that does not compromise convenience for the end user. >> >> One more comment - because Luigi, Ferdinando & Co not only had the >> foresight to introduce Real, but also introduced Time as distinct from Real >> (which for now I decided to keep as double), we can avoid using AD variables >> for anything related to the times, schedules, etc. This is a large chunk of >> the code that will not be using AD<double> needlessly. So overall I am >> hopeful that the approach will prove viable. >> >> Best regards >> Alex >> >> -----Original Message----- >> From: Peter Caspers [mailto:[hidden email]] >> Sent: Tuesday, February 10, 2015 12:49 PM >> To: Alexander Sokol >> Cc: QuantLib Mailing Lists >> Subject: Re: [Quantlib-dev] Adjoint Greeks >> >> Hi Alexander, >> >> I agree with most of your points. With the typedef-approach we surely have >> less code changes. Also it will be easy to merge them into the original >> code. >> >> What I am not sure about is how to address the performance loss in parts >> of your application where you do not need AD. Using AD<double> >> (naively) instead of double slows down my vanilla swap example by 20 - >> 30 percent. Is that connected to your comment about the AD-specific >> optimizations needed later on ? Can you be more specific on this part in >> general maybe ? >> >> Concerning your CppAD patch, I did not look into it, but it sounds similar >> to what I saw when implementing the Null<AD<Base>> class. With templates >> it's easy to get a clean solution though. A dependency on a patch for an AD >> framework would not be very nice in my opinion. >> >> Well let's see. In any case it will be nice to compare both approaches >> once working for real life problems, won't it. >> >> Best regards >> Peter >> >> >> ------------------------------------------------------------------------------ >> Dive into the World of Parallel Programming. The Go Parallel Website, >> sponsored by Intel and developed in partnership with Slashdot Media, is >> your >> hub for all things parallel software development, from weekly thought >> leadership blogs to news, videos, case studies, tutorials and more. Take a >> look and join the conversation now. http://goparallel.sourceforge.net/ >> _______________________________________________ >> QuantLib-dev mailing list >> [hidden email] >> https://lists.sourceforge.net/lists/listinfo/quantlib-dev > > > > > -- > <https://implementingquantlib.blogspot.com> > <https://twitter.com/lballabio> ------------------------------------------------------------------------------ Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk _______________________________________________ QuantLib-dev mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/quantlib-dev |
|
|
Peter, Luigi:
Just a quick update on our status - as of today the entire QuantLib code including the core library, test suite, and examples compiles without errors with Real = AD<double>, and there are only 3 linking errors remaining. I hope to commit the code which has no linking or compilation errors within the next few days and will post GIT revisions then. The interim version is in CompatibL's clone of quantlib repo, https://github.com/compatibl/quantlib. However this result was achieved by temporarily creating a large number of stubs for methods taking AD<double>. The stubs are currently throwing exceptions, and will need to be implemented one by one. The good news is that we have been able to compile the entire source while making only minimal changes, and I hope these changes are sufficiently limited and localized for Luigi to accept them into the main master so we do not need to maintain AD and non-AD version separately - it would be controlled by a compile time define with the same source. Regarding Luigi's idea with two libraries, this can certainly work if one needs to apply AD only in some areas of the code but not others. We can make "QuantLib" a compile time define, to be defined separately for each project. This will avoid having to touch every file. Best regards Alex |
|
|
In reply to this post by Alexander Sokol
Hi Alex，
I have checked out your master branch and I found that there are 2 more folders named QuantLibFramework and QuantLibResults respectively. Can I know what are they used for? Regards, Cheng -----邮件原件----- 发件人: Alexander Sokol [mailto:[hidden email]] 发送时间: 2015年2月10日 1:15 收件人: [hidden email] 主题: Re: [Quantlib-dev] Adjoint Greeks Peter, Luigi, Ferdinando: I am a bit late joining this discussion. I believe the approach of choosing AD vs. non-AD mode globally at compile time that you have discussed in the two messages quoted below may on the balance be the best choice for a large scale C++ library such as QuantLib. If we try to templatize nearly every class, in addition to the obscure compiler warning problems noted by Peter we will also see a major impact on compilation time, because a lot of the code will recompile the moment we touch any class. Also, as everyone noted earlier, this is not possible to do without a major overhaul of the entire code (turning a lot of .cpp files to .hpp headers and touching a lot of lines of code). Also, if the ultimate goal is to be able to select which type is using AD<double> and which type uses double, it may turn out that in the end the only two settings that will compile will be all-AD or no-AD settings, and the intermediate combinations will be hard to make compile and work. On the other hand, if we simply typedef Real to AD<double> (for CppAD) or adouble (for ADOL-C), and also ensure that a variable which has no tape pointer in it simply uses the internal double, then C++ inlining will likely reduce any performance impact. The advantage, as noted earlier in this thread, is that this can be done with minimal changes to the code base and hopefully can then be pulled into the master branch under a compile time define. Thanks to the great wisdom in using Real from the very beginning, this worked well without massive code changes. When I did the replacement and hit compile, it was about 150,000 line of C++ compiler errors (some lines of code were generating many lines of errors). After some tweaking which I committed to GitHub step by step, we are down to about 1000 errors and I do not see any major showstoppers in completing the conversion in a short period of time. For now I defined all variables as AD<double> except Time, but changed durations from Time to Real. I am currently trying to see if we should bite the bullet and use Real for Time as well, so we only have one type of double within the system. My code is in the following repos (expect rapid changes): Fork of Luigi's master, branch master-adjoint with changes: https://github.com/compatibl/quantlib/commits/master-adjoint Dependencies including a customized version of CppAD: https://github.com/compatibl/quantlib-dependencies To compile in adjoint mode, define QL_AD and put dependencies\cpp in the include path. Note that I had to make a minor change to CppAD. This change to CppAD is in dependencies, so only this version of CppAD wil work for now. If I do not manage to find a workaround will ask Brad Bell to pull my modification under a compile time define. It has to do with a constructor of AD<double> from another type with cast to double, which superseded the conversion we needed for InterestRate to AD<double>. See commit log for details. I will keep posting to this thread as we progress on this. Please let me know any comments, and please contact me if you wish to contribute to further development of this alternative approach, or use this repo. After the code compiles and runs, only then the real work will begin because the code will require considerable amount of AD-specific optimizations to outperform the brute force approach. But I am optimistic that it can be done with QuantLib. Best regards Alexander Sokol CompatibL > On Sun, Jan 11, 2015 at 7:16am, Luigi Ballabio wrote: > > Hi Peter, > you definitely need both double and CppAD<double>. I was > wondering if you needed a given engine if both adjoint and not-adjoint > implementation. > If not, you might choose at compile time. Otherwise, we'd have to bite > the bullet and templatize lots of stuff, as you're doing already. > > Luigi > > On Thu, Jan 8, 2015 at 8:56 PM, Peter Caspers wrote: > > I thought in a realistic application you would always need both > worlds, CppAD<double> for adjoint greek engines and double for all the > rest. I wonder what it would mean in terms of performance and memory > if you replace double by CppAD<double> in general. I can maybe just > stress test this a bit though. > Peter -- View this message in context: http://quantlib.10058.n7.nabble.com/Adjoint-Greeks-tp16147p16251.html Sent from the quantlib-dev mailing list archive at Nabble.com. ---------------------------------------------------------------------------- -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ QuantLib-dev mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/quantlib-dev ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ QuantLib-dev mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/quantlib-dev |
|
|
Hi Cheng
The Framework folder contains a data-driven interface around QuantLib we are wokring on, and the Results folder will have test results which will help establish that adjoint code works correctly. These are both in progress and are not yet ready for use. Regarding the conversion itself, we are already running with the entire library converted to use AD<double> instead of Real. However this required some changes in CppAD and so we did not release this code on GitHub, and instead tried to find a better way to approach the conversion. To address this problem, we took a slightly different approach - converted the code to use an internal inline class, which in turn contains AD<double>. This works with standard CppAD and will also work with other adjoint frameworks without further changes to QuantLib. The code is inlined, so there is no slowdown to speak of due to the introduction of this wrapper. I will publish the code shortly and post to this list, after which testing can commence! Best regards Alex |
|
|
Hi Alex, all,
more performance tests indicate that the slowdown factor 1.2 - 1.3 which I mentioned before (for AD<double> vs. double) is definitely the best case. As soon as the compiler can do serious floating point optimizations the factor gets higher. The highest value we saw so far was for matrix multiplication, here it is 18 for large matrices. Actual applications will lie somewhere in between probably, but it seems likely that you will want both double and AD<double> calculations mixed in your average ql application for that reason alone. So for the typedef-approach this means that you'd need to stitch two QuantLib copies together as Luigi proposed. What about the Settings class then, or the IndexManager and the like? Will there be a third namespace QuantLibShared (you can avoid the third one by accessing one of the two existing ones from the other, but the complexity introduced remains the same imo). Also if AD becomes an everyday tool, who would want to work with this kind of twin library in the long term if it can be avoided? I still think that patched AD frameworks would be very ugly. New wrappers in ql as a remedy are better, but again increase complexity. Correct me if I am wrong, but currently it seems that the only plus of the typedef-approach is that the necessary changes can be kept rather local. And the only minus of the template approach is that the whole codebase needs to be converted. But the target picture is clear, it is obvious what to do, it can be done in a reasonable amount of time and the result would be rather flawless with very few (if any) compromises. To put it differently, if this was the boost mailing list, we wouldn't have this discussion, would we ;-) But yes, sure, I also see the conflict if the primary goal is to conserve the current code basis. So probably it boils down to this question in the end. Best regards Peter On 2 March 2015 at 07:02, Alexander Sokol <[hidden email]> wrote: > Hi Cheng > > The Framework folder contains a data-driven interface around QuantLib we are > wokring on, and the Results folder will have test results which will help > establish that adjoint code works correctly. These are both in progress and > are not yet ready for use. > > Regarding the conversion itself, we are already running with the entire > library converted to use AD<double> instead of Real. However this required > some changes in CppAD and so we did not release this code on GitHub, and > instead tried to find a better way to approach the conversion. > > To address this problem, we took a slightly different approach - converted > the code to use an internal inline class, which in turn contains AD<double>. > This works with standard CppAD and will also work with other adjoint > frameworks without further changes to QuantLib. The code is inlined, so > there is no slowdown to speak of due to the introduction of this wrapper. I > will publish the code shortly and post to this list, after which testing can > commence! > > Best regards > Alex > > > > > > -- > View this message in context: http://quantlib.10058.n7.nabble.com/Adjoint-Greeks-tp16147p16292.html > Sent from the quantlib-dev mailing list archive at Nabble.com. > > ------------------------------------------------------------------------------ > Dive into the World of Parallel Programming The Go Parallel Website, sponsored > by Intel and developed in partnership with Slashdot Media, is your hub for all > things parallel software development, from weekly thought leadership blogs to > news, videos, case studies, tutorials and more. Take a look and join the > conversation now. http://goparallel.sourceforge.net/ > _______________________________________________ > QuantLib-dev mailing list > [hidden email] > https://lists.sourceforge.net/lists/listinfo/quantlib-dev ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ QuantLib-dev mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/quantlib-dev |
|
|
Hi Peter:
I am not yet ready to comment on the performance implications, but not becuase the initial test results are not clear - it is just that the bottleneck may not be as dependent to the overhead of "unused" adjoint variable. For example, if the bottleneck is in Monte Carlo, and by the time we get to Monte Carlo claculations every value in time slices is an AD variable, then there is no additional overhead at all and performance optimizations may turn out to be completely different from isolating non-AD variables from AD variables. On the other hand, the benefits of not touching much of the code are quite significant for continuity and avoiding a disruption to the codebase. So far I collected these changes in my master-adjoint-ready branch in github.com/compatibl/quantlib. They are faily minimal and I am planning to send Luigi a pull request shortly. Also, we confirmed that using a class for Real where inside is a regular double has no measurable performance impact at all because it is fully inlined. If we use our own class for Real, and inside that class place AD<double> or adouble, then the AD framework does not need to be patched at all. Best regards Alex |
|
|
Alex,
sure it is nice not to have to touch the code. I was just wondering if this is the only reason to follow this path or if there are other advantages ? Thanks Peter On 2 March 2015 at 21:18, Alexander Sokol <[hidden email]> wrote: > Hi Peter: > > I am not yet ready to comment on the performance implications, but not > becuase the initial test results are not clear - it is just that the > bottleneck may not be as dependent to the overhead of "unused" adjoint > variable. For example, if the bottleneck is in Monte Carlo, and by the time > we get to Monte Carlo claculations every value in time slices is an AD > variable, then there is no additional overhead at all and performance > optimizations may turn out to be completely different from isolating non-AD > variables from AD variables. > > On the other hand, the benefits of not touching much of the code are quite > significant for continuity and avoiding a disruption to the codebase. So far > I collected these changes in my master-adjoint-ready branch in > github.com/compatibl/quantlib. They are faily minimal and I am planning to > send Luigi a pull request shortly. Also, we confirmed that using a class for > Real where inside is a regular double has no measurable performance impact > at all because it is fully inlined. If we use our own class for Real, and > inside that class place AD<double> or adouble, then the AD framework does > not need to be patched at all. > > Best regards > Alex > > > > > > -- > View this message in context: http://quantlib.10058.n7.nabble.com/Adjoint-Greeks-tp16147p16294.html > Sent from the quantlib-dev mailing list archive at Nabble.com. > > ------------------------------------------------------------------------------ > Dive into the World of Parallel Programming The Go Parallel Website, sponsored > by Intel and developed in partnership with Slashdot Media, is your hub for all > things parallel software development, from weekly thought leadership blogs to > news, videos, case studies, tutorials and more. Take a look and join the > conversation now. http://goparallel.sourceforge.net/ > _______________________________________________ > QuantLib-dev mailing list > [hidden email] > https://lists.sourceforge.net/lists/listinfo/quantlib-dev ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ QuantLib-dev mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/quantlib-dev |
|
|
Hi Peter:
My impression currently is that keeping track of AD vs. non-AD variables manually and designing the code to compile with two different types of variables in different classes is going to be very cumbersome, and not necessarily effective in terms of performance. By the time we get to the slow part of the calculation such as lattice and Monte Carlo, the variables in the time slice will all have to be AD variables. If this is the case, then getting typedef to QlDouble, which in turn contains AD<double> as a data member, is the easiest and fastest way to get the entire library supporting AD. In fact, the conversion is already done and we are about to release the code on GitHub - currently testing and resolving the remaining issues with conversion of InterestRate to Real. I also think the work only just begins, because using AD effectively with Monte Carlo and other numerical techniques will require considerable amount of additional engineering - so we are still far from having an effective AD implementation for e.g. XVA or other numerical calculations where additional speed is most important. The version of the code with typedef only gets us to the starting line for that effort. Alex |
|
|
Hi Alex,
yes. I have other scenarios in mind. Like you have a demanding model calibration, say for a LFM just to name an example. You want to do this without AD of course. Then you have your actual exotic pricing with a Monte Carlo engine, where you want AD enabled to compute the deltas. Here you seem to need both calculations variants within one application and even have to transport the calibrated model from one to the other somehow. Thanks Peter On 3 March 2015 at 09:02, Alexander Sokol <[hidden email]> wrote: > Hi Peter: > > My impression currently is that keeping track of AD vs. non-AD variables > manually and designing the code to compile with two different types of > variables in different classes is going to be very cumbersome, and not > necessarily effective in terms of performance. By the time we get to the > slow part of the calculation such as lattice and Monte Carlo, the variables > in the time slice will all have to be AD variables. If this is the case, > then getting typedef to QlDouble, which in turn contains AD<double> as a > data member, is the easiest and fastest way to get the entire library > supporting AD. In fact, the conversion is already done and we are about to > release the code on GitHub - currently testing and resolving the remaining > issues with conversion of InterestRate to Real. > > I also think the work only just begins, because using AD effectively with > Monte Carlo and other numerical techniques will require considerable amount > of additional engineering - so we are still far from having an effective AD > implementation for e.g. XVA or other numerical calculations where additional > speed is most important. The version of the code with typedef only gets us > to the starting line for that effort. > > Alex > > > > > -- > View this message in context: http://quantlib.10058.n7.nabble.com/Adjoint-Greeks-tp16147p16296.html > Sent from the quantlib-dev mailing list archive at Nabble.com. > > ------------------------------------------------------------------------------ > Dive into the World of Parallel Programming The Go Parallel Website, sponsored > by Intel and developed in partnership with Slashdot Media, is your hub for all > things parallel software development, from weekly thought leadership blogs to > news, videos, case studies, tutorials and more. Take a look and join the > conversation now. http://goparallel.sourceforge.net/ > _______________________________________________ > QuantLib-dev mailing list > [hidden email] > https://lists.sourceforge.net/lists/listinfo/quantlib-dev ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ QuantLib-dev mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/quantlib-dev |
|
|
Hi Peter:
I agree that in this scenario, having them separate is beneficial if this can be accomplished in practice. Perhaps we need two separate branches, one for each approach, with two groups working in parallel. For the moment, my team is focusing on the typedef approach and taking the next step to making AD usable in practice with Monte Carlo. Best regards Alex |
|
|
Alex,
I will try to get an example like this working, then we can compare. Best regards Peter On 3 March 2015 at 09:43, Alexander Sokol <[hidden email]> wrote: > Hi Peter: > > I agree that in this scenario, having them separate is beneficial if this > can be accomplished in practice. Perhaps we need two separate branches, one > for each approach, with two groups working in parallel. > > For the moment, my team is focusing on the typedef approach and taking the > next step to making AD usable in practice with Monte Carlo. > > Best regards > Alex > > > > > -- > View this message in context: http://quantlib.10058.n7.nabble.com/Adjoint-Greeks-tp16147p16298.html > Sent from the quantlib-dev mailing list archive at Nabble.com. > > ------------------------------------------------------------------------------ > Dive into the World of Parallel Programming The Go Parallel Website, sponsored > by Intel and developed in partnership with Slashdot Media, is your hub for all > things parallel software development, from weekly thought leadership blogs to > news, videos, case studies, tutorials and more. Take a look and join the > conversation now. http://goparallel.sourceforge.net/ > _______________________________________________ > QuantLib-dev mailing list > [hidden email] > https://lists.sourceforge.net/lists/listinfo/quantlib-dev ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ QuantLib-dev mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/quantlib-dev |
Re: 答复: Adjoint Greeks
|
|
Hi Alex and Peter too bad in this period of my professional life I'm busy with other issues, as I would love to join you in this exciting endeavor (not sure you would appreciate, but that's another story... :-)I don't see your different approaches as conflicting: if Sokol's approach will not alter the QL codebase significantly, nothing is preventing Caspers' approach to be overlaid on the same QL codebase. To me this seems the best outcome: both alternatives being available to all users for experimenting, testing, and customizing solutions! In time we might settle on which would be the best practice for every different use case. just my $0.02 (or mBTC0.2) ciao -- Nando On Tue, Mar 3, 2015 at 10:12 AM, Peter Caspers <[hidden email]> wrote: Alex, ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ QuantLib-dev mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/quantlib-dev |
|
|
Hi all, well, the only sure thing seems to be that my idea won't work :) I agree with Peter, there's classes such as Settings that can't be duplicated in two namespaces. Oh well. As someone said already, I guess that for now you both might go ahead and see where you get. I can put your work in two branches on my repo if you think that people might feel more encouraged to try it out. (Also, I think that getting people to try out your code is the priority right now. I need feedback because I'm kind of between a rock and a hard place here, not wanting to hinder your progress but also having to check that nothing breaks, and that the barrier to adoption doesn't get too high---for instance, I like Peter's approach a lot, but I'm kind of scared to throw two pages of compilation errors at a user that makes a mistake...) (On a more personal note: I also have the problem of keeping honest and checking that I'm not just putting myself in the way of change because I'd have to revise my course material and book. People, please call me out on this if I don't realize I'm slipping.) Going back to technical stuff: - yes, the two approaches might overlay, but if Peter's approach is in place, you lose the simplicity of Alex's approach anyway and the typedef only sets the default. - about the wrapper class: Alexander, I was under the impression that the problems you were having could be solved just by specializing Null<AD<Real>> and giving it an appropriate conversion operator as Peter did. Did you have time to look at his code? If this work, you won't need the wrapper (which might add conversion issues, inlined or not). - in any case, I think the two approaches can both benefit from sharing changes. The specialized Null is one case; Alex's MC engineering would be another. Ok, enough for now, I guess... Later, Luigi On Tue, Mar 3, 2015 at 11:14 AM, Ferdinando M. Ametrano <[hidden email]> wrote:
------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ QuantLib-dev mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/quantlib-dev |
«
Return to quantlib-dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |