quantlib-dev — Discussion of QuantLib development

[Quantlib-dev] QuantlibAddin duplicate project files

[Francois B. <ig...@gm...>]

Hi,

Why all the "duplicate" project files in the QuantLibAddin directory. For
example:

QuantLibObjects_vc10.vcxproj
QuantLibObjects2_vc10.vcxproj
QuantLibObjects3_vc10.vcxproj
QuantLibObjects4_vc10.vcxproj

regards
Francois Botha

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

[Alexander S. <so...@co...>]

Hi Luigi, Ferdinando, Peter:

Thank you for the feedback! Answering a few of the recent comments in no
particular order.

1) We concluded that the only way to both avoid making breaking changes to
QuantLib and avoid creating a custom fork of CppAD/ADOL-C, is to introduce a
class for Real and place AD<double> inside this class. Otherwise things like
implicit conversions from Null and InterestRate classes will not work
correctly and will require changes to one or the other, or can break
existing code due to ambiguous conversion.

2) On the other hand, with the class for Real, we can have a compile time
define to use CppAD, ADOL-C, as well as regular double (for validation of
conversion to the class) inside, and it will be very easy to add any future
AD library. We are using SFINAE for this, and the approach should be
relatively safe as far as unintended implicit conversions. I think this is
the best approach in long term. We checked that the wrapper gets fully
inlined and has zero impact on performance (this can be verified by looking
at assembly code), so there is really no downsize I can think of to
introducing it. If Real has to be a class for AD anyway, the best way to
proceed in my view is to create our own class, and then place various AD
implementations inside, rather than change the core QuantLib code to work
with various AD doubles.

3) Luigi, given that you are very busy these days, can you give me the list
of all officially supported compiler versions and are additional tests that
are not in test suite - we will then create a TeamCity installation that
will be running continuous builds to verify that our branch works and has no
regression. Incidentally, I would personally prefer to limit AD-based
version to C++11, or rather its subset implemented by MSVC 2013, gcc, and
clang. But if we have to support older compilers, we can try to get it work
with cpp98 as well.

4) I will shortly send a pull request to Luigi for two branches - one based
on master-adjoint-ready (please take a look if you have a moment, it is
almost done and already pushed to
github.com/compatibl/master-adjoint-ready), which I hope you will consider
pulling into your master. The changes on this branch have to do with mixing
double and Real or things like if(double), etc. - namely it is just
correcting something in core QuantLib that stops AD from working, but does
not have AD itself and keeps Real=double. These fixes should be very safe
but we will test them before the pull request is sent. The second branch
will have AD and I hope you can pull it into a separate branch in your repo
so more people can try it.

Best regards
Alex




--
View this message in context: http://quantlib.10058.n7.nabble.com/Adjoint-Greeks-tp16147p16302.html
Sent from the quantlib-dev mailing list archive at Nabble.com.

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>

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

[Ferdinando M. A. <fer...@am...>]

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
>

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

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

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

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

[Alexander S. <so...@co...>]

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.

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

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

Hi Alex,

yes. I have other scenarios in mind. Like you have a demanding model
calibration, say for a LFM just to name an example. You want to do
this without AD of course. Then you have your actual exotic pricing
with a Monte Carlo engine, where you want AD enabled to compute the
deltas.

Here you seem to need both calculations variants within one
application and even have to transport the calibrated model from one
to the other somehow.

Thanks
Peter


On 3 March 2015 at 09:02, Alexander Sokol <so...@co...> wrote:
> Hi Peter:
>
> My impression currently is that keeping track of AD vs. non-AD variables
> manually and designing the code to compile with two different types of
> variables in different classes is going to be very cumbersome, and not
> necessarily effective in terms of performance. By the time we get to the
> slow part of the calculation such as lattice and Monte Carlo, the variables
> in the time slice will all have to be AD variables. If this is the case,
> then getting typedef to QlDouble, which in turn contains AD<double> as a
> data member, is the easiest and fastest way to get the entire library
> supporting AD. In fact, the conversion is already done and we are about to
> release the code on GitHub - currently testing and resolving the remaining
> issues with conversion of InterestRate to Real.
>
> I also think the work only just begins, because using AD effectively with
> Monte Carlo and other numerical techniques will require considerable amount
> of additional engineering - so we are still far from having an effective AD
> implementation for e.g. XVA or other numerical calculations where additional
> speed is most important. The version of the code with typedef only gets us
> to the starting line for that effort.
>
> Alex
>
>
>
>
> --
> View this message in context: http://quantlib.10058.n7.nabble.com/Adjoint-Greeks-tp16147p16296.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

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

[Alexander S. <so...@co...>]

Hi Peter:

My impression currently is that keeping track of AD vs. non-AD variables
manually and designing the code to compile with two different types of
variables in different classes is going to be very cumbersome, and not
necessarily effective in terms of performance. By the time we get to the
slow part of the calculation such as lattice and Monte Carlo, the variables
in the time slice will all have to be AD variables. If this is the case,
then getting typedef to QlDouble, which in turn contains AD<double> as a
data member, is the easiest and fastest way to get the entire library
supporting AD. In fact, the conversion is already done and we are about to
release the code on GitHub - currently testing and resolving the remaining
issues with conversion of InterestRate to Real.

I also think the work only just begins, because using AD effectively with
Monte Carlo and other numerical techniques will require considerable amount
of additional engineering - so we are still far from having an effective AD
implementation for e.g. XVA or other numerical calculations where additional
speed is most important. The version of the code with typedef only gets us
to the starting line for that effort.

Alex




--
View this message in context: http://quantlib.10058.n7.nabble.com/Adjoint-Greeks-tp16147p16296.html
Sent from the quantlib-dev mailing list archive at Nabble.com.

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

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

Alex,

sure it is nice not to have to touch the code. I was just wondering if
this is the only reason to follow this path or if there are other
advantages ?

Thanks
Peter



On 2 March 2015 at 21:18, Alexander Sokol <so...@co...> wrote:
> Hi Peter:
>
> I am not yet ready to comment on the performance implications, but not
> becuase the initial test results are not clear - it is just that the
> bottleneck may not be as dependent to the overhead of "unused" adjoint
> variable. For example, if the bottleneck is in Monte Carlo, and by the time
> we get to Monte Carlo claculations every value in time slices is an AD
> variable, then there is no additional overhead at all and performance
> optimizations may turn out to be completely different from isolating non-AD
> variables from AD variables.
>
> On the other hand, the benefits of not touching much of the code are quite
> significant for continuity and avoiding a disruption to the codebase. So far
> I collected these changes in my master-adjoint-ready branch in
> github.com/compatibl/quantlib. They are faily minimal and I am planning to
> send Luigi a pull request shortly. Also, we confirmed that using a class for
> Real where inside is a regular double has no measurable performance impact
> at all because it is fully inlined. If we use our own class for Real, and
> inside that class place AD<double> or adouble, then the AD framework does
> not need to be patched at all.
>
> Best regards
> Alex
>
>
>
>
>
> --
> View this message in context: http://quantlib.10058.n7.nabble.com/Adjoint-Greeks-tp16147p16294.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

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

[Alexander S. <so...@co...>]

Hi Peter:

