...

...

...

* problem description In boost::math::cstdfloat AND boost::multiprecision::float128>>>> identical functions for __float128 (quadmath) are provided.

This is unnecessary overhead. I think it would make sense>>>> to "pull out" the quadmath library as a distinct library Chris Kormanyos and I have discussed writing a software> implementation of binary128 that could be used cross> platform. That would be more valuable as a separate library. It is good to read this discussion. Historically, it all went like this...

When we started , we wereinterested in specifying floating-point types havingfixed-widths. This proposal was abandoned in the2013 timeframe, but recently picked up and broughtinto C++23 with some new stuff. Around that time, we also "invented" Multiprecision,which came into Boost 1.53, basically with the numberbackend and cpp_dec_float only. We went on(with lots and lots of work primiarly by John) toadd several backends to Multiprecision, one ofthem being Multiprecision's float128 backend. So indeed, we have two 128 bit floats hangingaround, yet form some platforms such as thepopular MSVC, we have zero 128-bit floatimplementations. Writing a uniform, cross-platform implementationcombined with aliases and/or seamless use inMultiprecision is, I believe, something of interestto us all. But i believe we need some specifyingwork and a few trial implementations in order tosee how all of this should fit in together nicelain a post C++23 domain. This is good discussion and I think we will followup on it. Chris On Wednesday, April 12, 2023 at 01:12:01 PM GMT+2, Matt Borland via Boost wrote:

On Apr 11, 2023, at 8:09 PM, Gero Peterhoff via Boost wrote:

Am 13.03.23 um 13:33 schrieb John Maddock via Boost:

...

On 13/03/2023 02:43, Gero Peterhoff via Boost wrote:

...

Hello, * problem description In boost::math::cstdfloat AND boost::multiprecision::float128 identical functions for __float128 (quadmath) are provided.

This is unnecessary overhead. I think it would make sense to "pull out" the quadmath library as a distinct library. I did this once canonically, but it doesn't work yet because boost::math::cstdfloat/boost::multiprecision::float128 have to be adapted for this. This is a prototype where there is still a lot of work to be done. But the beginning is done.

If you mean https://github.com/boostorg/multiprecision/blob/develop/include/boost/multip... then it's a trivially small header, and spinning stuff out into a separate library has a significant maintenance overhead.

I mean this canonically. Advantages: - For both compilers (gcc/intel) the functions/limits can be provided directly, without the mass #define/#undef function-macros. - Clean separation and/or Konsolidierugn of the __float128 types: a) gcc: __float128

GCC also provides support for __ibm128 on PowerPC platforms. We don’t have any support for it because there has been no demand signal.

b) intel: Windows _Qaud -> __float128, !Windows -> __float128 (https://community.intel.com/t5/Intel-C-Compiler/C-Compiler-128-bit-floating-...) So there is only one type __float128. - Clean/mature standard functions can be provided for IO.

Disadvantages: - One-time(!) effort to update dependent libs.

Boost.Multiprecision is already available without the rest of Boost: https://github.com/boostorg/multiprecision/releases so there isn’t much bloat in the way it can be consumed now. Chris Kormanyos and I have discussed writing a software implementation of binary128 that could be used cross platform. That would be more valuable as a separate library. Matt _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost