quantlib-dev — Discussion of QuantLib development

Re: [Quantlib-dev] 答复: 答复: 答复: Adjoint Greeks

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

unlikely (the optimization level)
Peter


On 14 January 2015 at 02:49, cheng li <scr...@gm...> 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:pca...@gm...]
> 发送时间: 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 <scr...@gm...> 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:lui...@gm...]
>> 发送时间: 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" <scr...@gm...> 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:pca...@gm...]
>> 发送时间: 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 <scr...@gm...> 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:pca...@gm...]
>>> 发送时间: 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 <lui...@gm...>
>>> 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
>>>> <fer...@am...> 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
>>>>> <pca...@gm...>
>>>>> 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
>>>>>> Qua...@li...
>>>>>> 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
>>>>> Qua...@li...
>>>>> 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
>>> Qua...@li...
>>> 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
>> Qua...@li...
>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>

[Quantlib-dev] 答复: 答复: 答复: Adjoint Greeks

[cheng l. <scr...@gm...>]

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:pca...@gm...] 
发送时间: 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 <scr...@gm...> 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:lui...@gm...]
> 发送时间: 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" <scr...@gm...> 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:pca...@gm...]
> 发送时间: 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 <scr...@gm...> 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:pca...@gm...]
>> 发送时间: 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 <lui...@gm...>
>> 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 
>>> <fer...@am...> 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 
>>>> <pca...@gm...>
>>>> 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
>>>>> Qua...@li...
>>>>> 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
>>>> Qua...@li...
>>>> 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
>> Qua...@li...
>> 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
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev

Re: [Quantlib-dev] 答复: 答复: Adjoint Greeks

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

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 <scr...@gm...> 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:lui...@gm...]
> 发送时间: 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" <scr...@gm...> 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:pca...@gm...]
> 发送时间: 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 <scr...@gm...> 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:pca...@gm...]
>> 发送时间: 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 <lui...@gm...>
>> 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
>>> <fer...@am...> 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
>>>> <pca...@gm...>
>>>> 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
>>>>> Qua...@li...
>>>>> 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
>>>> Qua...@li...
>>>> 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
>> Qua...@li...
>> 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
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev

[Quantlib-dev] 答复: 答复: Adjoint Greeks

[cheng l. <scr...@gm...>]

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:lui...@gm...] 
发送时间: 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" <scr...@gm... <mailto:scr...@gm...> > 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:pca...@gm... <mailto:pca...@gm...> ]
发送时间: 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 <scr...@gm... <mailto:scr...@gm...> > 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 <http://makefile.am>  to exclude them
> out the compiling process works fine.
>
>
> Regards,
> Cheng
>
> -----邮件原件-----
> 发件人: Peter Caspers [mailto:pca...@gm... <mailto:pca...@gm...> ]
> 发送时间: 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 <lui...@gm... <mailto:lui...@gm...> > 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
>> <fer...@am... <mailto:fer...@am...> > 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
>>> <pca...@gm... <mailto:pca...@gm...> >
>>> 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
>>>> Qua...@li... <mailto:Qua...@li...> 
>>>> 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
>>> Qua...@li... <mailto:Qua...@li...> 
>>> 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
> Qua...@li... <mailto:Qua...@li...> 
> 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 <http://www.gigenet.com> 
_______________________________________________
QuantLib-dev mailing list
Qua...@li... <mailto:Qua...@li...> 
https://lists.sourceforge.net/lists/listinfo/quantlib-dev

[Quantlib-dev] 答复: 答复: Adjoint Greeks

[cheng l. <scr...@gm...>]

Hi Peter,

I'll try again later on another machine with another compiler. 

Regards,
Cheng

-----邮件原件-----
发件人: Peter Caspers [mailto:pca...@gm...] 
发送时间: 2015年1月12日 23:59
收件人: Luigi Ballabio
抄送: Cheng Li; QuantLib developers
主题: Re: [Quantlib-dev] 答复: Adjoint Greeks