I am not yet ready to comment on the performance implications, but not
becuase the initial test results are not clear - it is just that the
bottleneck may not be as dependent to the overhead of "unused" adjoint
variable. For example, if the bottleneck is in Monte Carlo, and by the time
we get to Monte Carlo claculations every value in time slices is an AD
variable, then there is no additional overhead at all and performance
optimizations may turn out to be completely different from isolating non-AD
variables from AD variables.

On the other hand, the benefits of not touching much of the code are quite
significant for continuity and avoiding a disruption to the codebase. So far
I collected these changes in my master-adjoint-ready branch in
github.com/compatibl/quantlib. They are faily minimal and I am planning to
send Luigi a pull request shortly. Also, we confirmed that using a class for
Real where inside is a regular double has no measurable performance impact
at all because it is fully inlined. If we use our own class for Real, and
inside that class place AD<double> or adouble, then the AD framework does
not need to be patched at all.

Best regards
Alex





--
View this message in context: http://quantlib.10058.n7.nabble.com/Adjoint-Greeks-tp16147p16294.html
Sent from the quantlib-dev mailing list archive at Nabble.com.

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

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

[Alexander S. <so...@co...>]

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.

[Quantlib-dev] 答复: Adjoint Greeks

[Cheng L. <scr...@gm...>]

Hi Alex，

I have checked out your master branch and I found that there are 2 more
folders named QuantLibFramework and QuantLibResults respectively. Can I know
what are they used for?

Regards,
Cheng

-----邮件原件-----
发件人: Alexander Sokol [mailto:so...@co...] 
发送时间: 2015年2月10日 1:15
收件人: qua...@li...
主题: Re: [Quantlib-dev] Adjoint Greeks

Peter, Luigi, Ferdinando:

I am a bit late joining this discussion. I believe the approach of choosing
AD vs. non-AD mode globally at compile time that you have discussed in the
two messages quoted below may on the balance be the best choice for a large
scale C++ library such as QuantLib. If we try to templatize nearly every
class, in addition to the obscure compiler warning problems noted by Peter
we will also see a major impact on compilation time, because a lot of the
code will recompile the moment we touch any class. Also, as everyone noted
earlier, this is not possible to do without a major overhaul of the entire
code (turning a lot of .cpp files to .hpp headers and touching a lot of
lines of code).

Also, if the ultimate goal is to be able to select which type is using
AD<double> and which type uses double, it may turn out that in the end the
only two settings that will compile will be all-AD or no-AD settings, and
the intermediate combinations will be hard to make compile and work.

On the other hand, if we simply typedef Real to AD<double> (for CppAD) or
adouble (for ADOL-C), and also ensure that a variable which has no tape
pointer in it simply uses the internal double, then C++ inlining will likely
reduce any performance impact. The advantage, as noted earlier in this
thread, is that this can be done with minimal changes to the code base and
hopefully can then be pulled into the master branch under a compile time
define.

Thanks to the great wisdom in using Real from the very beginning, this
worked well without massive code changes.
When I did the replacement and hit compile, it was about
150,000 line of C++ compiler errors (some lines of code were generating many
lines of errors). After some tweaking which I committed to GitHub step by
step, we are down to about 1000 errors and I do not see any major
showstoppers in completing the conversion in a short period of time.

For now I defined all variables as AD<double> except Time, but changed
durations from Time to Real. I am currently trying to see if we should bite
the bullet and use Real for Time as well, so we only have one type of double
within the system.

My code is in the following repos (expect rapid changes):

Fork of Luigi's master, branch master-adjoint with changes:
    https://github.com/compatibl/quantlib/commits/master-adjoint

Dependencies including a customized version of CppAD:
    https://github.com/compatibl/quantlib-dependencies

To compile in adjoint mode, define QL_AD and put dependencies\cpp in the
include path.

Note that I had to make a minor change to CppAD.
This change to CppAD is in dependencies, so only this version of CppAD wil
work for now.

If I do not manage to find a workaround will ask Brad Bell to pull my
modification under a compile time define. It has to do with a constructor of
AD<double> from another type with cast to double, which superseded the
conversion we needed for InterestRate to AD<double>. See commit log for
details.

I will keep posting to this thread as we progress on this.

Please let me know any comments, and please contact me if you wish to
contribute to further development of this alternative approach, or use this
repo. After the code compiles and runs, only then the real work will begin
because the code will require considerable amount of AD-specific
optimizations to outperform the brute force approach. But I am optimistic
that it can be done with QuantLib.

Best regards
Alexander Sokol
CompatibL

> On Sun, Jan 11, 2015 at 7:16am, Luigi Ballabio wrote:
>
> Hi Peter,
>      you definitely need both double and CppAD<double>. I was 
> wondering if you needed a given engine if both adjoint and not-adjoint 
> implementation.
> If not, you might choose at compile time. Otherwise, we'd have to bite 
> the bullet and templatize lots of stuff, as you're doing already.
> 
> Luigi
> 
> On Thu, Jan 8, 2015 at 8:56 PM, Peter Caspers wrote:
> 
> I thought in a realistic application you would always need both 
> worlds, CppAD<double> for adjoint greek engines and double for all the 
> rest. I wonder what it would mean in terms of performance and memory 
> if you replace double by CppAD<double> in general. I can maybe just 
> stress test this a bit though.
> Peter



--
View this message in context:
http://quantlib.10058.n7.nabble.com/Adjoint-Greeks-tp16147p16251.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

Re: [Quantlib-dev] Coding cryptocurrencies

[Joseph W. <joe...@gm...>]

OK.  I'll hold off on using commodities.

Also, have you looked at the intraday patches?  I'd like to get those
merged into the mainline since my bitcoin stuff depends on those.

Re: [Quantlib-dev] Coding cryptocurrencies

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

Hi Joseph,
    I'm not sure about the asset class. The whole commodity folder has been
kind of an abandoned project. I wouldn't tie currencies to it before giving
it a good, hard look.

The lack of fractional items shouldn't be a problem (there are also fiat
currencies that don't have them). I'm not sure about the numeric code. You
might try returning a null and see if this breaks anything.

Later,
    Luigi


On Mon, Feb 16, 2015 at 8:11 AM, Joseph Wang <joe...@gm...> wrote:

> I've starting doing some quant work on coding cryptocurrency
> derivative code.  One question that I have is the way of representing
> bitcoin.  There is infrastructure for representing currencies, but
> while cryptocurrencies have codes associated with them, they don't
> have fractional items or ISO numbers.
>
> I was wondering if it would be worth refactoring the CommodityType and
> Currency classes into subclasses of an AssetType class.
>
>
> ------------------------------------------------------------------------------
> 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
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>



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

Re: [Quantlib-dev] discount margin

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

I gave the beginning of an answer when the same question was asked at <
http://quant.stackexchange.com/questions/8965/setting-up-schedule-for-an-amortizing-floater-in-quantlib>,
but there's no working code there. You can check if the methodology is
sound, though (I'm not sure of that myself).

Luigi


On Thu, Feb 19, 2015 at 5:12 PM, Ferdinando M. Ametrano <
fer...@am...> wrote:

> Hello
>
> has anyone ever implemented floating bond discount margin evaluation in QL
> C++.
>
> I need to tackle this, but would love to leverage my laziness :-)
>
> thx
> F
>
>
> ------------------------------------------------------------------------------
> 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
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>
>


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

