Re: [Quantlib-dev] 答复: Adjoint Greeks

[Peter C. <pca...@gm...>]

Hi Alex, all,

more performance tests indicate that the slowdown factor 1.2 - 1.3
which I mentioned before (for AD<double> vs. double) is definitely the
best case. As soon as the compiler can do serious floating point
optimizations the factor gets higher. The highest value we saw so far
was for matrix multiplication, here it is 18 for large matrices.
Actual applications will lie somewhere in between probably, but it
seems likely that you will want both double and AD<double>
calculations mixed in your average ql application for that reason
alone.

So for the typedef-approach this means that you'd need to stitch two
QuantLib copies together as Luigi proposed. What about the Settings
class then, or the IndexManager and the like? Will there be a third
namespace QuantLibShared (you can avoid the third one by accessing one
of the two existing ones from the other, but the complexity introduced
remains the same imo). Also if AD becomes an everyday tool, who would
want to work with this kind of twin library in the long term if it can
be avoided?

I still think that patched AD frameworks would be very ugly. New
wrappers in ql as a remedy are better, but again increase complexity.

Correct me if I am wrong, but currently it seems that the only plus of
the typedef-approach is that the necessary changes can be kept rather
local. And the only minus of the template approach is that the whole
codebase needs to be converted. But the target picture is clear, it is
obvious what to do, it can be done in a reasonable amount of time and
the result would be rather flawless with very few (if any)
compromises. To put it differently, if this was the boost mailing
list, we wouldn't have this discussion, would we ;-) But yes, sure, I
also see the conflict if the primary goal is to conserve the current
code basis. So probably it boils down to this question in the end.

Best regards
Peter

On 2 March 2015 at 07:02, Alexander Sokol <so...@co...> wrote:
> Hi Cheng
>
> The Framework folder contains a data-driven interface around QuantLib we are
> wokring on, and the Results folder will have test results which will help
> establish that adjoint code works correctly. These are both in progress and
> are not yet ready for use.
>
> Regarding the conversion itself, we are already running with the entire
> library converted to use AD<double> instead of Real. However this required
> some changes in CppAD and so we did not release this code on GitHub, and
> instead tried to find a better way to approach the conversion.
>
> To address this problem, we took a slightly different approach - converted
> the code to use an internal inline class, which in turn contains AD<double>.
> This works with standard CppAD and will also work with other adjoint
> frameworks without further changes to QuantLib. The code is inlined, so
> there is no slowdown to speak of due to the introduction of this wrapper. I
> will publish the code shortly and post to this list, after which testing can
> commence!
>
> Best regards
> Alex
>
>
>
>
>
> --
> View this message in context: http://quantlib.10058.n7.nabble.com/Adjoint-Greeks-tp16147p16292.html
> Sent from the quantlib-dev mailing list archive at Nabble.com.
>
> ------------------------------------------------------------------------------
> 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