Re: Adjoint Greeks

Posted by Luigi Ballabio on Feb 18, 2015; 2:24pm
URL: http://quantlib.414.s1.nabble.com/Adjoint-Greeks-tp16147p16272.html

Hi Peter and Alexander,

    apologies for chiming in so late. I've been thinking a bit about this, and as usual I didn't make up my mind, as I seem to agree with both of you :)

I agree with Alexander that the typedef approach is surely less scary than templatizing most of the library (especially from my other perspective of having to teach and write about the library from time to time...) but I also see Peter's point of not having to pay for adjoints when one doesn't use them.

So, here's a crazy idea. Feel free to punch holes in it as you see fit. In the template approach, AD and Real versions of objects are not really compatible as I understand it; that is, you can't set an engine using AD<Real> to an instrument using Real (is this correct, Peter?) so in a way, it's as if they're part of two different libraries.  What if one actually made two different libraries, one compiled with Real and the other with AD<Real>? Using a macro to change the namespace in the second one to something like QuantLibAD should be enough to prevent resolution conflicts when using both. What do you think?

About the CppAD patch: yes, having to rely on a patch is kind of awkward. Alexander, did you try looking into Peter's solution for this? (If I remember correctly, it was a specialization of our Null class for AD<double> which you could integrate in your code.)

Needless to say, I would be a very happy maintainer if I got the two of you on the same project instead of two competing ones...

Later,

    Luigi

On Tue, Feb 10, 2015 at 7:04 PM, Alexander Sokol <[hidden email]> wrote:

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

--

------------------------------------------------------------------------------
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=190641631&iu=/4140/ostg.clktrk
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev