|
Boost : |
Subject: [boost] [math] Extended float in C++ : Was : Support for libquadmath/ __float128
From: Christopher Kormanyos (e_float_at_[hidden])
Date: 2013-03-18 17:46:01
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk