Re: [boost] New library proposal: Autodiff

Subject: Re: [boost] New library proposal: Autodiff
From: mike.dev_at_[hidden]
Date: 2018-12-20 17:38:03

> -----Original Message-----
> From: Boost <boost-bounces_at_[hidden]> On Behalf Of Matt Pulver via Boost
> Sent: Tuesday, December 18, 2018 5:38 PM
> 
> Hello,
> 
> An automatic differentiation
> <https://en.wikipedia.org/wiki/Automatic_differentiation> C++ library -
> Autodiff - is released under the Boost License and is proposed for
> inclusion into Boost:
> 
>    - Github: https://github.com/pulver/autodiff
>    - Boost Library Incubator:
>    http://blincubator.com/bi_library/autodiff-2/?gform_post_id=1716
> 
> Features:
> 
>    - Instances of autodiff variables satisfy Boost's Conceptual
>    Requirements for Real Number Types
>    <https://www.boost.org/doc/libs/1_69_0/libs/math/doc/html/math_toolkit/real_concepts.html>.
>    In fact the class and function template definitions are based upon the
>    tables in this page.
>    - No use of dynamic memory. The only member variable is a std::array<>.
>    - Consistent with Boost's type promotion templates. When
>    adding/multiplying/etc. variables of differing dimension number and sizes,
>    the resulting data type is calculated at compile-time.
>    - Single header-only file.
>    - Intuitive and minimal API.
> 
> Requirements:
> 
>    - C++17 compiler that supports constexpr if statements. There are a fair
>    amount of calculations done at compile-time which would require messy
>    SFINAE hacks to make this C++14-compatible.
> 
> Todo:
> 
>    - A github build matrix that also includes clang and MSVC.
>    - Additional documentation, including the mathematics.
> 
> Feedback and endorsements for Boost Library inclusion are welcome and
> requested.

1) What exactly is mean by "Standard Library Support Requirements"? 

Do my types have to work with the actual Standard library functions 
(e.g. via implicit conversion to double) or does there have to be a function 
with the same name that can be found via ADL?

2) Any plan to support types, where the result of a math operation might not
be the same as the operands?

3) Regarding the language standard: 
Don't use c++17 just for the sake of it, or because it simplifies a few lines of 
code.

But if (contrary to Peter Dimov's statement) it actually lets you avoid lots of 
template machinery It probably also reduces compile times and I for one 
would be very happy to see a library that prioritizes implementation simplicity 
and compile times over support for outdated standards and compilers.

Best Mike

> 
> Best regards,
> Matt
> 
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost