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>