Re: [Quantlib-dev] QuantLib 1.5 compilation errors

[Theo B. <tb...@ao...>]

Hi Luigi,


Many thanks for your response, I tried boost 1_55 and it works.


Many thanks.


Regards


Theo




  
  
 

Re: [Quantlib-dev] QuantLib 1.5 compilation errors

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

It seems that it's a problem specific to Boost 1.51: see <
https://svn.boost.org/trac/boost/ticket/7437>.  You can use any other
version.

Luigi


On Thu, Feb 19, 2015 at 5:19 PM, Theo Boafo <tb...@ao...> wrote:

> Hi All,
>
>  I downloaded Quantlib 1.5 and tried compiling it under Quantlib_vc10 and
> get the errors below.  It seems the version of boost I have 1_51 is not
> compatible.  1_51 was okay for Quantlib 1.4.
>
>  Please, What version of boost should i be using.
>
>  Regards
>
>  Theo
>
>
> c:\program
> files\boost\boost_1_51\boost\functional\hash\extensions.hpp(257): error
> C2665: 'boost::hash_value' : none of the 2 overloads could convert all the
> argument types
> 1>          c:\program
> files\boost\boost_1_51\boost\functional\hash\hash.hpp(115): could be
> 'size_t boost::hash_value(std::type_index)'
> 1>          c:\program
> files\boost\boost_1_51\boost\functional\hash\extensions.hpp(160): or
> 'size_t boost::hash_value(const std::tr1::tuple<> &)'
> 1>          while trying to match the argument list '(const
> QuantLib::TimeUnit)'
> 1>          c:\program
> files\boost\boost_1_51\boost\functional\hash\extensions.hpp(256) : while
> compiling class template member function 'size_t boost::hash<T>::operator
> ()(const T &) const'
> 1>          with
> 1>          [
> 1>              T=QuantLib::TimeUnit
> 1>          ]
> 1>          c:\program
> files\boost\boost_1_51\boost\functional\hash\hash.hpp(219) : see reference
> to class template instantiation 'boost::hash<T>' being compiled
> 1>          with
> 1>          [
> 1>              T=QuantLib::TimeUnit
> 1>          ]
> 1>
>  c:\users\catherinechristopher\documents\quants\quants\quantlib-1.5\ql\experimental\models\gaussian1dmodel.hpp(183)
> : see reference to function template instantiation 'void
> boost::hash_combine<QuantLib::TimeUnit>(size_t &,const T &)' being compiled
> 1>          with
> 1>          [
> 1>              T=QuantLib::TimeUnit
> 1>          ]
> 1>  gaussian1dfloatfloatswaptionengine.cpp
> 1>c:\program
> files\boost\boost_1_51\boost\functional\hash\extensions.hpp(257): error
> C2665: 'boost::hash_value' : none of the 2 overloads could convert all the
> argument types
> 1>          c:\program
> files\boost\boost_1_51\boost\functional\hash\hash.hpp(115): could be
> 'size_t boost::hash_value(std::type_index)'
> 1>          c:\program
> files\boost\boost_1_51\boost\functional\hash\extensions.hpp(160): or
> 'size_t boost::hash_value(const std::tr1::tuple<> &)'
> 1>          while trying to match the argument list '(const
> QuantLib::TimeUnit)'
> 1>          c:\program
> files\boost\boost_1_51\boost\functional\hash\extensions.hpp(256) : while
> compiling class template member function 'size_t boost::hash<T>::operator
> ()(const T &) const'
> 1>          with
> 1>          [
> 1>              T=QuantLib::TimeUnit
> 1>          ]
> 1>          c:\program
> files\boost\boost_1_51\boost\functional\hash\hash.hpp(219) : see reference
> to class template instantiation 'boost::hash<T>' being compiled
> 1>          with
> 1>          [
> 1>              T=QuantLib::TimeUnit
> 1>          ]
> 1>
>  c:\users\catherinechristopher\documents\quants\quants\quantlib-1.5\ql\experimental\models\gaussian1dmodel.hpp(183)
> : see reference to function template instantiation 'void
> boost::hash_combine<QuantLib::TimeUnit>(size_t &,const T &)' being compiled
> 1>          with
> 1>          [
> 1>              T=QuantLib::TimeUnit
> 1>          ]
> 1>  gaussian1djamshidianswaptionengine.cpp
> 1>c:\program
> files\boost\boost_1_51\boost\functional\hash\extensions.hpp(257): error
> C2665: 'boost::hash_value' : none of the 2 overloads could convert all the
> argument types
> 1>          c:\program
> files\boost\boost_1_51\boost\functional\hash\hash.hpp(115): could be
> 'size_t boost::hash_value(std::type_index)'
> 1>          c:\program
> files\boost\boost_1_51\boost\functional\hash\extensions.hpp(160): or
> 'size_t boost::hash_value(const std::tr1::tuple<> &)'
> 1>          while trying to match the argument list '(const
> QuantLib::TimeUnit)'
> 1>          c:\program
> files\boost\boost_1_51\boost\functional\hash\extensions.hpp(256) : while
> compiling class template member function 'size_t boost::hash<T>::operator
> ()(const T &) const'
> 1>          with
> 1>          [
> 1>              T=QuantLib::TimeUnit
> 1>          ]
> 1>          c:\program
> files\boost\boost_1_51\boost\functional\hash\hash.hpp(219) : see reference
> to class template instantiation 'boost::hash<T>' being compiled
> 1>          with
> 1>          [
> 1>              T=QuantLib::TimeUnit
> 1>          ]
> 1>
>  c:\users\catherinechristopher\documents\quants\quants\quantlib-1.5\ql\experimental\models\gaussian1dmodel.hpp(183)
> : see reference to function template instantiation 'void
> boost::hash_combine<QuantLib::TimeUnit>(size_t &,const T &)' being compiled
> 1>          with
> 1>          [
> 1>              T=QuantLib::TimeUnit
> 1>          ]
> 1>  gaussian1dnonstandardswaptionengine.cpp
> 1>c:\program
> files\boost\boost_1_51\boost\functional\hash\extensions.hpp(257): error
> C2665: 'boost::hash_value' : none of the 2 overloads could convert all the
> argument types
> 1>          c:\program
> files\boost\boost_1_51\boost\functional\hash\hash.hpp(115): could be
> 'size_t boost::hash_value(std::type_index)'
> 1>          c:\program
> files\boost\boost_1_51\boost\functional\hash\extensions.hpp(160): or
> 'size_t boost::hash_value(const std::tr1::tuple<> &)'
> 1>          while trying to match the argument list '(const
> QuantLib::TimeUnit)'
> 1>          c:\program
> files\boost\boost_1_51\boost\functional\hash\extensions.hpp(256) : while
> compiling class template member function 'size_t boost::hash<T>::operator
> ()(const T &) const'
> 1>          with
> 1>          [
> 1>              T=QuantLib::TimeUnit
> 1>          ]
> 1>          c:\program
> files\boost\boost_1_51\boost\functional\hash\hash.hpp(219) : see reference
> to class template instantiation 'boost::hash<T>' being compiled
> 1>          with
> 1>          [
> 1>              T=QuantLib::TimeUnit
> 1>          ]
> 1>
>  c:\users\catherinechristopher\documents\quants\quants\quantlib-1.5\ql\experimental\models\gaussian1dmodel.hpp(183)
> : see reference to function template instantiation 'void
> boost::hash_combine<QuantLib::TimeUnit>(size_t &,const T &)' being compiled
> 1>          with
> 1>          [
> 1>              T=QuantLib::TimeUnit
> 1>          ]
> 1>  gaussian1dswaptionengine.cpp
> 1>c:\program
> files\boost\boost_1_51\boost\functional\hash\extensions.hpp(257): error
> C2665: 'boost::hash_value' : none of the 2 overloads could convert all the
> argument types
> 1>          c:\program
> files\boost\boost_1_51\boost\functional\hash\hash.hpp(115): could be
> 'size_t boost::hash_value(std::type_index)'
> 1>          c:\program
> files\boost\boost_1_51\boost\functional\hash\extensions.hpp(160): or
> 'size_t boost::hash_value(const std::tr1::tuple<> &)'
> 1>          while trying to match the argument list '(const
> QuantLib::TimeUnit)'
> 1>          c:\program
> files\boost\boost_1_51\boost\functional\hash\extensions.hpp(256) : while
> compiling class template member function 'size_t boost::hash<T>::operator
> ()(const T &) const'
> 1>          with
> 1>          [
> 1>              T=QuantLib::TimeUnit
> 1>          ]
> 1>          c:\program
> files\boost\boost_1_51\boost\functional\hash\hash.hpp(219) : see reference
> to class template instantiation 'boost::hash<T>' being compiled
> 1>          with
> 1>          [
> 1>              T=QuantLib::TimeUnit
> 1>          ]
> 1>
>  c:\users\catherinechristopher\documents\quants\quants\quantlib-1.5\ql\experimental\models\gaussian1dmodel.hpp(183)
> : see reference to function template instantiation 'void
> boost::hash_combine<QuantLib::TimeUnit>(size_t &,const T &)' being compiled
> 1>          with
> 1>          [
> 1>              T=QuantLib::TimeUnit
> 1>          ]
> 1>  gsr.cpp
> 1>c:\program
> files\boost\boost_1_51\boost\functional\hash\extensions.hpp(257): error
> C2665: 'boost::hash_value' : none of the 2 overloads could convert all the
> argument types
> 1>          c:\program
> files\boost\boost_1_51\boost\functional\hash\hash.hpp(115): could be
> 'size_t boost::hash_value(std::type_index)'
> 1>          c:\program
> files\boost\boost_1_51\boost\functional\hash\extensions.hpp(160): or
> 'size_t boost::hash_value(const std::tr1::tuple<> &)'
> 1>          while trying to match the argument list '(const
> QuantLib::TimeUnit)'
> 1>          c:\program
> files\boost\boost_1_51\boost\functional\hash\extensions.hpp(256) : while
> compiling class template member function 'size_t boost::hash<T>::operator
> ()(const T &) const'
> 1>          with
> 1>          [
> 1>              T=QuantLib::TimeUnit
> 1>          ]
> 1>          c:\program
> files\boost\boost_1_51\boost\functional\hash\hash.hpp(219) : see reference
> to class template instantiation 'boost::hash<T>' being compiled
> 1>          with
> 1>          [
> 1>              T=QuantLib::TimeUnit
> 1>          ]
> 1>
>  c:\users\catherinechristopher\documents\quants\quants\quantlib-1.5\ql\experimental\models\gaussian1dmodel.hpp(183)
> : see reference to function template instantiation 'void
> boost::hash_combine<QuantLib::TimeUnit>(size_t &,const T &)' being compiled
> 1>          with
> 1>          [
> 1>              T=QuantLib::TimeUnit
> 1>          ]
> 1>  gsrprocess.cpp
> 1>c:\program
> files\boost\boost_1_51\boost\functional\hash\extensions.hpp(257): error
> C2665: 'boost::hash_value' : none of the 2 overloads could convert all the
> argument types
> 1>          c:\program
> files\boost\boost_1_51\boost\functional\hash\hash.hpp(115): could be
> 'size_t boost::hash_value(std::type_index)'
> 1>          c:\program
> files\boost\boost_1_51\boost\functional\hash\extensions.hpp(160): or
> 'size_t boost::hash_value(const std::tr1::tuple<> &)'
> 1>          while trying to match the argument list '(const
> QuantLib::TimeUnit)'
> 1>          c:\program
> files\boost\boost_1_51\boost\functional\hash\extensions.hpp(256) : while
> compiling class template member function 'size_t boost::hash<T>::operator
> ()(const T &) const'
> 1>          with
> 1>          [
> 1>              T=QuantLib::TimeUnit
> 1>          ]
> 1>          c:\program
> files\boost\boost_1_51\boost\functional\hash\hash.hpp(219) : see reference
> to class template instantiation 'boost::hash<T>' being compiled
> 1>          with
> 1>          [
> 1>              T=QuantLib::TimeUnit
> 1>          ]
> 1>
>  c:\users\catherinechristopher\documents\quants\quants\quantlib-1.5\ql\experimental\models\gaussian1dmodel.hpp(183)
> : see reference to function template instantiation 'void
> boost::hash_combine<QuantLib::TimeUnit>(size_t &,const T &)' being compiled
> 1>          with
> 1>          [
> 1>              T=QuantLib::TimeUnit
> 1>          ]
> 1>  kahalesmilesection.cpp
> 1>c:\program
> files\boost\boost_1_51\boost\functional\hash\extensions.hpp(257): error
> C2665: 'boost::hash_value' : none of the 2 overloads could convert all the
> argument types
> 1>          c:\program
> files\boost\boost_1_51\boost\functional\hash\hash.hpp(115): could be
> 'size_t boost::hash_value(std::type_index)'
> 1>          c:\program
> files\boost\boost_1_51\boost\functional\hash\extensions.hpp(160): or
> 'size_t boost::hash_value(const std::tr1::tuple<> &)'
> 1>          while trying to match the argument list '(const
> QuantLib::TimeUnit)'
> 1>          c:\program
> files\boost\boost_1_51\boost\functional\hash\extensions.hpp(256) : while
> compiling class template member function 'size_t boost::hash<T>::operator
> ()(const T &) const'
> 1>          with
> 1>          [
> 1>              T=QuantLib::TimeUnit
> 1>          ]
> 1>          c:\program
> files\boost\boost_1_51\boost\functional\hash\hash.hpp(219) : see reference
> to class template instantiation 'boost::hash<T>' being compiled
> 1>          with
> 1>          [
> 1>              T=QuantLib::TimeUnit
> 1>          ]
> 1>
>  c:\users\catherinechristopher\documents\quants\quants\quantlib-1.5\ql\experimental\models\gaussian1dmodel.hpp(183)
> : see reference to function template instantiation 'void
> boost::hash_combine<QuantLib::TimeUnit>(size_t &,const T &)' being compiled
> 1>          with
> 1>          [
> 1>              T=QuantLib::TimeUnit
> 1>          ]
> 1>  markovfunctional.cpp
> 1>  mfstateprocess.cpp
> 1>c:\program
> files\boost\boost_1_51\boost\functional\hash\extensions.hpp(257): error
> C2665: 'boost::hash_value' : none of the 2 overloads could convert all the
> argument types
> 1>          c:\program
> files\boost\boost_1_51\boost\functional\hash\hash.hpp(115): could be
> 'size_t boost::hash_value(std::type_index)'
> 1>          c:\program
> files\boost\boost_1_51\boost\functional\hash\extensions.hpp(160): or
> 'size_t boost::hash_value(const std::tr1::tuple<> &)'
> 1>          while trying to match the argument list '(const
> QuantLib::TimeUnit)'
> 1>          c:\program
> files\boost\boost_1_51\boost\functional\hash\extensions.hpp(256) : while
> compiling class template member function 'size_t boost::hash<T>::operator
> ()(const T &) const'
> 1>          with
> 1>          [
> 1>              T=QuantLib::TimeUnit
> 1>          ]
> 1>          c:\program
> files\boost\boost_1_51\boost\functional\hash\hash.hpp(219) : see reference
> to class template instantiation 'boost::hash<T>' being compiled
> 1>          with
> 1>          [
> 1>              T=QuantLib::TimeUnit
> 1>          ]
> 1>
>  c:\users\catherinechristopher\documents\quants\quants\quantlib-1.5\ql\experimental\models\gaussian1dmodel.hpp(183)
> : see reference to function template instantiation 'void
> boost::hash_combine<QuantLib::TimeUnit>(size_t &,const T &)' being compiled
> 1>          with
> 1>          [
> 1>              T=QuantLib::TimeUnit
> 1>          ]
> 1>  nonstandardswap.cpp
> 1>  nonstandardswaption.cpp
> 1>  smilesectionutils.cpp
> 1>  extendedblackscholesprocess.cpp
> 1>c:\program
> files\boost\boost_1_51\boost\functional\hash\extensions.hpp(257): error
> C2665: 'boost::hash_value' : none of the 2 overloads could convert all the
> argument types
> 1>          c:\program
> files\boost\boost_1_51\boost\functional\hash\hash.hpp(115): could be
> 'size_t boost::hash_value(std::type_index)'
> 1>          c:\program
> files\boost\boost_1_51\boost\functional\hash\extensions.hpp(160): or
> 'size_t boost::hash_value(const std::tr1::tuple<> &)'
> 1>          while trying to match the argument list '(const
> QuantLib::TimeUnit)'
> 1>          c:\program
> files\boost\boost_1_51\boost\functional\hash\extensions.hpp(256) : while
> compiling class template member function 'size_t boost::hash<T>::operator
> ()(const T &) const'
> 1>          with
> 1>          [
> 1>              T=QuantLib::TimeUnit
> 1>          ]
> 1>          c:\program
> files\boost\boost_1_51\boost\functional\hash\hash.hpp(219) : see reference
> to class template instantiation 'boost::hash<T>' being compiled
> 1>          with
> 1>          [
> 1>              T=QuantLib::TimeUnit
> 1>          ]
> 1>
>  c:\users\catherinechristopher\documents\quants\quants\quantlib-1.5\ql\experimental\models\gaussian1dmodel.hpp(183)
> : see reference to function template instantiation 'void
> boost::hash_combine<QuantLib::TimeUnit>(size_t &,const T &)' being compiled
> 1>          with
> 1>          [
> 1>              T=QuantLib::TimeUnit
> 1>          ]
> 1>  extendedornsteinuhlenbeckprocess.cpp
> 1>  vegastressedblackscholesprocess.cpp
> 1>c:\program
> files\boost\boost_1_51\boost\functional\hash\extensions.hpp(257): error
> C2665: 'boost::hash_value' : none of the 2 overloads could convert all the
> argument types
> 1>          c:\program
> files\boost\boost_1_51\boost\functional\hash\hash.hpp(115): could be
> 'size_t boost::hash_value(std::type_index)'
> 1>          c:\program
> files\boost\boost_1_51\boost\functional\hash\extensions.hpp(160): or
> 'size_t boost::hash_value(const std::tr1::tuple<> &)'
> 1>          while trying to match the argument list '(const
> QuantLib::TimeUnit)'
> 1>          c:\program
> files\boost\boost_1_51\boost\functional\hash\extensions.hpp(256) : while
> compiling class template member function 'size_t boost::hash<T>::operator
> ()(const T &) const'
> 1>          with
> 1>          [
> 1>              T=QuantLib::TimeUnit
> 1>          ]
> 1>          c:\program
> files\boost\boost_1_51\boost\functional\hash\hash.hpp(219) : see reference
> to class template instantiation 'boost::hash<T>' being compiled
> 1>          with
> 1>          [
> 1>              T=QuantLib::TimeUnit
> 1>          ]
> 1>
>  c:\users\catherinechristopher\documents\quants\quants\quantlib-1.5\ql\experimental\models\gaussian1dmodel.hpp(183)
> : see reference to function template instantiation 'void
> boost::hash_combine<QuantLib::TimeUnit>(size_t &,const T &)' being compiled
> 1>          with
> 1>          [
> 1>              T=QuantLib::TimeUnit
> 1>          ]
>
>
>
>
> ------------------------------------------------------------------------------
> 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
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>
>


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