oh, actually -temporarily- I need C++11 in the adjoint branch, because I wrote some constexpr declarations (will have to revisit this later).
Also I wrote default template parameters (T = Real) that have to be removed again for 03 I guess.

Is this problem gcc 4.9.2 specific ? I have 4.9.1 and everything compiles fine (except some auto_ptr - deprecated - warnings). Also my local branch is consistent with the one on github.

Or maybe run "make clean" before compiling ?

Peter

On 12 January 2015 at 07:27, Luigi Ballabio <lui...@gm...> wrote:
> Don't use C++11.
>
> Luigi
>
> On Jan 12, 2015 4:53 AM, "cheng li" <scr...@gm...> 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:pca...@gm...]
>> 发送时间: 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 <scr...@gm...> 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:pca...@gm...]
>> > 发送时间: 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 
>> > <lui...@gm...>
>> > 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 
>> >> <fer...@am...> 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 
>> >>> <pca...@gm...>
>> >>> 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
>> >>>> Qua...@li...
>> >>>> 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
>> >>> Qua...@li...
>> >>> 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
>> > Qua...@li...
>> > 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
>> Qua...@li...
>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev

Re: [Quantlib-dev] Intraday patch

[Joseph W. <joe...@gm...>]

One other change that I'd like to see made is to rename the interface
"yearFraction" to "timeFraction" with yearFraction being a backward
compatible but deprecated interface.

The reason for this is that the ContinuousTime day counter allows one
to specific quantities in terms of perDay, perWeek, or perMonth
quantities, and this is relevant for bitcoin where interest rates are
specified per day rather than per year.

On Tue, Jan 13, 2015 at 2:09 AM, Joseph Wang <joe...@gm...> wrote:
> The only reason I created a subclass of Date was to avoid making any
> changes to the Date class.  If there is a consensus to go with the new
> Date classes, then once that is in place, I can port the
> ContinuousTime date counters to use the new Date class.
>
> On Tue, Jan 13, 2015 at 1:54 AM, Klaus Spanderen <kl...@sp...> wrote:
>> Hi Joseph
>>
>> what is the best approach to merge both solutions? I do like your way of
>> adding new day counters which can deal with intraday resolution, especially a
>> Actual365 day counter, which reflects the opening hours of the exchange is a
>> good idea for non-bitcoin stuff.
>>
>> But the concepts for he Date classes are mutual exclusive.
>>
>> regards
>> Klaus
>>
>> On Monday, January 05, 2015 10:03:28 AM Joseph Wang wrote:
>>> I think that both patches would work for different use cases.
>>>
>>> My patch was specifically focused on dealing with bitcoin derivatives,
>>> so it intentionally works as only a UTC timestamp without any
>>> additional timezone data.  Also bitcoin does everything on a per day
>>> basis, which means that I had to create a new day counter.
>>>
>>> One thing that I've seen done which would require some more
>>> sophistication in the Date class is to have special tags for "start of
>>> day" and "end of day".
>>>
>>> Also there is massively interesting quant work to be done with bitcoin
>>> futures.
>>>
>>> 1) there are two types of futures on bitmex.  One is quanto style.
>>> The other is inverse style.  Details on the each type are on their
>>> site, but there appears to be a convexity adjustment between the two.
>>>
>>> 2) counterparty risk modelling - The Chinese exchanges have something
>>> called "loss socialization".  This is a situation in which they mess
>>> up margining, the exchange ends up with a loss, which they "socialize"
>>> against the people that made money.  Modelling this is quite
>>> interesting.  One thing that is particularly interesting is that
>>> counterparty risk does not affect price.  It does affect volume in a
>>> big way.  The Chinese exchanges are very liquid with short dated
>>> futures, but volume goes down dramatically for long dated futures.
>>>
>>> 3) general trading issues - This is where derivatives pricing meets
>>> trading.  Derivative pricing has traditionally not involved many
>>> issues of flow trading.  However, with bitcoin futures, you end up
>>> having to deal with things like bid-ask spreads.
>>>
>>> 4) Bootstrapping an IR curve - You can think of bitcoin futures as an
>>> interest rate product, which means that the only way you get a term
>>> structure curve with bitcoin is through the futures market.  There is
>>> now enough data to start modelling that curve.  In particular, the low
>>> end of that curve is fixed by the BFX swap markets.
>>>
>>> On Mon, Jan 5, 2015 at 6:36 AM, Dirk Eddelbuettel <ed...@de...> wrote:
>>> > Klaus,
>>> >
>>> > On 4 January 2015 at 22:58, Klaus Spanderen wrote:
>>> > | Hi Joe,
>>> > |
>>> > | I was struggling with the same problem of intraday pricing a while ago.
>>> > | I've now found  the time to bundle my solution into a patch.
>>> > |
>>> > | In short, I've added intraday resolution directly to QuantLib's Date
>>> > | class
>>> > | using boost::posix_time::ptime while keeping the existing interfaces and
>>> > | behavior the same. The test suite runs unchanged with the new Date
>>> > | class. If you are interest then please find more details
>>> > |
>>> > | https://hpcquantlib.wordpress.com/2015/01/04/intraday-high-resolution-da
>>> > | y-counters/>
>>> > This sounds excellent, and reads very well. Wonderful news!
>>> >
>>> > That said, I don't mean to take away from Joe's work which I meant to look
>>> > at but had not found time to actually do so. Being backwards compatible
>>> > could well be the key feature here.
>>> >
>>> > Exciting times ahead, along with Peter's AD magic...
>>> >
>>> > Dirk
>>> >
>>> > --
>>> > http://dirk.eddelbuettel.com | @eddelbuettel | ed...@de...
>>

