Re: [boost] Specific-Width Floating-Point Typedefs

Subject: Re: [boost] Specific-Width Floating-Point Typedefs
From: Mathias Gaunard (mathias.gaunard_at_[hidden])
Date: 2013-05-03 07:05:59

On 09/04/13 11:32, Paul A. Bristow wrote:

> In case anyone following this thread is interested, I attach a cross posting of our replies to
> comments from Nick MacLaren from the British Standards  WG21 subgroup.

I haven't found a simple way to reply to that email, so sorry for the 
bad formatting.

 > 1  templates mean that it isn't POD

That's not true. There is nothing in the definition of POD that is 
related to templates.
What he probably meant to say is that a template class cannot be a 
fundamental type (while a fundamental type is a POD, a POD isn't 
necessarily a fundamental type). But then again, it being a template 
doesn't require a template class to be involved; it could be implemented 
with template aliases that could forward to a fundamental type if 
needed. It's a QoI issue.

 > how to specify constants with higher precision than long double

If the new extended literal mechanism doesn't allow to do this as a 
library, then it should probably be fixed.

 > 3  Ours is a simple pragmatic solution using existing hardware and no 
new software.  We don't expect 'reproducible execution', but experience 
with Boost.Math's extensive test suite suggests that it is
jolly close.  (It's the number of bits that make the significant 
differences). We're specifying
types not strict semantics.

 From my experience Boost.Math is lacking when it comes to denormals, 
nans or inf. Those are the tricky bits when different architectures are 
considered.

 > 4  Almost all C++ uses the X86 FP

What is "the X86 FP"? Results on x86 are highly variable depending on 
the microarchitecture, compilation flags and mood of the optimizer. 
(arbitrary usage of x87, SSE, FMA3, FMA4 may all lead to different results).

 > 7  float64_t will not use 80 bits, but float80_t will.

The C++ language allows the compiler to use higher precision for 
intermediate floating-point computations whenever it wants.

The way the above is phrased, it could be misunderstood that 
computations with float64_t may never use a 80-bit precision 
floating-point unit, even though that may well likely happen.
This gives a false sense of security to people who write some code that 
would only work with a IEEE754 64-bit floating-point unit.