-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Steven Watanabe Sent: 18 March 2015 15:20 To: boost@lists.boost.org Subject: Re: [boost] [endian] Testing floating point interoperability

AMDG

On 03/18/2015 07:24 AM, Beman Dawes wrote:

...

On Fri, Jan 30, 2015 at 5:25 AM, Paul A. Bristow wrote:

...

You can't test all possible values (except for 32-bit float - 64-bit double takes about 50 years at current processor speeds ;-) but you can chose values (floating-point bit patterns) at random for a test lasting some minutes or even hours.

Could you provide the random number generation and otherwise help with this? I've only ever used integer RNGs.

Since you want to test random bit patterns, the easiest way is to generate a 64-bit integer and memcpy it to a double.

I'm not sure if it will prove realistic to test all the possible NaN patterns provided by IEEE floating-point layout? I would expect only those 'funny numbers' in std::numeric_limits to work numeric_limits<>::infinity() -numeric_limits<>::infinity() numeric_limits<>::quiet_NaN() perhaps (despite its meaninglessness) even -numeric_limits<>::quiet_NaN() There was some discussion about removing signaling_NaN std::numeric_limits<float>::signaling_NaN() representation is 0x7fc00001 for Microsoft/Dinkumware, but is 0x7fa00000 for gcc and clang:-( I would simply accept and document that signaling_NaN won't work (unless it does ;-)? But if all of the tests prove to work, then fine. If not, then in our round-trip testing John and I just tested for 'funny' with #include template <class T> bool isfinite(T z); // Neither infinity nor NaN. template <class T> bool isinf(T t); // Infinity (+ or -). template <class T> bool isnan(T t); // NaN. and choose another value if !isfinite. HTH Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830

[Beman Dawes]

An exhaustive return-by-value round-trip test of all 4 billion possible bit patterns for float (but not double) has been run on Windows with the GCC and Microsoft compilers. For both compilers in release mode, and for GCC in debug mode, all bit patterns pass. But for Microsoft in debug mode, certain bit patterns do not round-trip correctly. For example, 7f810000 becomes 7fc10000. (Those are little endian representations).

I'll file a bug if you can give me a self-contained repro. Just one offending bit pattern is fine. Ideally, a repro that doesn't drag in Boost would be the easiest for the compiler team to investigate (i.e. if you can reduce it all the way down to standalone functions). STL

On Fri, Mar 20, 2015 at 11:43 AM, Peter Dimov wrote:

Beman Dawes wrote:

...

The most conservative approach is to remove the return-by-value reverse functions, and note in the docs that only in-place reverse is available for FP. That will give us more time to determine if return-by-value endianness reverse is valid for floating point.

Even if everything round-trips correctly on all compilers we care about, returning "wrong endianness" by value is not standard conforming for any type, not just float. int, for instance, is allowed to have padding bits and trap representations, or to not preserve the sign bit of negative zero.

Understood. While that's a particular concern for floating point types, you are correct that it also applies to integer types even though two's complement integers have become ubiquitous. See my reply below to Rob Stewart for the impact on a 1.58.0 release. Thanks, --Beman

On Fri, Mar 20, 2015 at 1:50 PM, Paul A. Bristow wrote:

...

-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Beman Dawes Sent: 20 March 2015 13:40 To: Boost Developers List Subject: Re: [boost] [endian] Testing floating point interoperability

An exhaustive return-by-value round-trip test of all 4 billion possible bit patterns for float (but not double) has been run on Windows with the GCC and Microsoft compilers.

For both compilers in release mode, and for GCC in debug mode, all bit patterns pass.

But for Microsoft in debug mode, certain bit patterns do not round-trip correctly. For example, 7f810000 becomes 7fc10000. (Those are little endian representations).

So what should Boost.Endian do? There is less than two weeks left before 1.58.0 ships, and even if this turns out to be a bug in the Microsoft compiler, it is likely to cause user problems.

The most conservative approach is to remove the return-by-value reverse functions, and note in the docs that only in-place reverse is available for FP. That will give us more time to determine if return-by-value endianness reverse is valid for floating point.

Opinions?

I'm not sure.

This looks like a NaN?

As I said before, I'd explicitly not make promises for any NaN except

std::numeric_limits<>::quiet_NaN

(not even the deprecated signalling_NaN)

Anyone using another NaN is likely to be not portable and not expecting Boost to be portable anyway?

But Peter Dimov's objection may be more significant.

+1 --Beman

On Fri, Mar 20, 2015 at 4:47 PM, Rob Stewart wrote:

On March 20, 2015 9:40:22 AM EDT, Beman Dawes wrote:

...

But for Microsoft in debug mode, certain bit patterns do not round-trip correctly. For example, 7f810000 becomes 7fc10000. (Those are little endian representations).

So what should Boost.Endian do? There is less than two weeks left before 1.58.0 ships, and even if this turns out to be a bug in the Microsoft compiler, it is likely to cause user problems.

The most conservative approach is to remove the return-by-value reverse functions, and note in the docs that only in-place reverse is available for FP. That will give us more time to determine if return-by-value endianness reverse is valid for floating point.

Until you have a good handle on the issue, you should not release the functionality as stable and vetted.

Understood. That's been uppermost in my mind.

You might just use a macro to enable those functions as experimental.

I'm going to remove all return-by-value functions, including for integers, and there isn't time to do that for 1.58.0. So Boost.Endian will have to wait for 1.59.0. Sigh... Thanks, --Beman