|
From: Peter C. <pca...@gm...> - 2015-01-08 19:56:46
|
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> |