Re: [Quantlib-dev] Intraday patch

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

Hi Joseph

what is the best approach to merge both solutions? I do like your way of 
adding new day counters which can deal with intraday resolution, especially a 
Actual365 day counter, which reflects the opening hours of the exchange is a 
good idea for non-bitcoin stuff.

But the concepts for he Date classes are mutual exclusive.

regards
Klaus   

On Monday, January 05, 2015 10:03:28 AM Joseph Wang wrote:
> I think that both patches would work for different use cases.
> 
> My patch was specifically focused on dealing with bitcoin derivatives,
> so it intentionally works as only a UTC timestamp without any
> additional timezone data.  Also bitcoin does everything on a per day
> basis, which means that I had to create a new day counter.
> 
> One thing that I've seen done which would require some more
> sophistication in the Date class is to have special tags for "start of
> day" and "end of day".
> 
> Also there is massively interesting quant work to be done with bitcoin
> futures.
> 
> 1) there are two types of futures on bitmex.  One is quanto style.
> The other is inverse style.  Details on the each type are on their
> site, but there appears to be a convexity adjustment between the two.
> 
> 2) counterparty risk modelling - The Chinese exchanges have something
> called "loss socialization".  This is a situation in which they mess
> up margining, the exchange ends up with a loss, which they "socialize"
> against the people that made money.  Modelling this is quite
> interesting.  One thing that is particularly interesting is that
> counterparty risk does not affect price.  It does affect volume in a
> big way.  The Chinese exchanges are very liquid with short dated
> futures, but volume goes down dramatically for long dated futures.
> 
> 3) general trading issues - This is where derivatives pricing meets
> trading.  Derivative pricing has traditionally not involved many
> issues of flow trading.  However, with bitcoin futures, you end up
> having to deal with things like bid-ask spreads.
> 
> 4) Bootstrapping an IR curve - You can think of bitcoin futures as an
> interest rate product, which means that the only way you get a term
> structure curve with bitcoin is through the futures market.  There is
> now enough data to start modelling that curve.  In particular, the low
> end of that curve is fixed by the BFX swap markets.
> 
> On Mon, Jan 5, 2015 at 6:36 AM, Dirk Eddelbuettel <ed...@de...> wrote:
> > Klaus,
> > 
> > On 4 January 2015 at 22:58, Klaus Spanderen wrote:
> > | Hi Joe,
> > | 
> > | I was struggling with the same problem of intraday pricing a while ago.
> > | I've now found  the time to bundle my solution into a patch.
> > | 
> > | In short, I've added intraday resolution directly to QuantLib's Date
> > | class
> > | using boost::posix_time::ptime while keeping the existing interfaces and
> > | behavior the same. The test suite runs unchanged with the new Date
> > | class. If you are interest then please find more details
> > | 
> > | https://hpcquantlib.wordpress.com/2015/01/04/intraday-high-resolution-da
> > | y-counters/> 
> > This sounds excellent, and reads very well. Wonderful news!
> > 
> > That said, I don't mean to take away from Joe's work which I meant to look
> > at but had not found time to actually do so. Being backwards compatible
> > could well be the key feature here.
> > 
> > Exciting times ahead, along with Peter's AD magic...
> > 
> > Dirk
> > 
> > --
> > http://dirk.eddelbuettel.com | @eddelbuettel | ed...@de...

[Quantlib-dev] 答复: Adjoint Greeks

[cheng l. <scr...@gm...>]

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:pca...@gm...]
发送时间: 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 <scr...@gm...> 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:pca...@gm...]
> 发送时间: 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 <lui...@gm...> 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 
>> <fer...@am...> 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 
>>> <pca...@gm...>
>>> 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
>>>> Qua...@li...
>>>> 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
>>> Qua...@li...
>>> 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
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>

[Quantlib-dev] Contribution Request

[Richard P. <pos...@gm...>]

Hi all,

I am a recent graduate of a financial engineering program.  I have 2 years
professional experience in Python, 1 year in Clojure, and working knowledge
of C++.  I want to start contributing to quantlib.  What suggestions do you
have on how I can start?

-- 
Rich

[Quantlib-dev] 答复: 答复: Adjoint Greeks

[Cheng L. <scr...@gm...>]

Oops... my fault...

Thank you peter, I'll try again with adjoint branch.

Regards,
Cheng

-----邮件原件-----
发件人: Peter Caspers [mailto:pca...@gm...] 
发送时间: 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 <scr...@gm...> 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:pca...@gm...]
> 发送时间: 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 <lui...@gm...> 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 
>> <fer...@am...> 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 
>>> <pca...@gm...>
>>> 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
>>>> Qua...@li...
>>>> 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
>>> Qua...@li...
>>> 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
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>

Re: [Quantlib-dev] Adjoint Greeks

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

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 <pca...@gm...>
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
>
>
>
> On 7 January 2015 at 10:23, Luigi Ballabio <lui...@gm...>
> 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
> > <fer...@am...> 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 <pca...@gm...>
> >> 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
> >>> Qua...@li...
> >>> 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
> >> Qua...@li...
> >> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
> >>
> >
> >
> >
> > --
> > <https://implementingquantlib.blogspot.com>
> > <https://twitter.com/lballabio>
>



-- 
<https://implementingquantlib.blogspot.com>
<https://twitter.com/lballabio>

Re: [Quantlib-dev] 答复: Adjoint Greeks

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

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 <scr...@gm...> 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:pca...@gm...]
> 发送时间: 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 <lui...@gm...> 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
>> <fer...@am...> 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
>>> <pca...@gm...>
>>> 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
>>>> Qua...@li...
>>>> 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
>>> Qua...@li...
>>> 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
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>

[Quantlib-dev] 答复: Adjoint Greeks

[Cheng L. <scr...@gm...>]

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:pca...@gm...] 
发送时间: 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 <lui...@gm...> 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 
> <fer...@am...> 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 
>> <pca...@gm...>
>> 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
>>> Qua...@li...
>>> 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
>> Qua...@li...
>> 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
Qua...@li...
https://lists.sourceforge.net/lists/listinfo/quantlib-dev

Re: [Quantlib-dev] Adjoint Greeks

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

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 <lui...@gm...> 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
> <fer...@am...> 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 <pca...@gm...>
>> 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
>>> Qua...@li...
>>> 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
>> Qua...@li...
>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>>
>
>
>
> --
> <https://implementingquantlib.blogspot.com>
> <https://twitter.com/lballabio>

