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

From: Gero Peterhoff (g.peterhoff_at_[hidden])
Date: 2023-03-16 22:21:02

Am 11.03.23 um 11:44 schrieb John Maddock via Boost:
> On 10/03/2023 21:12, Gero Peterhoff via Boost wrote:
- The support for XX_v is omitted.
- Additional macros BOOST_FLOATxx_C_OR_ZERO are needed.
- boost::multiprecision::float128 is now constexpr if possible.
> 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> 
I am not sure if this is actually true. When testing with pi the results were identical. If this should be generally so (testing) we can save the helper macros BOOST_FLOATxx_C_OR_ZERO and use the general version.
In the code the general version is available, but commented out.
> * 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).
Instead of lexical_cast, the constructor(sting) is now used - had overlooked that. Is the accuracy sufficient?
> * 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.
As said boost::multiprecision::float128 works now. Are there any other cases?
Exactly with boost::multiprecision::float128 it is noticed negatively that there are 3 code paths:
- gcc (BOOST_MP_USE_FLOAT128)
- intel (BOOST_MP_USE_QUAD)
- in general

This was also the reason for my other posting - quadmath as a standalone library. Then there would be only 2 code paths and the quadmath lib could be implemented more understandable. Eg there is in cstdfloat_iostream.hpp AND cstdfloat_cmath.hpp the stream operator<<. This is completely unnecessary effort.
You have expressed concerns that with these measures the code would have to be adapted - which nobody likes to do. But in the train with C++23-FP types this must be done anyway - then please correctly.

Gero