Re: [Quantlib-dev] Adjoint Greeks

[Alexander S. <so...@co...>]

Peter, Luigi:

Just a quick update on our status - as of today the entire QuantLib code
including the core library, test suite, and examples compiles without errors
with Real = AD<double>, and there are only 3 linking errors remaining. I
hope to commit the code which has no linking or compilation errors within
the next few days and will post GIT revisions then. The interim version is
in CompatibL's clone of quantlib repo,
https://github.com/compatibl/quantlib.

However this result was achieved by temporarily creating a large number of
stubs for methods taking AD<double>. The stubs are currently throwing
exceptions, and will need to be implemented one by one. The good news is
that we have been able to compile the entire source while making only
minimal changes, and I hope these changes are sufficiently limited and
localized for Luigi to accept them into the main master so we do not need to
maintain AD and non-AD version separately - it would be controlled by a
compile time define with the same source.

Regarding Luigi's idea with two libraries, this can certainly work if one
needs to apply AD only in some areas of the code but not others. We can make
"QuantLib" a compile time define, to be defined separately for each project.
This will avoid having to touch every file.

Best regards
Alex





--
View this message in context: http://quantlib.10058.n7.nabble.com/Adjoint-Greeks-tp16147p16276.html
Sent from the quantlib-dev mailing list archive at Nabble.com.

