Subject: Re: [boost] [math] Extended float in C++ : Was : Support for libquadmath/ __float128
From: Paul A. Bristow (pbristow_at_[hidden])
Date: 2013-03-19 05:27:53
> -----Original Message-----
> From: Boost [mailto:boost-bounces_at_[hidden]] On Behalf Of Christopher Kormanyos
> Sent: Monday, March 18, 2013 9:46 PM
> To: boost_at_[hidden]
> 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
> Here, I am talking about floating-point types with fixed precision such as 24, 54, 113 or more
> 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
> but there is a remark in Section 6.11.1:
> "Future standardization may include additional floating-point types, including those with greater
> 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++
> 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
> 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
> Is there any interest in committing to this project?
> Specification takes a long time and requires a coalition of collaborators. I could potentially
> 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 A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow_at_[hidden]
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk