[math] Support for libquadmath/ __float128
I have experimented with the quadmath library included with gcc and the boost::math::constants library and encountered several problems. - typeid is seemingly not supported for __float128, which requires an overload of nameof<__float128> - the stream extraction operator has to be provided for __float128 for string conversion to work - a specialisation of numeric_limits has to be provided. Is there an interest in incorporating __float128 into boost ? If so, would it be a good idea to specialise constants for __float128 as well, apart from float, double and long double? Regards Claas
I have experimented with the quadmath library included with gcc and the boost::math::constants library and encountered several problems.
- typeid is seemingly not supported for __float128, which requires an overload of nameof<__float128> - the stream extraction operator has to be provided for __float128 for string conversion to work - a specialisation of numeric_limits has to be provided.
Is there an interest in incorporating __float128 into boost ? If so, would it be a good idea to specialise constants for __float128 as well, apart from float, double and long double?
Funnilly enough I wondered about this the other day, but haven't had the time to do anything about it. Plus I've rather been hoping that the GCC guys would make __int128 and __float128 first class citizens and render the issue moot ;-) An open question is whether we should add a "binding" header under boost/math/bindings or whether it would be better to wrap __float128 and libquadmath as a multiprecision type under boost/multiprecision. The latter option has the advantage that we don't have to pollute the global namespace with std lib overloads for __float128. Of course a simpler solution is possible if you just want the numeric constants working for __float128, but it would be nice to make the type a first class C++ type that interoperates with all of Boost.Math. John.
I have experimented with the quadmath library included with gcc and the boost::math::constants library and encountered several problems.
- typeid is seemingly not supported for __float128, which requires an overload of nameof<__float128> - the stream extraction operator has to be provided for __float128 for string conversion to work - a specialisation of numeric_limits has to be provided.
Is there an interest in incorporating __float128 into boost ? If so, would it be a good idea to specialise constants for __float128 as well, apart from float, double and long double?
Funnilly enough I wondered about this the other day, but haven't had the time to do anything about it. Plus I've rather been hoping that the GCC guys would make __int128 and __float128 first class citizens and render the issue moot ;-)
Well, finally IEE754:2008 has a full specification of quadruple-precision floating-point types. It will probably, however, take a long time for these to be widely supported by compiler vendors.
An open question is whether we should add a "binding" header under boost/math/bindings or whether it would be better to wrap __float128 and libquadmath as a multiprecision type under boost/multiprecision.
The latter option has the advantage that we don't have to pollute the global namespace with std lib overloads for __float128.
Of course a simpler solution is possible if you just want the numeric constants working for __float128, but it would be nice to make the type a first class C++ type that interoperates with all of Boost.Math. John.
If you would like my opinion, I would recommend creating a backend for boost::multiprecision::number, as John has suggested. The backend *looks* formidable in code, but it is quite lightweight. This would provide a very nice resource for Boost. When I published the original work that partly influenced boost::multiprecision, I did a similar wrapping of the Fortran77 type REAL*16. Yes, you heard right, Fortran77! This kind of wrapped type is very efficient because the underlying type is a native one, as would be expected as well for a wrap of GCC's __float128. But John, don't you already have the wrap? During the review of Multiprecision, you provided evidence of the lightweight overhead of boost::multiprecision::number by implementing a wrap for the native double type. I seem to remember that you implemented this wrap as a template for potentially any native type. Would this potentially be another project for GSoC 2013? Sincerely, Chris.
Of course a simpler solution is possible if you just want the numeric constants working for __float128, but it would be nice to make the type a first class C++ type that interoperates with all of Boost.Math. John.
If you would like my opinion, I would recommend creating a backend for boost::multiprecision::number, as John has suggested. The backend *looks* formidable in code, but it is quite lightweight. This would provide a very nice resource for Boost.
But John, don't you already have the wrap? During the review of Multiprecision, you provided evidence of the lightweight overhead of boost::multiprecision::number by implementing a wrap for the native double type. I seem to remember that you implemented this wrap as a template for potentially any native type.
I almost have the wrap - the builtin-type wrapper I provided won't quite work "as is" because __float128 isn't a first class native type. But it's only a cut and paste job to fix it up.
Would this potentially be another project for GSoC 2013?
Might actually be too small for that, although it could be used as a way of getting them started. Proabably not very "exciting" for them either :-( John.
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Claas Sent: Thursday, February 21, 2013 3:24 PM To: boost@lists.boost.org Subject: [boost] [math] Support for libquadmath/ __float128
I have experimented with the quadmath library included with gcc and the boost::math::constants library and encountered several problems.
- typeid is seemingly not supported for __float128, which requires an overload of nameof<__float128> - the stream extraction operator has to be provided for __float128 for string conversion to work - a specialisation of numeric_limits has to be provided.
Is there an interest in incorporating __float128 into boost ? If so, would it be a good idea to specialise constants for __float128 as well, apart from float, double and long double?
As John and Chris have observed already, it would be nicest to have proper compiler and platform support for __float128, including numeric_limits, and/or full. I'm not sure how to facilitate this but perhaps firstly users need to do more asking? (It seems to take an inordinate length of time to get compilers and libraries to fully support numeric_limits, especially max_digits10). But meanwhile, have you considered using the cpp_dec_float (and cpp_int) types from Boost.Multiprecision. A predefined 50 digit version is very easy to use, and a 40 digit version almost as easy. Of course, speed will not be nearly as good, but accuracy will be fine. Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow@hetp.u-net.com
On 22/02/13 13:33, Paul A. Bristow wrote:
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Claas Sent: Thursday, February 21, 2013 3:24 PM To: boost@lists.boost.org Subject: [boost] [math] Support for libquadmath/ __float128
I have experimented with the quadmath library included with gcc and the boost::math::constants library and encountered several problems.
- typeid is seemingly not supported for __float128, which requires an overload of nameof<__float128> - the stream extraction operator has to be provided for __float128 for string conversion to work - a specialisation of numeric_limits has to be provided.
Is there an interest in incorporating __float128 into boost ? If so, would it be a good idea to specialise constants for __float128 as well, apart from float, double and long double?
As John and Chris have observed already, it would be nicest to have proper compiler and platform support for __float128, including numeric_limits, and/or full.
I'm not sure how to facilitate this but perhaps firstly users need to do more asking? Where should I best complain? :-)
But meanwhile, have you considered using the cpp_dec_float (and cpp_int) types from Boost.Multiprecision. A predefined 50 digit version is very easy to use, and a 40 digit version almost as easy.
Actually I already wrote my own overload of numeric_limits, io-operators, math functions and std::complex. Thus things work relatively smooth for me. I just figured, that probably many users meanwhile created the same overloads, so I wondered if there is a critical mass to supply this code in boost to avoid a lot of duplicate code generation. I agree, that this should best be provided by the compiler people, but since libquadmath is around for quite a while and no C++ support is available yet, I needed an intermediate solution. The thing with boost constants is, that it does not provide explicit support for __float128, so constants are generated from strings. Thus I was wondering if there are plans to provide constexpr overloads similar to the built-in types for __float128. As far as I can tell, the number of digits in the stored (non-string) constants is sufficient, so replacing "L" by "Q" in the long double specialisations should do the trick (plus adding the new type of course). On the other hand, this would probably require the additional functionality of <math>, <complex> and numeric_limits to be consistent.
Of course, speed will not be nearly as good, but accuracy will be fine.
Paul
--- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow@hetp.u-net.com
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Claas wrote:
I have experimented with the quadmath library included with gcc and the boost::math::constants library
and encountered several problems.
Paul wrote:
But meanwhile, have you considered using the cpp_dec_float (and cpp_int) types from Boost.Multiprecision. A predefined 50 digit version is very easy to use, and a 40 digit version almost as easy.
Claas wrote:
Actually I already wrote my own overload of numeric_limits, io-operators, math functions and std::complex. Thus things work relatively smooth for me.
I just figured, that probably many users meanwhile created the same overloads, so I wondered if there is a critical mass to supply this code in boost to avoid a lot of duplicate code generation.
We hear you. In fact, you are really preaching to the choir on this one. We have all done numerous workarounds, waiting patches and re-writes of Fortran stuff, all to get our hands on the 34 digits of quad. Claas wrote:
I agree, that this should best be provided by the compiler people, but since libquadmath is around for quite a while and no C++ support is available yet, I needed an intermediate solution.
You are right again. I know how frustrating this is! Claas wrote:
The thing with boost constants is, that it does not provide explicit support for __float128, so constants are generated from strings. Thus I was wondering if there are plans to provide constexpr overloads similar to the built-in types for __float128. As far as I can tell, the number of digits in the stored (non-string) constants is sufficient, so replacing "L" by "Q" in the long double specialisations should do the trick (plus adding the new type of course).
This is where we need to reach a decision. GCC's __float128 is an exotic, non-standard type. Nonetheless, it is popular and widely used. If we decide to support it in Boost, the right place is probably not in the constants section of Boost.Math, but rather as a backend type for Boost.Multiprecision, as mentioned earlier by John. In this way you would retain near-native performance and attain access to *all* the functions in Boost.Math, including the constants. In addition, there is a Boost extended complex library waiting for a review manager. So if we ever get complex reviewed and potentially into Boost, then you will be able to use types other than float, double and long double with complex. Of course, you are a rough-and-ready programmer and you already wrote your own --- like everyone else who needs it has to do (frown). The frustrating thing is that it will take us a long time to add support for the functions you need. It will, however, probably take compiler vendors longer to support quad. So in the intermediate time, you still need to roll your own quadmath, complex for quad, numeric limits for quad, etc. But you might seriously consider writing your own backend for Boost.Multiprecision using __float128. If you do this and use Boost.Multiprecision consistently as a template parameter in your generic math algorithms, then you can also use, via template parameter, the multiprecision types mentioned by Paul if the 34 digits of quad are insufficient and you need the 50 or 100 or more digits of Boost.Multiprecision. If we can get a consensus on support for GCC's libquadmath in Boost.Multiprecision, I would volunteer to write the backend for it. But I need a few months before I get that kind of time slot for writing, testing, etc. I wonder what John and Paul think about adding support for this. I'm skeptical because the type really only works with one compiler, and then you need to --enable-quadmath when building GCC in order to get it. It's a nightmare! Good luck and please keep in touch if you would like to pursue this matter further. Sincerely, Chris.
If we can get a consensus on support for GCC's libquadmath in Boost.Multiprecision, I would volunteer to write the backend for it. But I need a few months before I get that kind of time slot for writing, testing, etc. I wonder what John and Paul think about adding support for this. I'm skeptical because the type really only works with one compiler, and then you need to --enable-quadmath when building GCC in order to get it. It's a nightmare!
I think this is really the issue - figuring out when to enable support for this feature. BTW, I can see a genuine use case for constexpr 128-bit float constants even if the right way to handle __float128 is to wrap it in the Multiprecision lib. I wonder are there any predefined macros we can use like __SIZEOF_INT128__ is for __int128? John.
If we can get a consensus on support for GCC's libquadmath
in Boost.Multiprecision, I would volunteer to write the backend for it. But I need a few months before I get that kind of time slot for writing, testing, etc. I wonder what John and Paul think about adding support for this. I'm skeptical because the type really only works with one compiler, and then you need to --enable-quadmath when building GCC in order to get it. It's a nightmare!
I think this is really the issue - figuring out when to enable support for this feature.
BTW, I can see a genuine use case for constexpr 128-bit float constants even if the right way to handle __float128 is to wrap it in the Multiprecision lib. I wonder are there any predefined macros we can use like __SIZEOF_INT128__ is for __int128? John.
I agree, of course. It guarantees compile-time const-ness. In C++11, I use something like this: template<typename built_in_float_type> built_in_float_type const_pi() { // This is a true compile-time constant. return built_in_float_type(3.14159265358979323846264338327950288419716939937511); } I do not use any suffixes on the literal number. But you really need C++11 for this. And then you need to differentiate it from the multiprecision constants, which still might force the creation of template specializations. Quite honestly, I can never really sort it all out, but I suppose it's possible to do so. Has anyone suggested "long long double" for C++17? Sincerely, Chris.
<snip>
BTW, I can see a genuine use case for constexpr 128-bit float constants even if the right way to handle __float128 is to wrap it in the Multiprecision lib. I wonder are there any predefined macros we can use like __SIZEOF_INT128__ is for __int128? John.
I agree, of course. It guarantees compile-time const-ness.
<snip> Of course, I made a mistake. You need to qualify the return value with constexpr. template<typename built_in_float_type> constexpr built_in_float_type const_pi() { // This is a true compile-time constant. return built_in_float_type(3.14159265358979323846264338327950288419716939937511); } Sorry. Sincerely, Chris.
Of course, I made a mistake. You need to qualify the return value with constexpr.
template<typename built_in_float_type> constexpr built_in_float_type const_pi() { // This is a true compile-time constant. return built_in_float_type(3.14159265358979323846264338327950288419716939937511); }
That only gives you a double precision constant irrespective of the cast, John.
Of course, I made a mistake. You need to qualify the
return value with constexpr.
template<typename built_in_float_type> constexpr built_in_float_type const_pi() { // This is a true compile-time constant. return built_in_float_type(3.14159265358979323846264338327950288419716939937511); }
That only gives you a double precision constant irrespective of the cast, John.
Groan. You're right.
From ISO/IEC 14882:2011 Sect. 2.14.4:
"The type of a floating literal is double unless explicitly specified by a suffix. The suffixes f and F specify float, the suffixes l and L specify long double." Thanks for the clarification, John. So this means that the suffixes L and l are the "longest" floating-point suffixes supported by the language and that the suffixes Q and q are non-portable language extensions. Is this right? So the only way to add Q or q suffixes would be to find a way to query the environment if it is supported. I wonder if GCC with --enable-libquadmath has a kind of query for this. What a mess! I'm starting to re-remember why I wrote e_float in the first place. Best regards, Chris.
So this means that the suffixes L and l are the "longest" floating-point suffixes supported by the language and that the suffixes Q and q are non-portable language extensions. Is this right?
Correct.
So the only way to add Q or q suffixes would be to find a way to query the environment if it is supported. I wonder if GCC with --enable-libquadmath has a kind of query for this.
I haven't found one - gcc-4.7.2 has all sorts of __SIZEOF_XXX__ defines for every last type *except* __float128 and __float80 :-( John.
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of John Maddock Sent: Monday, February 25, 2013 9:22 AM To: boost@lists.boost.org Subject: Re: [boost] [math] Support for libquadmath/ __float128
So this means that the suffixes L and l are the "longest" floating-point suffixes supported by the language and that the suffixes Q and q are non-portable language extensions. Is this right?
Correct.
So the only way to add Q or q suffixes would be to find a way to query the environment if it is supported. I wonder if GCC with --enable-libquadmath has a kind of query for this.
I haven't found one - gcc-4.7.2 has all sorts of __SIZEOF_XXX__ defines for every last type *except* __float128 and __float80 :-(
It won't help now, but is 'more precise types' an issue to raise with WG21 for the next C++ standard? Or is Multiprecision the way to go? Paul
On 25/02/13 11:16, Paul A. Bristow wrote:
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of John Maddock Sent: Monday, February 25, 2013 9:22 AM To: boost@lists.boost.org Subject: Re: [boost] [math] Support for libquadmath/ __float128
So this means that the suffixes L and l are the "longest" floating-point suffixes supported by the language and that the suffixes Q and q are non-portable language extensions. Is this right?
Correct.
So the only way to add Q or q suffixes would be to find a way to query the environment if it is supported. I wonder if GCC with --enable-libquadmath has a kind of query for this.
I haven't found one - gcc-4.7.2 has all sorts of __SIZEOF_XXX__ defines for every last type *except* __float128 and __float80 :-(
Sorry for a possibly stupid questio, but is it not possible to use any of the FLT128_XXX defines listed here: http://gcc.gnu.org/onlinedocs/libquadmath/Typedef-and-constants.html#Typedef... Claas
It won't help now, but is 'more precise types' an issue to raise with WG21 for the next C++ standard?
Or is Multiprecision the way to go?
Paul
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
I haven't found one - gcc-4.7.2 has all sorts of __SIZEOF_XXX__ defines for every last type *except* __float128 and __float80 :-(
Sorry for a possibly stupid questio, but is it not possible to use any of the FLT128_XXX defines listed here:
http://gcc.gnu.org/onlinedocs/libquadmath/Typedef-and-constants.html#Typedef...
Including that header will only work (as in not generate a compiler error) if the compiler supports __float128 as a native type, which is what we want to work out... basically whether the GCC build was configured to support it or not. John.
On 25 February 2013 16:28, John Maddock wrote:
I haven't found one - gcc-4.7.2 has all sorts of __SIZEOF_XXX__ defines for every last type
*except*
__float128 and __float80 :-(
Sorry for a possibly stupid questio, but is it not possible to use any of the FLT128_XXX defines listed here:
http://gcc.gnu.org/onlinedocs/libquadmath/Typedef-and-constants.html#Typedef...
Including that header will only work (as in not generate a compiler error) if the compiler supports __float128 as a native type, which is what we want to work out... basically whether the GCC build was configured to support it or not.
The current libstdc++ headers define _GLIBCXX_USE_FLOAT128 if __float128 is supported, but that's an implementation detail and shouldn't be relied on (relying on _GLIBCXX_HAS_GTHREADS broke Boost.Threads recently when GCC 4.7 stopped defining it.)
Including that header will only work (as in not generate a compiler error) if the compiler supports __float128 as a native type, which is what we want to work out... basically whether the GCC build was configured to support it or not.
The current libstdc++ headers define _GLIBCXX_USE_FLOAT128 if __float128 is supported, but that's an implementation detail and shouldn't be relied on (relying on _GLIBCXX_HAS_GTHREADS broke Boost.Threads recently when GCC 4.7 stopped defining it.)
I've added minimal __float128 support in Boost.Math Trunk: it's enabled whenever BOOST_MATH_USE_FLOAT128 is set, which it is automatically when the above macro is detected (which I note libstdc++ doesn't seem to use anywhere itself). Also filed a gcc bug report on the lack of a __SIZEOF__ macro for __float128: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56540 HTH, John.
On 7 March 2013 09:20, John Maddock wrote:
I've added minimal __float128 support in Boost.Math Trunk: it's enabled whenever BOOST_MATH_USE_FLOAT128 is set, which it is automatically when the above macro is detected (which I note libstdc++ doesn't seem to use anywhere itself).
It's used in <type_traits> #if !defined(__STRICT_ANSI__) && defined(_GLIBCXX_USE_FLOAT128) template<> struct __is_floating_point_helper<__float128> : public true_type { }; #endif
So this means that the suffixes L and l are the "longest"
floating-point suffixes supported by the language and that the suffixes Q and q are non-portable language extensions. Is this right?
Correct.
So the only way to add Q or q suffixes would be to find a way to query the environment if it is supported. I wonder if GCC with --enable-libquadmath has a kind of query for this.
I haven't found one - gcc-4.7.2 has all sorts of __SIZEOF_XXX__ defines for every last type *except* __float128 and __float80 :-(
It won't help now, but is 'more precise types' an issue to raise with WG21 for the next C++ standard? Or is Multiprecision the way to go? Paul
I would welcome both. Remember what a relief it was to finally be able to use specified fixed-size integers such as std::uint16_t, std::uint32_t, and the like? These standardized types solved a host of portability problems for integer algorithms. Having fixed-precision floating-point types such as std::float32_t, std::float64_t, std::float128_t would, in my opinion, solve an even grander host of portability issues for floating-point algorithms. We have all grudgingly struggled with these for 30 years. (Where has my long lost love Fortran77's REAL*16 from the '80s gone?) Although multiprecision can, and possibly should, be addresses, I would not rely on multiprecision alone for a potential std::float128_t. The reason for this is because a potential std::float128_t can be well-implemented *on-the-metal* on many systems and offer the high performance thereof. Multiprecision will always suffer large performance losses (unless it gets onto a GPU). Just my $.02. Sincerely, Chris.
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Christopher Kormanyos Sent: Monday, February 25, 2013 6:26 PM To: boost@lists.boost.org Subject: Re: [boost] [math] Support for libquadmath/ __float128
So this means that the suffixes L and l are the "longest"
floating-point suffixes supported by the language and that the suffixes Q and q are non-portable language extensions. Is this right?
Correct.
So the only way to add Q or q suffixes would be to find a way to query the environment if it is supported. I wonder if GCC with --enable-libquadmath has a kind of query for this.
I haven't found one - gcc-4.7.2 has all sorts of __SIZEOF_XXX__ defines for every last type *except* __float128 and __float80 :-(
It won't help now, but is 'more precise types' an issue to raise with WG21 for the next C++ standard? Or is Multiprecision the way to go? Paul
I would welcome both.
Remember what a relief it was to finally be able to use specified fixed-size integers such as std::uint16_t, std::uint32_t, and the like? These standardized types solved a host of portability problems for integer algorithms.
Having fixed-precision floating-point types such as std::float32_t, std::float64_t, std::float128_t would, in my opinion, solve an even grander host of portability issues for floating-point algorithms. We have all grudgingly struggled with these for 30 years.
(Where has my long lost love Fortran77's REAL*16 from the '80s gone?)
Although multiprecision can, and possibly should, be addresses, I would not rely on multiprecision alone for a potential std::float128_t. The reason for this is because a potential std::float128_t can be well- implemented *on-the-metal* on many systems and offer the high performance thereof. Multiprecision will always suffer large performance losses (unless it gets onto a GPU).
Agreed. So what do we need to get into the next C++ version in order to facilitate this? Does std::decimal_128 in http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1977.html give any good ideas? 1 std::float32_t, std::float64_t, std::float80_t, std::float128_t, and std::float256_t (and even std::float512_t - though I would think that 512 was time to go multiprecision) 2 A mechanism to discover which of these are supported by a particular implementation. (Testing if sizeof double == sizeof long double is a crummy way to find out if long double is really supported! We need something better - and I'd prefer a language solution rather than a macro). 3 Suffix(es) like Q to define longer constants? It takes a (much too) long time to get these things into the Standard and even longer to get them implemented, so we need to plan a long time ahead. Views? Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow@hetp.u-net.com
There has been some recent discussion on extended floating-point types in C++.
So the only way to add Q or q suffixes would be to find a way to query
the environment if it is supported. I wonder if GCC with --enable-libquadmath has a kind of query for this.
I haven't found one - gcc-4.7.2 has all sorts of __SIZEOF_XXX__ defines for every last type *except* __float128 and __float80 :-(
It won't help now, but is 'more precise types' an issue to raise with WG21 for the next C++ standard? Or is Multiprecision the way to go?
Is there any definitive interest in adding more precise floating-point types to C++ in the next draft? Here, I am talking about floating-point types with fixed precision such as 24, 54, 113 or more binary digits, and possibly even extending beyond these to potential multiprecision types. See also Boost.Multiprecision. Consider the C language in ISO/IEC 9899:2011 (in other words C11). Extended precision is not specified, but there is a remark in Section 6.11.1: "Future standardization may include additional floating-point types, including those with greater range, precision, or both than long double." Recent specification of fixed-size integer types in C99, C11 and C++11 has drastically improved integer algorithm portability and range. Similar specification of fixed-size floating-point types could potentially improve the C++ language significantly, especially in the scientific and engineering communities. One could envision two ways to go: * Types such as float24_t, float53_t, float113_t, ... * Types such as float32_t, float64_t, float128_t, ...The first set above is intuitively coined from IEE754:2008. It is also consistent with the gist of std::uint32_t, et al --- in so far as the number of binary digits of precision is contained within the name of the data type. Is there any interest in committing to this project? Specification takes a long time and requires a coalition of collaborators. I could potentially contribute to this project as a subordinate author. But I don't feel confident enough to champion such a cause. Best regards, Chris.
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Christopher Kormanyos Sent: Monday, March 18, 2013 9:46 PM To: boost@lists.boost.org Subject: [boost] [math] Extended float in C++ : Was : Support for libquadmath/ __float128
There has been some recent discussion on extended floating-point types in C++.
So the only way to add Q or q suffixes would be to find a way to query
the environment if it is supported. I wonder if GCC with --enable-libquadmath has a kind of query for this.
I haven't found one - gcc-4.7.2 has all sorts of __SIZEOF_XXX__ defines for every last type *except* __float128 and __float80 :-(
It won't help now, but is 'more precise types' an issue to raise with WG21 for the next C++ standard? Or is Multiprecision the way to go?
Is there any definitive interest in adding more precise floating-point types to C++ in the next draft?
Here, I am talking about floating-point types with fixed precision such as 24, 54, 113 or more binary digits, and possibly even extending beyond these to potential multiprecision types.
See also Boost.Multiprecision.
Consider the C language in ISO/IEC 9899:2011 (in other words C11). Extended precision is not specified, but there is a remark in Section 6.11.1:
"Future standardization may include additional floating-point types, including those with greater range, precision, or both than long double."
Recent specification of fixed-size integer types in C99, C11 and C++11 has drastically improved integer algorithm portability and range.
Similar specification of fixed-size floating-point types could potentially improve the C++ language significantly, especially in the scientific and engineering communities.
One could envision two ways to go:
* Types such as float24_t, float53_t, float113_t, ... * Types such as float32_t, float64_t, float128_t, ...The first set above is intuitively coined from IEE754:2008. It is also consistent with the gist of std::uint32_t, et al --- in so far as the number of binary digits of precision is contained within the name of the data type.
Is there any interest in committing to this project? Specification takes a long time and requires a coalition of collaborators. I could potentially contribute to this project as a subordinate author. But I don't feel confident enough to champion such a cause.
I think that, although fixed/higher-precisions is a 'niche market', they are 'killer' features for some would-be C++ users. So I would strongly support these additions and am willing to contribute what I can. Preparing a draft 'N' paper for discussion here would be a start, with some use cases demos, and then submission to WG21 for their consideration. The wording of std::uint32_t will provide a Standardese template? Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow@hetp.u-net.com
On 22/02/13 13:33, Paul A. Bristow wrote:
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Claas Sent: Thursday, February 21, 2013 3:24 PM To: boost@lists.boost.org Subject: [boost] [math] Support for libquadmath/ __float128
I have experimented with the quadmath library included with gcc and the boost::math::constants library and encountered several problems.
- typeid is seemingly not supported for __float128, which requires an overload of nameof<__float128> - the stream extraction operator has to be provided for __float128 for string conversion to work - a specialisation of numeric_limits has to be provided.
Is there an interest in incorporating __float128 into boost ? If so, would it be a good idea to specialise constants for __float128 as well, apart from float, double and long double?
As John and Chris have observed already, it would be nicest to have proper compiler and platform support for __float128, including numeric_limits, and/or full.
I'm not sure how to facilitate this but perhaps firstly users need to do more asking? Where should I best complain? :-)
But meanwhile, have you considered using the cpp_dec_float (and cpp_int) types from Boost.Multiprecision. A predefined 50 digit version is very easy to use, and a 40 digit version almost as easy.
Actually I already wrote my own overload of numeric_limits, io-operators, math functions and std::complex. Thus things work relatively smooth for me. I just figured, that probably many users meanwhile created the same overloads, so I wondered if there is a critical mass to supply this code in boost to avoid a lot of duplicate code generation. I agree, that this should best be provided by the compiler people, but since libquadmath is around for quite a while and no C++ support is available yet, I needed an intermediate solution. The thing with boost constants is, that it does not provide explicit support for __float128, so constants are generated from strings. Thus I was wondering if there are plans to provide constexpr overloads similar to the built-in types for __float128. As far as I can tell, the number of digits in the stored (non-string) constants is sufficient, so replacing "L" by "Q" in the long double specialisations should do the trick (plus adding the new type of course). On the other hand, this would probably require the additional functionality of <math>, <complex> and numeric_limits to be consistent.
Of course, speed will not be nearly as good, but accuracy will be fine.
Paul
--- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow@hetp.u-net.com
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
participants (6)
-
"Claas H. Köhler" -
Christopher Kormanyos -
Claas
-
John Maddock -
Jonathan Wakely -
Paul A. Bristow