Re: [boost] [Review] Boost.Endian mini-review

Subject: Re: [boost] [Review] Boost.Endian mini-review
From: Cliff Green (cliffg_at_[hidden])
Date: 2015-01-30 12:17:21

>> ... I'd suggest that *testing interoperability* is the key precaution 
>> that you should advise.

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

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.

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

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

Thanks, Paul.

I was going to start another discussion thread asking for suggestions from 
some of the experts (or at least people more expert than me) dealing with 
floating point endian swapping, but I'll wait to see if we get responses on 
this thread.

I'm still not sure what to suggest to Beman for the Endian library wrt to 
float and double API's, specially as this library could or should be the
basis for a standardization proposal. Integers are completely safe and 
well-defined for swapping - all bit patterns form valid integers and
swapping bytes never result in "special" hardware processing. This is not 
the case for floating point. I have definitely seen "in-place" floating
point swapping used extensively without problems, and have definitely seen 
other functionality have problems (my previously mentioned "returning 
swapped floating point by value causes silent changing of bits" 
normalization issue). And, of course, there's the additional problem of 
binary floating point interoperability between IEEE-754 processors and those 
that are not.

Boost.Endian does not (and should not) define wire protocols. It provides 
functionality and API's for translating to and from wire protocols. But with 
floating point, any kind of standardization will have to not only define the 
API, but some form of wire protocol. Then the Endian functions become 
something like:

opaque_binary_type native_to_interoperate_fp(float x); // opaque_binary_type 
stores fp elements - sign, mantissa, exponent, etc
opaque_binary_type native_to_interoperate_fp(double x);
float fp_interoperate_to_native(opaque_binary_type x);
double fp_interoperate_to_native(opaque_binary_type x);

Unless there is something I'm missing.

Here's my initial (and incomplete) answers to Beman's queries to my e-mail:

* Recommendations for changes to the library interface for floating point. 
For example, eliminating the return by value functions.

Eliminating the floating point "return by value" function should definitely 
should be performed. Whether the "in place" swap should be removed I'd like 
to hear from others more expert. Specifically, with common hardware 
architectures, what are the operations that will invoke floating point 
normalization (and other "bit changing" functionality)? What is safe to 
perform?

* Test cases that probe for errors you have seen in the past or that you 
worry about.

Paul gave a pretty good summary in his reply about the general testing 
strategy. I don't have specific test cases, so maybe others more expert can 
chime in with specific test logic.

* Suggestions about warnings or other changes you would like to see made to 
the docs.

Definitely some kind of summary of these warnings and "brittleness" should 
be included in the docs. Probably no more than a paragraph or two of general 
"watch out". I'll be happy to help. If we get responses from people more 
expert at the hardware instruction level (i.e. what is really going on 
"under the covers") summaries of those discussions can be included.

* Should the implementation refuse to compile (i.e. #error) on no-IEEE 754 
systems? If so, how to implement?

Not sure - if we're not defining a floating point wire protocol, then it 
doesn't matter what the underlying bit pattern of a swapped floating value 
is. It's up to the application to know what's "on the wire" and whether it 
can be safely unswapped back to native float or double (just like it's up 
the application to know the underlying integer wire protocol).

* Anything else that you can think of to improve FP support.

Hopefully this is a good start and others will chime in and you'll have a 
useful and safe (even if not 100% complete) initial API and implementation.

Cliff

---
This email has been checked for viruses by Avast antivirus software.
http://www.avast.com