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
>> * 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
> 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
> 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:
native uint32_t 0x12345678U as a float
native uint64_t 0x0123456789abcdefULL as a double
Are there other specific values worth testing?> (Unless very special
precautions are taken, then infinity and NaN are like to rear their
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk