Re: improve <boost/math/constants.hpp>

From: John Maddock (jz.maddock_at_[hidden])
Date: 2023-03-11 10:44:05

On 10/03/2023 21:12, Gero Peterhoff via Boost wrote:
> Hello,
> * Problem description
> The constants do not work with the C++23 FP types.
We will make sure that they will - once a working implementation is 
*released*.
>
> * general hint
> To prevent (more) warnings it is useful to introduce this macro:
> #if defined(__STDCPP_FLOAT128_T__)

 From past experience, __STDCPP_FLOAT128_T__ is a deeply unreliable 
indicator.

> * question
> In constants the namespaces float/double/long_double_constant+detail 
> are created type dependent (in case the value constexpr can be 
> requested). If the value cannot be requested constexpr the conversion 
> is finally done by boost::lexical_cast.
> But the implementation is very complex. I have a better one - but I 
> may have missed things.
> If so - which would they be?

Off the top of my head I see two main correctness issues:

* Your code introduces *double rounding* for float/double (and maybe 
long double) types, as a result the constants for these types will no 
longer guarantee last digit accuracy.  This is a deal breaker for me.

* For multiprecision types with more digits than we can reasonably store 
in a string your constants will have insufficient accuracy (cached 
runtime calculation is needed in this case).

It's also lacking some "nice to have" features, for example, you have 
all UDT types going the lexical_cast route, but if the type can be 
constructed from a builtin type with sufficient precision, then the code 
is more efficient and constexpr that way.  For example with 
boost::multiprecision::float128.

John.

>
> * My solution (BOOST_MAKE_MATH_CONSTANT)
> see constants_more.hpp, advantages:
> - works with all FP types
> - compatible to the existing implementation CONSTANT<Type>()
> - is clear/understandable (comments)
> - may need only one additional namespace static_constants (and not 4)
> - provides the constants additionally as CONSTANT_v (constexpr) or 
> static_constants::CONSTANT_v (not constexpr) (if possible)
>
> What is your opinion? Are there still errors in it?
>
> It would be even nicer if boost::lexical_cast and/or 
> boost::math::tools::convert_from_string were constexpr. This would 
> further simplify the implementation.
>
> thx + regards
> Gero
>
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost