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

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

Hi all,
    well, the only sure thing seems to be that my idea won't work :)
I agree with Peter, there's classes such as Settings that can't be
duplicated in two namespaces. Oh well.

As someone said already, I guess that for now you both might go ahead and
see where you get. I can put your work in two branches on my repo if you
think that people might feel more encouraged to try it out.

(Also, I think that getting people to try out your code is the priority
right now. I need feedback because I'm kind of between a rock and a hard
place here, not wanting to hinder your progress but also having to check
that nothing breaks, and that the barrier to adoption doesn't get too
high---for instance, I like Peter's approach a lot, but I'm kind of scared
to throw two pages of compilation errors at a user that makes a mistake...)

(On a more personal note: I also have the problem of keeping honest and
checking that I'm not just putting myself in the way of change because I'd
have to revise my course material and book. People, please call me out on
this if I don't realize I'm slipping.)

Going back to technical stuff:

- yes, the two approaches might overlay, but if Peter's approach is in
place, you lose the simplicity of Alex's approach anyway and the typedef
only sets the default.
- about the wrapper class: Alexander, I was under the impression that the
problems you were having could be solved just by specializing
Null<AD<Real>> and giving it an appropriate conversion operator as Peter
did. Did you have time to look at his code? If this work, you won't need
the wrapper (which might add conversion issues, inlined or not).
- in any case, I think the two approaches can both benefit from sharing
changes. The specialized Null is one case; Alex's MC engineering would be
another.

Ok, enough for now, I guess...

Later,
    Luigi



On Tue, Mar 3, 2015 at 11:14 AM, Ferdinando M. Ametrano <
fer...@am...> wrote:

> Hi Alex and Peter
>
> too bad in this period of my professional life I'm busy with other issues,
> as I would love to join you in this exciting endeavor (not sure you would
> appreciate, but that's another story... :-)
>
> I don't see your different approaches as conflicting: if Sokol's approach
> will not alter the QL codebase significantly, nothing is preventing
> Caspers' approach to be overlaid on the same QL codebase. To me this seems
> the best outcome: both alternatives being available to all users for
> experimenting, testing, and customizing solutions!
>
> In time we might settle on which would be the best practice for every
> different use case.
>
> just my $0.02 (or mBTC0.2)
>
> ciao -- Nando
>
>
> On Tue, Mar 3, 2015 at 10:12 AM, Peter Caspers <pca...@gm...>
> wrote:
>
>> Alex,
>>
>> I will try to get an example like this working, then we can compare.
>>
>> Best regards
>> Peter
>>
>> On 3 March 2015 at 09:43, Alexander Sokol <so...@co...> wrote:
>> > Hi Peter:
>> >
>> > I agree that in this scenario, having them separate is beneficial if
>> this
>> > can be accomplished in practice. Perhaps we need two separate branches,
>> one
>> > for each approach, with two groups working in parallel.
>> >
>> > For the moment, my team is focusing on the typedef approach and taking
>> the
>> > next step to making AD usable in practice with Monte Carlo.
>> >
>> > Best regards
>> > Alex
>> >
>> >
>> >
>> >
>> > --
>> > View this message in context:
>> http://quantlib.10058.n7.nabble.com/Adjoint-Greeks-tp16147p16298.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
>>
>>
>> ------------------------------------------------------------------------------
>> 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
>>
>
>
>
> ------------------------------------------------------------------------------
> 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>