separated. I thought of converting constructors (just typing here, so
Class_t<S>& other) { /* ... */ }
for S (Real) convertible to T (CppAD::AD<Real>). I did not really
think it through though. Anyway, what I want to do is to finish the
I will fork his branch on the weekend and see where I can help. So no
> 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>
>
>
>
> --
> <
https://implementingquantlib.blogspot.com>
> <
https://twitter.com/lballabio>