Re: [boost] [math] Extended float in C++ : Was : Support for libquadmath/ __float128

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
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
[phone]  07714330204
pbristow_at_[hidden]