Re: [Quantlib-dev] Adjoint Greeks

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

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 <
fer...@am...> 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 <pca...@gm...>
> 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
>> Qua...@li...
>> 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
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>
>


-- 
<https://implementingquantlib.blogspot.com>
<https://twitter.com/lballabio>

Re: [Quantlib-dev] Adjoint Greeks

[Ferdinando M. A. <fer...@am...>]

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 <pca...@gm...>
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
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>

Re: [Quantlib-dev] 答复: Adjoint Greeks

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

Hi Cheng,
yes, exactly, Sebastian applied AD to vega computation in the Hull
White Model if I remember correctly.
It would be great, if you would join in.
Peter

On 5 January 2015 at 02:47, cheng li <scr...@gm...> wrote:
> Hi Peter,
>
> I have recently read the presentation writtern by Sebastian on qlws13. Are
> your idea similar with his? Roughly both are template based? I am always
> very interested in AD method but never know how to start from scratch...
>
> I'd like to follow your branch and try to follow the algorithms. Once I got
> that basis, I am very glad to help you to continue the development~
>
> Regards,
> Cheng
>
> -----邮件原件-----
> 发件人: Peter Caspers [mailto:pca...@gm...]
> 发送时间: 2015年1月5日 4:55
> 收件人: QuantLib Mailing Lists
> 主题: [Quantlib-dev] Adjoint Greeks
>
> 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
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>

Re: [Quantlib-dev] Intraday patch

[Joseph W. <joe...@gm...>]

I think that both patches would work for different use cases.

My patch was specifically focused on dealing with bitcoin derivatives,
so it intentionally works as only a UTC timestamp without any
additional timezone data.  Also bitcoin does everything on a per day
basis, which means that I had to create a new day counter.

One thing that I've seen done which would require some more
sophistication in the Date class is to have special tags for "start of
day" and "end of day".

Also there is massively interesting quant work to be done with bitcoin futures.

1) there are two types of futures on bitmex.  One is quanto style.
The other is inverse style.  Details on the each type are on their
site, but there appears to be a convexity adjustment between the two.

2) counterparty risk modelling - The Chinese exchanges have something
called "loss socialization".  This is a situation in which they mess
up margining, the exchange ends up with a loss, which they "socialize"
against the people that made money.  Modelling this is quite
interesting.  One thing that is particularly interesting is that
counterparty risk does not affect price.  It does affect volume in a
big way.  The Chinese exchanges are very liquid with short dated
futures, but volume goes down dramatically for long dated futures.

3) general trading issues - This is where derivatives pricing meets
trading.  Derivative pricing has traditionally not involved many
issues of flow trading.  However, with bitcoin futures, you end up
having to deal with things like bid-ask spreads.

4) Bootstrapping an IR curve - You can think of bitcoin futures as an
interest rate product, which means that the only way you get a term
structure curve with bitcoin is through the futures market.  There is
now enough data to start modelling that curve.  In particular, the low
end of that curve is fixed by the BFX swap markets.



On Mon, Jan 5, 2015 at 6:36 AM, Dirk Eddelbuettel <ed...@de...> wrote:
>
> Klaus,
>
> On 4 January 2015 at 22:58, Klaus Spanderen wrote:
> | Hi Joe,
> |
> | I was struggling with the same problem of intraday pricing a while ago. I've
> | now found  the time to bundle my solution into a patch.
> |
> | In short, I've added intraday resolution directly to QuantLib's Date class
> | using boost::posix_time::ptime while keeping the existing interfaces and
> | behavior the same. The test suite runs unchanged with the new Date class. If
> | you are interest then please find more details
> |
> | https://hpcquantlib.wordpress.com/2015/01/04/intraday-high-resolution-day-counters/
>
> This sounds excellent, and reads very well. Wonderful news!
>
> That said, I don't mean to take away from Joe's work which I meant to look at
> but had not found time to actually do so. Being backwards compatible could
> well be the key feature here.
>
> Exciting times ahead, along with Peter's AD magic...
>
> Dirk
>
> --
> http://dirk.eddelbuettel.com | @eddelbuettel | ed...@de...

