Login  Register

Re: Adjoint Greeks

Posted by Alexander Sokol on Feb 10, 2015; 6:04pm
URL: http://quantlib.414.s1.nabble.com/Adjoint-Greeks-tp16147p16258.html

Hi Peter:

Thank you for your comments! I think even if manage to integrate AD into the master branch without the disruption of switching to a headers-only QuantLib or massive code changes, and only lose 20-30 percent in performance relative to the optimal assignment of Real vs. double inside each class, it would already be a good result. But I believe the impact in Release mode can be reduced even further by optimizing arithmetic operations that involve AD<double> objects with null tape pointer. We will run performance tests as soon as the conversion is finished. I hope for a less than 20% impact overall once all optimizations are done.

Also, if we are comparing to the template based approach, it seems that the optimal assignment of Real vs. double cannot be done purely at the level of the entire class. For example, among multiple parameters that a method takes, depending on how it is used, some may have to be AD<double> and others have to be double. And of course it is not desirable if the code has to be recompiled with different template arguments for every mode of use. It is not clear if the perfect assignment of AD<double> vs double can be achieved in a way that does not compromise convenience for the end user.

One more comment - because Luigi, Ferdinando & Co not only had the foresight to introduce Real, but also introduced Time as distinct from Real (which for now I decided to keep as double), we can avoid using AD variables for anything related to the times, schedules, etc. This is a large chunk of the code that will not be using AD<double> needlessly. So overall I am hopeful that the approach will prove viable.

Best regards
Alex

-----Original Message-----
From: Peter Caspers [mailto:[hidden email]]
Sent: Tuesday, February 10, 2015 12:49 PM
To: Alexander Sokol
Cc: QuantLib Mailing Lists
Subject: Re: [Quantlib-dev] Adjoint Greeks

Hi Alexander,

I agree with most of your points. With the typedef-approach we surely have less code changes. Also it will be easy to merge them into the original code.

What I am not sure about is how to address the performance loss in parts of your application where you do not need AD. Using AD<double>
(naively) instead of double slows down my vanilla swap example by 20 -
30 percent. Is that connected to your comment about the AD-specific optimizations needed later on ? Can you be more specific on this part in general maybe ?

Concerning your CppAD patch, I did not look into it, but it sounds similar to what I saw when implementing the Null<AD<Base>> class. With templates it's easy to get a clean solution though. A dependency on a patch for an AD framework would not be very nice in my opinion.

Well let's see. In any case it will be nice to compare both approaches once working for real life problems, won't it.

Best regards
Peter

------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev