Adjoint Greeks

classic Classic list List threaded Threaded
44 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: 答复: Adjoint Greeks

Alexander Sokol
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
Reply | Threaded
Open this post in threaded view
|

Re: 答复: Adjoint Greeks

Peter Caspers-4
Hi,

just a few updates from my side.

My adjoint branch now supports the rate volatility structures and
experimental one factor models (and connected classes). I guess I will
change my mode of working on the branch to "on demand conversion",
either driven by my own requirements and use cases or also by anyone
interested in specific classes / parts of the library - since I have
some experience with the conversion process now and in order to keep
the "ql-template" codebase homogeneous and in one location I would be
happy to do the work. Pull requests are of course also still very
welcome. From time to time I will update the branch with the recent
changes from the mainstream version.

Some problems with CppAD / QuantLib / Boost came up in the past
months, or also wishes for new features like new functions to include.
Since CppAD's maintainer Brad Bell is quite open and fast to update
the project accordingly, in my opinion we should avoid own patches or
extensions to CppAD but rather try to stick with the official (yet
possibly very recent) CppAD releases. Currently there are two open
points:

atanh, asinh and acosh should be included => this is on the wishlist
https://github.com/coin-or/CppAD/commit/135165758d425f39aa9800f51a356723630165b1

#QL_NO_UBLAS_SUPPORT must be defined, otherwise Matrix_t<T>::inverse
does not compile for T=CppAD::AD<Base> => this seems to be a bug in
CppAD
https://github.com/coin-or/CppAD/blob/master/bug/boost_lu.sh

@Alex, did you work around the last point somehow ?

Thanks
Peter



On 3 March 2015 at 13:18, Alexander Sokol <[hidden email]> wrote:

> 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.
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for all
> things parallel software development, from weekly thought leadership blogs to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> QuantLib-dev mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev

------------------------------------------------------------------------------
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev
Reply | Threaded
Open this post in threaded view
|

Re: 答复: Adjoint Greeks

Alexander Sokol
Hi Peter:

We were able to solve the errors such as the one you mentioned in your post by operator overloading in boost namespace. The code sample is below in this email.

Best regards
Alex

Sample error message:

1>c:\projects\quantlib\dependencies\cpp\boost\numeric\ublas\detail\matrix_assign.hpp(34): error C2678: binary '<' : no operator found which takes a left-hand operand of type 'boost::numeric::ublas::matrix_scalar_unary<E,F>' (or there is no acceptable conversion)

Code snippet which fixes this error:

#include <cppad/cppad.hpp>

namespace boost {
       namespace numeric {
              namespace ublas
              {
                     template<class M>
                     class sparse_matrix_element;

                     template<class T, class L, std::size_t IB, class IA, class TA>
                     class compressed_matrix;

                     template<class T, class ALLOC>
                     class unbounded_array;

                     namespace detail {

                           template <typename Left, typename Right>
                           inline bool operator < (Left const& left, CppAD::AD<Right> const& right)
                           {

#pragma message ("overload operator < : " __FUNCSIG__)
                                  // This is only for demonstrate
                                  // Ensure that adjoint logic will workable
                                  return left < CppAD::Value(right);
                           }
                     }
              }
       }
}

#include <boost/numeric/ublas/lu.hpp>
using namespace std;


int main() {
    typedef CppAD::AD<double> T;
    boost::numeric::ublas::matrix<T> a(5, 5);
    boost::numeric::ublas::permutation_matrix<std::size_t> pert(5);
    // lu decomposition
    const std::size_t s = lu_factorize(a, pert);

    return 0;
}
Reply | Threaded
Open this post in threaded view
|

Re: 答复: Adjoint Greeks

Peter Caspers-4
Thanks Alex, great.
Peter

On 15 April 2015 at 15:07, Alexander Sokol <[hidden email]> wrote:

> Hi Peter:
>
> We were able to solve the errors such as the one you mentioned in your post
> by operator overloading in boost namespace. The code sample is below in this
> email.
>
> Best regards
> Alex
>
> Sample error message:
>
> 1>c:\projects\quantlib\dependencies\cpp\boost\numeric\ublas\detail\matrix_assign.hpp(34):
> error C2678: binary '<' : no operator found which takes a left-hand operand
> of type 'boost::numeric::ublas::matrix_scalar_unary<E,F>' (or there is no
> acceptable conversion)
>
> Code snippet which fixes this error:
>
> #include <cppad/cppad.hpp>
>
> namespace boost {
>        namespace numeric {
>               namespace ublas
>               {
>                      template<class M>
>                      class sparse_matrix_element;
>
>                      template<class T, class L, std::size_t IB, class IA,
> class TA>
>                      class compressed_matrix;
>
>                      template<class T, class ALLOC>
>                      class unbounded_array;
>
>                      namespace detail {
>
>                            template <typename Left, typename Right>
>                            inline bool operator < (Left const& left,
> CppAD::AD<Right> const& right)
>                            {
>
> #pragma message ("overload operator < : " __FUNCSIG__)
>                                   // This is only for demonstrate
>                                   // Ensure that adjoint logic will workable
>                                   return left < CppAD::Value(right);
>                            }
>                      }
>               }
>        }
> }
>
> #include <boost/numeric/ublas/lu.hpp>
> using namespace std;
>
>
> int main() {
>     typedef CppAD::AD<double> T;
>     boost::numeric::ublas::matrix<T> a(5, 5);
>     boost::numeric::ublas::permutation_matrix<std::size_t> pert(5);
>     // lu decomposition
>     const std::size_t s = lu_factorize(a, pert);
>
>     return 0;
> }
>
>
>
>
> --
> View this message in context: http://quantlib.10058.n7.nabble.com/Adjoint-Greeks-tp16147p16486.html
> Sent from the quantlib-dev mailing list archive at Nabble.com.
>
> ------------------------------------------------------------------------------
> BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
> Develop your own process in accordance with the BPMN 2 standard
> Learn Process modeling best practices with Bonita BPM through live exercises
> http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
> source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
> _______________________________________________
> QuantLib-dev mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev

------------------------------------------------------------------------------
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev
123