Posted by
cheng li on
Jan 11, 2015; 9:16am
URL: http://quantlib.414.s1.nabble.com/Adjoint-Greeks-tp16147p16166.html
Hi Peter,
Thank you for your kindly offer these new stuff for all of us!
I have cloned your branch and tried to build it on my machine. When it was
building the example/InterestRateSmile, the compiler complained as
following:
InterestRateSmiles.cpp: In function ‘void zabrExamples()’:
InterestRateSmiles.cpp:64:39: error: type/value mismatch at argument 1 in
template parameter list for ‘template<class T> class boost::shared_ptr’
boost::shared_ptr<ZabrSmileSection> zabrln =
^
InterestRateSmiles.cpp:64:39: error: expected a type, got
‘ZabrSmileSection’
InterestRateSmiles.cpp:64:48: error: invalid type in declaration before
‘=’ token
boost::shared_ptr<ZabrSmileSection> zabrln =
^
InterestRateSmiles.cpp:67:13: error: ‘template<class Evaluation> class
QuantLib::ZabrSmileSection’ used without template parameters
ZabrSmileSection::ShortMaturityLognormal);
I am not sure what is the problem... Is it due to missing template argument
for ZabrSmileSection?
My compiler is g++ 4.8.2 and with parameter "-std=c++11 -O3"
BTW, I found that quadraticlfm.hpp and quadraticlfm.cpp are missing from the
branch. However when I adjust the makefile.am to exclude them out the
compiling process works fine.
Regards,
Cheng
-----邮件原件-----
发件人: Peter Caspers [mailto:
[hidden email]]
发送时间: 2015年1月9日 3:57
收件人: Luigi Ballabio
抄送: QuantLib Mailing Lists; Ferdinando M. Ametrano
主题: Re: [Quantlib-dev] Adjoint Greeks
I thought in a realistic application you would always need both worlds,
CppAD<double> for adjoint greek engines and double for all the rest. I
wonder what it would mean in terms of performance and memory if you replace
double by CppAD<double> in general. I can maybe just stress test this a bit
though.
Peter
On 7 January 2015 at 10:23, Luigi Ballabio <
[hidden email]> wrote:
> Switching Real would force you to fix compilation problems all over
> the library, instead of just in the code you're converting.
>
> If you wanted to go the route of #defining the type, I guess you could
> introduce another type (ADReal or something) and switch the coverted
> code to use it.
> Which might or might not be a good idea; you wouldn't be forced to
> templatize the code, but you would have to choose AD or not at
> compilation time, instead that having the choice to use both for different
tasks. Hmm...
>
> Anyway: yes, very promising. Between Peter, Klaus and Joseph, we got a
> lot of presents this Christmas :)
>
> Luigi
>
>
>
> On Wed, Jan 7, 2015 at 9:41 AM, Ferdinando M. Ametrano
> <
[hidden email]> wrote:
>>
>> Thank you Peter, it sounds exciting and promising.
>> Why haven't you considered to just change the Real typedef from
>> double to CppAD::AD<double>?
>>
>> On Sun, Jan 4, 2015 at 9:55 PM, Peter Caspers
>> <
[hidden email]>
>> wrote:
>>>
>>> Hello all,
>>>
>>> happy new year.
>>>
>>> I revisited Ferdinando's comments on adjoint greeks during our
>>> December workshop and started to play around with that idea.
>>>
>>> The approach I am trying to follow is to adapt the ql library code
>>> so that automatic differentiation _tools_ can be used with it in a
>>> transparent way. This is opposed to writing special adjoint engines
>>> by _hand_ like e.g. advocated in Capriotti, Giles, Algorithmic
>>> Differentiation: Adjoint Greeks Made Easy. The relatively small and
>>> homogeneous code basis of ql seems to allow for this kind of more
>>> fundamental approach.
>>>
>>> I wrote a bit about my first steps in my blog
>>>
>>>
http://quantlib.wordpress.com/>>>
>>> and forked a new branch from Luigi's current master on github
>>>
>>>
https://github.com/pcaspers/quantlib/tree/adjoint>>>
>>> where I started to template'ize the library in order to allow for AD
>>> tools to hook in. There are already first working examples (see the
>>> blog) and I am starting to feel confident that the approach might
>>> work as a whole, might be doable in a reasonable amount of time and
>>> is worthwhile following.
>>>
>>> About the feasibility: The library seems to consist of roughly 376k
>>> lines of code currently (all hpp and cpp files under ql / ). From
>>> that we can subtract "data" files
>>>
>>> 78862 ./math/randomnumbers/sobolrsg.cpp
>>> 21376 ./math/randomnumbers/primitivepolynomials.cpp
>>> 14495 ./math/randomnumbers/latticerules.cpp
>>> 10115 ./experimental/volatility/noarbsabrabsprobs.cpp
>>>
>>> which leaves us with 251k lines. It seems that I have already
>>> reviewed and adapted around 14k lines, which is 5% and which took me
>>> approximately 60 hours. This gives an estimation of 130 person days
>>> still left to do. For the whole (!) library where already parts will
>>> make much sense and give interesting applications. E.g. excluding
>>> experimental classes (90k) and the market model (25k) reduces the
>>> estimate already to 65 person days to go.
>>>
>>> I would be interested in your opinions on that, in particular
>>> regarding the design choices to make (better now than later :-) ).
>>>
>>> I'd also be grateful for people supporting the development by
>>> forking the adjoint branch and sending pull requests with adapted code
pieces.
>>> My personal next steps would be
>>> - rate deltas for Legs / Swap instruments
>>> - rate vegas for vanilla interest rate options
>>> - Hull White model
>>>
>>> What do you think ?
>>>
>>> Thank you
>>> Peter
>>>
>>>
>>> --------------------------------------------------------------------
>>> ---------- Dive into the World of Parallel Programming! The Go
>>> Parallel Website, sponsored by Intel and developed in partnership
>>> with Slashdot Media, is your hub for all things parallel software
>>> development, from weekly thought leadership blogs to news, videos,
>>> case studies, tutorials and more. Take a look and join the
>>> conversation now.
http://goparallel.sourceforge.net
>>> _______________________________________________
>>> QuantLib-dev mailing list
>>>
[hidden email]
>>>
https://lists.sourceforge.net/lists/listinfo/quantlib-dev>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> --------- Dive into the World of Parallel Programming! The Go
>> Parallel Website, sponsored by Intel and developed in partnership
>> with Slashdot Media, is your hub for all things parallel software
>> development, from weekly thought leadership blogs to news, videos,
>> case studies, tutorials and more. Take a look and join the
>> conversation now.
http://goparallel.sourceforge.net
>> _______________________________________________
>> QuantLib-dev mailing list
>>
[hidden email]
>>
https://lists.sourceforge.net/lists/listinfo/quantlib-dev>>
>
>
>
> --
> <
https://implementingquantlib.blogspot.com>
> <
https://twitter.com/lballabio>
----------------------------------------------------------------------------
--
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now.
http://goparallel.sourceforge.net_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now.
http://goparallel.sourceforge.net_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev