Extracting bit fields from an IEEE-784 float

[Mark Dickinson]

On Monday, July 30, 2012 1:44:04 AM UTC+1, Steven D'Aprano wrote:
> 1) Are there any known implementations or platforms where Python floats 
> are not C doubles? If so, what are they?

Well, IronPython is presumably using .NET Doubles, while Jython will be using Java Doubles---in either case, that's specified to be the IEEE 754 binary64 type.

For CPython, and I guess PyPy too, we're using C doubles, which in theory are in whatever format the platform provides, but in practice are always IEEE 754 binary64 again.

So you're pretty safe assuming IEEE 754 binary64 format.  If you ever meet a current Python running on a system that *doesn't* use IEEE 754 for its C doubles, please let me know---there are a lot of interesting questions that would come up in that case.   

> 2) If the platform byte-order is reversed, do I need to take any special 
> 
> action? I don't think I do, because even though the float is reversed, so 
> 
> will be the bit mask. Is this correct?

True; on almost all current platforms, the endianness of int types matches the endianness of float types.    But to be safe, why not use '<d' and '<q' in your formats instead of '=d' and '=q'?  That way you don't have to worry.

> 3) Any other problems with the way I am doing this?

You might consider whether you want to use '<q' or '<Q' --- i.e. whether you want a signed integer or an unsigned integer to be returned.  For grabbing bits, '<Q' seems a bit cleaner, while '<q' has the nice property that you can tell the sign of the original double by looking at the sign of the integer.

-- 
Mark