Am 12.04.23 um 15:18 schrieb Christopher Kormanyos via Boost:
>    >>>> * 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/multiprecision/detail/float128_functions.hpp 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-point/m-p/1216949)
>> 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
Hi Matt, Hi Chris,
Thanks for your comments. However, I didn't want this to be that elaborate, I just wanted to define a unique C++ interface for __float128. Right now, IO functions are spread across different header files with divergent functionality, for example:
1) boost/math/cstdfloat/cstdfloat_cmath.hpp: non-template operator<<
2) boost/math/cstdfloat/cstdfloat_iostream.hpp: operator<< operator>>
3) There are quite a few forward declarations/defines in boost/multiprecision/float128.hpp, although they are available in boost/math/cstdfloat/cstdfloat_cmath.hpp.
Also, float128_backend::str seems to support std::hexfloat, which 1+2 do not.

Therefore it would make sense to provide quadmath for __float128 (or intel _Quad) as a sub-library of boost.math to unify this and provide more functions (e.g. C++17 from_chars/to_chars, to_w/string). boost/multiprecision/float128.hpp could then simply use this (#include ).

I've started with this before (see attachment); for gcc it's halfway ok, intel doesn't work.

cu
Gero