Re: [Quantlib-dev] Adjoint Greeks

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

Hi Luigi, Alex,

even with templates the AD and non-AD worlds would be rather
separated. I thought of converting constructors (just typing here, so
it might be nonsense)

template<class T> template<class S> Class_t<T>::Class_t(const
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
template approach for a
well defined subset of the library (like the vanilla rates part
including volatility structures and the Gsr and Markov models and the
bonds part contributed by
Cheng).

However, I also think that it would be quite a big thing to merge the
changes into the mainstream branch and that in total it may be wiser
to follow Alex's approach.
I will fork his branch on the weekend and see where I can help. So no
need to spend an extra day on generic programming during your next
course, Luigi ;-)

best regards
Peter


On 18 February 2015 at 15:30, Luigi Ballabio <lui...@gm...> wrote:
> 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>

[Quantlib-dev] discount margin

[Ferdinando M. A. <fer...@am...>]

Hello

has anyone ever implemented floating bond discount margin evaluation in QL
C++.

I need to tackle this, but would love to leverage my laziness :-)

thx
F

Re: [Quantlib-dev] QuantLib 1.5 compilation errors

[Theo B. <tb...@ao...>]

Hi All,


I downloaded Quantlib 1.5 and tried compiling it under Quantlib_vc10 and get the errors below.  It seems the version of boost I have 1_51 is not compatible.  1_51 was okay for Quantlib 1.4.


