Re: [Quantlib-dev] Adjoint Greeks

[Luigi B. <lui...@gm...>]

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 <so...@co...>
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:pca...@gm...]
> 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
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>



-- 
<https://implementingquantlib.blogspot.com>
<https://twitter.com/lballabio>