[Quantlib-dev] 答复: Adjoint Greeks

[cheng l. <scr...@gm...>]

Hi Peter,

I have recently read the presentation writtern by Sebastian on qlws13. Are
your idea similar with his? Roughly both are template based? I am always
very interested in AD method but never know how to start from scratch...

I'd like to follow your branch and try to follow the algorithms. Once I got
that basis, I am very glad to help you to continue the development~

Regards,
Cheng

-----邮件原件-----
发件人: Peter Caspers [mailto:pca...@gm...] 
发送时间: 2015年1月5日 4:55
收件人: QuantLib Mailing Lists
主题: [Quantlib-dev] Adjoint Greeks

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
Qua...@li...
https://lists.sourceforge.net/lists/listinfo/quantlib-dev

Re: [Quantlib-dev] Intraday patch

[Dirk E. <ed...@de...>]

Klaus,

On 4 January 2015 at 22:58, Klaus Spanderen wrote:
| Hi Joe,
| 
| I was struggling with the same problem of intraday pricing a while ago. I've 
| now found  the time to bundle my solution into a patch. 
| 
| In short, I've added intraday resolution directly to QuantLib's Date class 
| using boost::posix_time::ptime while keeping the existing interfaces and 
| behavior the same. The test suite runs unchanged with the new Date class. If 
| you are interest then please find more details 
| 
| https://hpcquantlib.wordpress.com/2015/01/04/intraday-high-resolution-day-counters/

This sounds excellent, and reads very well. Wonderful news!

That said, I don't mean to take away from Joe's work which I meant to look at
but had not found time to actually do so. Being backwards compatible could
well be the key feature here.

Exciting times ahead, along with Peter's AD magic...

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | ed...@de...

Re: [Quantlib-dev] Intraday patch

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

Hi Joe,

I was struggling with the same problem of intraday pricing a while ago. I've 
now found  the time to bundle my solution into a patch. 

In short, I've added intraday resolution directly to QuantLib's Date class 
using boost::posix_time::ptime while keeping the existing interfaces and 
behavior the same. The test suite runs unchanged with the new Date class. If 
you are interest then please find more details 

https://hpcquantlib.wordpress.com/2015/01/04/intraday-high-resolution-day-counters/

regards
 Klaus

On Monday, December 22, 2014 03:58:19 PM Joseph Wang wrote:
> I've just pushed up a patch to quantlib that provides basic support
> for intraday calculations.  The patch consists of two new classes
> 
> timestamp - which is a simple UTC timestamp class.  It is a subclass
> of Date, and can be used whereever date is.
> 
> continoustime - is a day counter that supports intraday calculations
> with timestamp.  ContinousTime allows the user to specify the base
> unit, so it is now possible to specify
> interest rates and volatility per day, per week, or per month (which
> is defined as 30 days) rather than per year.
> 
> The only non backward compartible part is the use of "yearFraction" to
> specify something other than a fraction of a year.  There is a
> function "timeFraction" which calls yearFraction.
> 
> Also this counter does not handle leap seconds, but I plan to add that.
> 
> I also intentionally left time zones out of these additions since
> that's another level of complexity.
> 
> I can write some unit tests and I'll add some more comments.  However,
> before I do, I'd like some feedback about the general class structure
> and to go through a code review.
> 
> Below is python code that uses the new interface
> 
> def option(strike, vol, t, putcall):
>     now = TimeStamp.now()
>     Settings.instance().evaluationDate = now
>     settlementDate = todaysDate + Period(3, Weeks)
>     riskFreeRate = FlatForward(settlementDate, 0.00,
> ContinuousTime.perDay())
> 
>     # option parameters
>     exercise = EuropeanExercise(settlementDate)
>     payoff = PlainVanillaPayoff(Option.Call, strike)
>     x = np.arange(strike*0.8, strike*1.2, 0.01);
> 
>     volatility = BlackConstantVol(todaysDate, TARGET(), vol,
> ContinuousTime.perDay())
>     dividendYield = FlatForward(settlementDate, 0.00,
> ContinuousTime.perDay()) underlying = SimpleQuote(0.0)
>     process = BlackScholesMertonProcess(QuoteHandle(underlying),
>                                     YieldTermStructureHandle(dividendYield),
> YieldTermStructureHandle(riskFreeRate),
> BlackVolTermStructureHandle(volatility)) option = VanillaOption(payoff,
> exercise)
>     # method: analytic
>     option.setPricingEngine(AnalyticEuropeanEngine(process))
>     def myfunc(x):
>         underlying .setValue(x)
>         return option.NPV()
>     def mydelta(x):
>         underlying.setValue(x)
>         return option.delta()
>     def mytheta(x):
>         underlying.setValue(x)
>         return option.theta()
>     plt.figure(1, figsize=(5,8))
>     plt.subplot(211)
>     y = map(payoff, x)
>     plt.plot(x, y)
>     plt.plot(x, map(myfunc,x))
>     plt.subplot(212)
>     plt.plot(x, map(mydelta,x))
> 
> ----------------------------------------------------------------------------
> -- 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=164703151&iu=/4140/ostg.clktrk
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev

[Quantlib-dev] Adjoint Greeks

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

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

[Quantlib-dev] Pushed docker image with ipython-quantlib and r-quantlib

[Joseph W. <joe...@gm...>]

I just pushed a docker image joequant/bitstation-prod to the docker
hub.  This contains an image with an internal ipython notebook and r
notebook web system that also contains python-quantlib and r-quantlib
installed.  It also contains pre-installed python goodies like
pyalgotrade, qstk, zipline and every other python and R package I
could think of that has to do with quant work.

I'm going to be doing some quant work with bitcoin futures next week.
Essentially, I'm going to try to derive a yield curve from market
data.

Also, I'm taking a close look at jupyter and some of the other ipython
notebook based systems.

Re: [Quantlib-dev] Possible future works

[Joseph W. <joe...@gm...>]

FYI, I worked at a major investment bank until a year ago when I
started my own company, and the derivatives trading pricing code had
only one feature that quantlib doesn't have, and that's the ability to
dynamically load in parts of the code.

The issue is that because all of the derivatives code is in one
library, it becomes impossible to load in the entire pricing library.
So there is a slick infrastructure in which the derivatives library is
modularized into dozens of small dynamic modules.  When a system needs
to run a c++ class, the system tracks which module it is in and it
autoloads that module.  This was also a bit tricky since it had to run
on both Windows and linux systems.

It would be interesting to see if this could be implemented in
QuantLib.  The autoloading mechanism was written by one person who
took a few months to do it.  Personally, I don't think it would be
worth while to write an autoload mechanism from scratch, but I'd be
interested in knowing if there was some off the shelf system that
could be adapted for quantlib.

Something that would be more low hanging fruit which would be easier
would be to just generate several shared libraries instead of one big
shared library or to have a mechanism by which someone can add a class
to QuantLib, put it into a shared library and be able to work on that
without having to do a complete recompile/relink of the library.

Re: [Quantlib-dev] Possible future works

[Joseph W. <joe...@gm...>]

Hi Xiang Ni,

I'm trying to use quantlib for some very basic algo trading with
bitcoin futures.  My wife is also trading HK options, and I'm trying
to write some very basic option pricing systems for her.

My general impression is that it would be better to keep quantlib a
pure derivatives pricing library, and that anything involving machine
learning or algo trading, would be better off in a library that is
separate from quantlib.

The way that I'm structuring my code is that I'm using the python-SWIG
interface to quantlib, and using quantlib only for pricing.
Everything else I'm keeping outside of quantlib, and interface it with
quantlib.  So it would make sense to me to write your code as a
separate library with python interfaces and then use it to glue it to
quantlib.

I have a docker image (joequant/bitstation-prod). that has a installed
python installation with quantlib and a lot of other goodies
installed.