Please, What version of boost should i be using.


Regards


Theo




c:\program files\boost\boost_1_51\boost\functional\hash\extensions.hpp(257): error C2665: 'boost::hash_value' : none of the 2 overloads could convert all the argument types
1>          c:\program files\boost\boost_1_51\boost\functional\hash\hash.hpp(115): could be 'size_t boost::hash_value(std::type_index)'
1>          c:\program files\boost\boost_1_51\boost\functional\hash\extensions.hpp(160): or       'size_t boost::hash_value(const std::tr1::tuple<> &)'
1>          while trying to match the argument list '(const QuantLib::TimeUnit)'
1>          c:\program files\boost\boost_1_51\boost\functional\hash\extensions.hpp(256) : while compiling class template member function 'size_t boost::hash<T>::operator ()(const T &) const'
1>          with
1>          [
1>              T=QuantLib::TimeUnit
1>          ]
1>          c:\program files\boost\boost_1_51\boost\functional\hash\hash.hpp(219) : see reference to class template instantiation 'boost::hash<T>' being compiled
1>          with
1>          [
1>              T=QuantLib::TimeUnit
1>          ]
1>          c:\users\catherinechristopher\documents\quants\quants\quantlib-1.5\ql\experimental\models\gaussian1dmodel.hpp(183) : see reference to function template instantiation 'void boost::hash_combine<QuantLib::TimeUnit>(size_t &,const T &)' being compiled
1>          with
1>          [
1>              T=QuantLib::TimeUnit
1>          ]
1>  gaussian1dfloatfloatswaptionengine.cpp
1>c:\program files\boost\boost_1_51\boost\functional\hash\extensions.hpp(257): error C2665: 'boost::hash_value' : none of the 2 overloads could convert all the argument types
1>          c:\program files\boost\boost_1_51\boost\functional\hash\hash.hpp(115): could be 'size_t boost::hash_value(std::type_index)'
1>          c:\program files\boost\boost_1_51\boost\functional\hash\extensions.hpp(160): or       'size_t boost::hash_value(const std::tr1::tuple<> &)'
1>          while trying to match the argument list '(const QuantLib::TimeUnit)'
1>          c:\program files\boost\boost_1_51\boost\functional\hash\extensions.hpp(256) : while compiling class template member function 'size_t boost::hash<T>::operator ()(const T &) const'
1>          with
1>          [
1>              T=QuantLib::TimeUnit
1>          ]
1>          c:\program files\boost\boost_1_51\boost\functional\hash\hash.hpp(219) : see reference to class template instantiation 'boost::hash<T>' being compiled
1>          with
1>          [
1>              T=QuantLib::TimeUnit
1>          ]
1>          c:\users\catherinechristopher\documents\quants\quants\quantlib-1.5\ql\experimental\models\gaussian1dmodel.hpp(183) : see reference to function template instantiation 'void boost::hash_combine<QuantLib::TimeUnit>(size_t &,const T &)' being compiled
1>          with
1>          [
1>              T=QuantLib::TimeUnit
1>          ]
1>  gaussian1djamshidianswaptionengine.cpp
1>c:\program files\boost\boost_1_51\boost\functional\hash\extensions.hpp(257): error C2665: 'boost::hash_value' : none of the 2 overloads could convert all the argument types
1>          c:\program files\boost\boost_1_51\boost\functional\hash\hash.hpp(115): could be 'size_t boost::hash_value(std::type_index)'
1>          c:\program files\boost\boost_1_51\boost\functional\hash\extensions.hpp(160): or       'size_t boost::hash_value(const std::tr1::tuple<> &)'
1>          while trying to match the argument list '(const QuantLib::TimeUnit)'
1>          c:\program files\boost\boost_1_51\boost\functional\hash\extensions.hpp(256) : while compiling class template member function 'size_t boost::hash<T>::operator ()(const T &) const'
1>          with
1>          [
1>              T=QuantLib::TimeUnit
1>          ]
1>          c:\program files\boost\boost_1_51\boost\functional\hash\hash.hpp(219) : see reference to class template instantiation 'boost::hash<T>' being compiled
1>          with
1>          [
1>              T=QuantLib::TimeUnit
1>          ]
1>          c:\users\catherinechristopher\documents\quants\quants\quantlib-1.5\ql\experimental\models\gaussian1dmodel.hpp(183) : see reference to function template instantiation 'void boost::hash_combine<QuantLib::TimeUnit>(size_t &,const T &)' being compiled
1>          with
1>          [
1>              T=QuantLib::TimeUnit
1>          ]
1>  gaussian1dnonstandardswaptionengine.cpp
1>c:\program files\boost\boost_1_51\boost\functional\hash\extensions.hpp(257): error C2665: 'boost::hash_value' : none of the 2 overloads could convert all the argument types
1>          c:\program files\boost\boost_1_51\boost\functional\hash\hash.hpp(115): could be 'size_t boost::hash_value(std::type_index)'
1>          c:\program files\boost\boost_1_51\boost\functional\hash\extensions.hpp(160): or       'size_t boost::hash_value(const std::tr1::tuple<> &)'
1>          while trying to match the argument list '(const QuantLib::TimeUnit)'
1>          c:\program files\boost\boost_1_51\boost\functional\hash\extensions.hpp(256) : while compiling class template member function 'size_t boost::hash<T>::operator ()(const T &) const'
1>          with
1>          [
1>              T=QuantLib::TimeUnit
1>          ]
1>          c:\program files\boost\boost_1_51\boost\functional\hash\hash.hpp(219) : see reference to class template instantiation 'boost::hash<T>' being compiled
1>          with
1>          [
1>              T=QuantLib::TimeUnit
1>          ]
1>          c:\users\catherinechristopher\documents\quants\quants\quantlib-1.5\ql\experimental\models\gaussian1dmodel.hpp(183) : see reference to function template instantiation 'void boost::hash_combine<QuantLib::TimeUnit>(size_t &,const T &)' being compiled
1>          with
1>          [
1>              T=QuantLib::TimeUnit
1>          ]
1>  gaussian1dswaptionengine.cpp
1>c:\program files\boost\boost_1_51\boost\functional\hash\extensions.hpp(257): error C2665: 'boost::hash_value' : none of the 2 overloads could convert all the argument types
1>          c:\program files\boost\boost_1_51\boost\functional\hash\hash.hpp(115): could be 'size_t boost::hash_value(std::type_index)'
1>          c:\program files\boost\boost_1_51\boost\functional\hash\extensions.hpp(160): or       'size_t boost::hash_value(const std::tr1::tuple<> &)'
1>          while trying to match the argument list '(const QuantLib::TimeUnit)'
1>          c:\program files\boost\boost_1_51\boost\functional\hash\extensions.hpp(256) : while compiling class template member function 'size_t boost::hash<T>::operator ()(const T &) const'
1>          with
1>          [
1>              T=QuantLib::TimeUnit
1>          ]
1>          c:\program files\boost\boost_1_51\boost\functional\hash\hash.hpp(219) : see reference to class template instantiation 'boost::hash<T>' being compiled
1>          with
1>          [
1>              T=QuantLib::TimeUnit
1>          ]
1>          c:\users\catherinechristopher\documents\quants\quants\quantlib-1.5\ql\experimental\models\gaussian1dmodel.hpp(183) : see reference to function template instantiation 'void boost::hash_combine<QuantLib::TimeUnit>(size_t &,const T &)' being compiled
1>          with
1>          [
1>              T=QuantLib::TimeUnit
1>          ]
1>  gsr.cpp
1>c:\program files\boost\boost_1_51\boost\functional\hash\extensions.hpp(257): error C2665: 'boost::hash_value' : none of the 2 overloads could convert all the argument types
1>          c:\program files\boost\boost_1_51\boost\functional\hash\hash.hpp(115): could be 'size_t boost::hash_value(std::type_index)'
1>          c:\program files\boost\boost_1_51\boost\functional\hash\extensions.hpp(160): or       'size_t boost::hash_value(const std::tr1::tuple<> &)'
1>          while trying to match the argument list '(const QuantLib::TimeUnit)'
1>          c:\program files\boost\boost_1_51\boost\functional\hash\extensions.hpp(256) : while compiling class template member function 'size_t boost::hash<T>::operator ()(const T &) const'
1>          with
1>          [
1>              T=QuantLib::TimeUnit
1>          ]
1>          c:\program files\boost\boost_1_51\boost\functional\hash\hash.hpp(219) : see reference to class template instantiation 'boost::hash<T>' being compiled
1>          with
1>          [
1>              T=QuantLib::TimeUnit
1>          ]
1>          c:\users\catherinechristopher\documents\quants\quants\quantlib-1.5\ql\experimental\models\gaussian1dmodel.hpp(183) : see reference to function template instantiation 'void boost::hash_combine<QuantLib::TimeUnit>(size_t &,const T &)' being compiled
1>          with
1>          [
1>              T=QuantLib::TimeUnit
1>          ]
1>  gsrprocess.cpp
1>c:\program files\boost\boost_1_51\boost\functional\hash\extensions.hpp(257): error C2665: 'boost::hash_value' : none of the 2 overloads could convert all the argument types
1>          c:\program files\boost\boost_1_51\boost\functional\hash\hash.hpp(115): could be 'size_t boost::hash_value(std::type_index)'
1>          c:\program files\boost\boost_1_51\boost\functional\hash\extensions.hpp(160): or       'size_t boost::hash_value(const std::tr1::tuple<> &)'
1>          while trying to match the argument list '(const QuantLib::TimeUnit)'
1>          c:\program files\boost\boost_1_51\boost\functional\hash\extensions.hpp(256) : while compiling class template member function 'size_t boost::hash<T>::operator ()(const T &) const'
1>          with
1>          [
1>              T=QuantLib::TimeUnit
1>          ]
1>          c:\program files\boost\boost_1_51\boost\functional\hash\hash.hpp(219) : see reference to class template instantiation 'boost::hash<T>' being compiled
1>          with
1>          [
1>              T=QuantLib::TimeUnit
1>          ]
1>          c:\users\catherinechristopher\documents\quants\quants\quantlib-1.5\ql\experimental\models\gaussian1dmodel.hpp(183) : see reference to function template instantiation 'void boost::hash_combine<QuantLib::TimeUnit>(size_t &,const T &)' being compiled
1>          with
1>          [
1>              T=QuantLib::TimeUnit
1>          ]
1>  kahalesmilesection.cpp
1>c:\program files\boost\boost_1_51\boost\functional\hash\extensions.hpp(257): error C2665: 'boost::hash_value' : none of the 2 overloads could convert all the argument types
1>          c:\program files\boost\boost_1_51\boost\functional\hash\hash.hpp(115): could be 'size_t boost::hash_value(std::type_index)'
1>          c:\program files\boost\boost_1_51\boost\functional\hash\extensions.hpp(160): or       'size_t boost::hash_value(const std::tr1::tuple<> &)'
1>          while trying to match the argument list '(const QuantLib::TimeUnit)'
1>          c:\program files\boost\boost_1_51\boost\functional\hash\extensions.hpp(256) : while compiling class template member function 'size_t boost::hash<T>::operator ()(const T &) const'
1>          with
1>          [
1>              T=QuantLib::TimeUnit
1>          ]
1>          c:\program files\boost\boost_1_51\boost\functional\hash\hash.hpp(219) : see reference to class template instantiation 'boost::hash<T>' being compiled
1>          with
1>          [
1>              T=QuantLib::TimeUnit
1>          ]
1>          c:\users\catherinechristopher\documents\quants\quants\quantlib-1.5\ql\experimental\models\gaussian1dmodel.hpp(183) : see reference to function template instantiation 'void boost::hash_combine<QuantLib::TimeUnit>(size_t &,const T &)' being compiled
1>          with
1>          [
1>              T=QuantLib::TimeUnit
1>          ]
1>  markovfunctional.cpp
1>  mfstateprocess.cpp
1>c:\program files\boost\boost_1_51\boost\functional\hash\extensions.hpp(257): error C2665: 'boost::hash_value' : none of the 2 overloads could convert all the argument types
1>          c:\program files\boost\boost_1_51\boost\functional\hash\hash.hpp(115): could be 'size_t boost::hash_value(std::type_index)'
1>          c:\program files\boost\boost_1_51\boost\functional\hash\extensions.hpp(160): or       'size_t boost::hash_value(const std::tr1::tuple<> &)'
1>          while trying to match the argument list '(const QuantLib::TimeUnit)'
1>          c:\program files\boost\boost_1_51\boost\functional\hash\extensions.hpp(256) : while compiling class template member function 'size_t boost::hash<T>::operator ()(const T &) const'
1>          with
1>          [
1>              T=QuantLib::TimeUnit
1>          ]
1>          c:\program files\boost\boost_1_51\boost\functional\hash\hash.hpp(219) : see reference to class template instantiation 'boost::hash<T>' being compiled
1>          with
1>          [
1>              T=QuantLib::TimeUnit
1>          ]
1>          c:\users\catherinechristopher\documents\quants\quants\quantlib-1.5\ql\experimental\models\gaussian1dmodel.hpp(183) : see reference to function template instantiation 'void boost::hash_combine<QuantLib::TimeUnit>(size_t &,const T &)' being compiled
1>          with
1>          [
1>              T=QuantLib::TimeUnit
1>          ]
1>  nonstandardswap.cpp
1>  nonstandardswaption.cpp
1>  smilesectionutils.cpp
1>  extendedblackscholesprocess.cpp
1>c:\program files\boost\boost_1_51\boost\functional\hash\extensions.hpp(257): error C2665: 'boost::hash_value' : none of the 2 overloads could convert all the argument types
1>          c:\program files\boost\boost_1_51\boost\functional\hash\hash.hpp(115): could be 'size_t boost::hash_value(std::type_index)'
1>          c:\program files\boost\boost_1_51\boost\functional\hash\extensions.hpp(160): or       'size_t boost::hash_value(const std::tr1::tuple<> &)'
1>          while trying to match the argument list '(const QuantLib::TimeUnit)'
1>          c:\program files\boost\boost_1_51\boost\functional\hash\extensions.hpp(256) : while compiling class template member function 'size_t boost::hash<T>::operator ()(const T &) const'
1>          with
1>          [
1>              T=QuantLib::TimeUnit
1>          ]
1>          c:\program files\boost\boost_1_51\boost\functional\hash\hash.hpp(219) : see reference to class template instantiation 'boost::hash<T>' being compiled
1>          with
1>          [
1>              T=QuantLib::TimeUnit
1>          ]
1>          c:\users\catherinechristopher\documents\quants\quants\quantlib-1.5\ql\experimental\models\gaussian1dmodel.hpp(183) : see reference to function template instantiation 'void boost::hash_combine<QuantLib::TimeUnit>(size_t &,const T &)' being compiled
1>          with
1>          [
1>              T=QuantLib::TimeUnit
1>          ]
1>  extendedornsteinuhlenbeckprocess.cpp
1>  vegastressedblackscholesprocess.cpp
1>c:\program files\boost\boost_1_51\boost\functional\hash\extensions.hpp(257): error C2665: 'boost::hash_value' : none of the 2 overloads could convert all the argument types
1>          c:\program files\boost\boost_1_51\boost\functional\hash\hash.hpp(115): could be 'size_t boost::hash_value(std::type_index)'
1>          c:\program files\boost\boost_1_51\boost\functional\hash\extensions.hpp(160): or       'size_t boost::hash_value(const std::tr1::tuple<> &)'
1>          while trying to match the argument list '(const QuantLib::TimeUnit)'
1>          c:\program files\boost\boost_1_51\boost\functional\hash\extensions.hpp(256) : while compiling class template member function 'size_t boost::hash<T>::operator ()(const T &) const'
1>          with
1>          [
1>              T=QuantLib::TimeUnit
1>          ]
1>          c:\program files\boost\boost_1_51\boost\functional\hash\hash.hpp(219) : see reference to class template instantiation 'boost::hash<T>' being compiled
1>          with
1>          [
1>              T=QuantLib::TimeUnit
1>          ]
1>          c:\users\catherinechristopher\documents\quants\quants\quantlib-1.5\ql\experimental\models\gaussian1dmodel.hpp(183) : see reference to function template instantiation 'void boost::hash_combine<QuantLib::TimeUnit>(size_t &,const T &)' being compiled
1>          with
1>          [
1>              T=QuantLib::TimeUnit
1>          ]



 

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>

