[boost] [endian] Testing floating point interoperability

Subject: [boost] [endian] Testing floating point interoperability
From: Beman Dawes (bdawes_at_[hidden])
Date: 2015-03-18 09:24:17

On Fri, Jan 30, 2015 at 5:25 AM, Paul A. Bristow
<pbristow_at_[hidden]> wrote:
>
>
>> * Anything else that you can think of to improve FP support.
>
> The proof of the pudding is in the eating.
>
> I'd suggest that *testing interoperability* is the key precaution that you should advise.

I'm starting to write a caution to go in the release, and will make that point.

A new test, "floating_point_test", has been added to the endian test
suite. It will focus on interoperability. (I know that you are talking
about users testing their application needs, but I want to test
Boost.Endian to be able to warn users of areas where there are known
issues.)

> It should obviously be between all possible combinations of processor hardware types.

It isn't just processor types.
std::numeric_limits<float>::signaling_NaN() representation is
0x7fc00001 for Microsoft/Dinkumware, but is 0x7fa00000 for gcc and
clang:-(

> The test should include a range of floating-point values from min to max,
> and include NaN and infinity unless it is certain that they will never occur.

To get started, floating_point_test.cpp is testing float and double:

  numeric_limits<>::min()
  numeric_limits<>::max()
  numeric_limits<>::lowest()
  numeric_limits<>::epsilon()
  numeric_limits<>::round_error()
  numeric_limits<>::infinity()
  -numeric_limits<>::infinity()
  numeric_limits<>::quiet_NaN()
  numeric_limits<>::denorm_min()
  0.0
  -0.0
  1.0
  -1.0
  native uint32_t 0x12345678U as a float
  native uint64_t 0x0123456789abcdefULL as a double
  pi<>()

Are there other specific values worth testing?>  (Unless very special
precautions are taken, then infinity and NaN are like to rear their
ugly heads
> at some time - probably when you least want to see them!)
>
> It must be possible to 'round-trip' all floating-point values.

That's one of the tests performed on each value.

> 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.

Thanks,

--Beman