Re: [boost] [math] Support for libquadmath/ __float128

Subject: Re: [boost] [math] Support for libquadmath/ __float128
From: Paul A. Bristow (pbristow_at_[hidden])
Date: 2013-02-27 05:26:05

> -----Original Message-----
> From: Boost [mailto:boost-bounces_at_[hidden]] On Behalf Of Christopher Kormanyos
> Sent: Monday, February 25, 2013 6:26 PM
> To: boost_at_[hidden]
> 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
[phone]  07714330204
pbristow_at_[hidden]