[Quantlib-dev] Coding cryptocurrencies

[Joseph W. <joe...@gm...>]

I've starting doing some quant work on coding cryptocurrency
derivative code.  One question that I have is the way of representing
bitcoin.  There is infrastructure for representing currencies, but
while cryptocurrencies have codes associated with them, they don't
have fractional items or ISO numbers.

I was wondering if it would be worth refactoring the CommodityType and
Currency classes into subclasses of an AssetType class.

Re: [Quantlib-dev] 答复: segmentation fault in boost ?

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

yes. It's not specific to the adjoint branch, but a more general
problem, actually I found this related post in the meantime

http://comments.gmane.org/gmane.comp.compilers.clang.devel/36032

so it seems to be a boost feature / bug.

best
Peter


On 11 February 2015 at 03:55, Cheng Li <scr...@gm...> wrote:
> Hi peter,
>
> Me too.
>
> If I compiled your adjoint branch with -O3 and then compiled your ad example
> with -O3 -std=c++11, the error raised up...(the same segmentation fault)
>
> However if I compiled ad example with only -std=c++11, then no error occurs.
>
> I don't know why...
>
> Regards,
> Cheng
>
> -----邮件原件-----
> 发件人: Peter Caspers [mailto:pca...@gm...]
> 发送时间: 2015年2月11日 3:58
> 收件人: QuantLib Mailing Lists
> 主题: [Quantlib-dev] segmentation fault in boost ?
>
> Hi,
>
> when compiling QL without -std=c++11, then an application (e.g. one of the
> examples) _with_ -std=c++11, I get the following weird error even before the
> first instruction in main was executed
>
> ==19902== Memcheck, a memory error detector ==19902== Copyright (C)
> 2002-2013, and GNU GPL'd, by Julian Seward et al.
> ==19902== Using Valgrind-3.11.0.SVN and LibVEX; rerun with -h for copyright
> info ==19902== Command: ./adjoint ==19902== ==19902== ==19902== Process
> terminating with default action of signal 11 (SIGSEGV) ==19902==  Bad
> permissions for mapped region at address 0x4DC608
> ==19902==    at 0x540F054: long double
> boost::math::lanczos::lanczos17m64::lanczos_sum<long double>(long double
> const&) (in
> /home/peter/quantlib/QuantLib/ql/.libs/libQuantLib.so.0.0.0)
> ==19902==    by 0x540F121:
> boost::math::lanczos::lanczos_initializer<boost::math::lanczos::lanczos17m64
> ,
> long double>::init::init() (lanczos.hpp:49)
> ==19902==    by 0x5257E26: __static_initialization_and_destruction_0
> (lanczos.hpp:64)
> ==19902==    by 0x5257E26: _GLOBAL__sub_I_gaussianlhplossmodel.cpp
> (gaussianlhplossmodel.cpp:202)
> ==19902==    by 0x400F855: call_init.part.0 (dl-init.c:84)
> ==19902==    by 0x400F90F: call_init (dl-init.c:55)
> ==19902==    by 0x400F90F: _dl_init (dl-init.c:133)
> ==19902==    by 0x4001669: ??? (in /lib/x86_64-linux-gnu/ld-2.17.so)
> ==19902==
> ==19902== HEAP SUMMARY:
> ==19902==     in use at exit: 4,316 bytes in 7 blocks
> ==19902==   total heap usage: 8 allocs, 1 frees, 37,132 bytes allocated
> ==19902==
> ==19902== LEAK SUMMARY:
> ==19902==    definitely lost: 0 bytes in 0 blocks
> ==19902==    indirectly lost: 0 bytes in 0 blocks
> ==19902==      possibly lost: 148 bytes in 2 blocks
> ==19902==    still reachable: 4,168 bytes in 5 blocks
> ==19902==         suppressed: 0 bytes in 0 blocks
> ==19902== Rerun with --leak-check=full to see details of leaked memory
> ==19902== ==19902== For counts of detected and suppressed errors, rerun
> with: -v ==19902== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0
> from 0)
>
> Anyone observed this too ? Drove me crazy until I realized the pattern. What
> is behind ? The other way around (QL with c++11, example
> without) works fine. Produced with gcc 4.9.1, boost 1.57.0 under Ubuntu.
>
> Thanks
> 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
>