Mailing List Archive: Python: Python

Extracting bit fields from an IEEE-784 float

Index | Next | Previous | View Threaded

steve+comp.lang.python at pearwood

Jul 29, 2012, 5:44 PM

Post #1 of 12 (845 views)
Permalink

Extracting bit fields from an IEEE-784 float

I wish to extract the bit fields from a Python float, call it x. First I
cast the float to 8-bytes:

s = struct.pack('=d', x)
i = struct.unpack('=q', s)[0]

Then I extract the bit fields from the int, e.g. to grab the sign bit:

(i & 0x8000000000000000) >> 63

Questions:

1) Are there any known implementations or platforms where Python floats
are not C doubles? If so, what are they?

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?

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

Thanks in advance,

Steven
--
http://mail.python.org/mailman/listinfo/python-list

dan at tombstonezero

Jul 29, 2012, 6:08 PM

Post #2 of 12 (820 views)
Permalink

Re: Extracting bit fields from an IEEE-784 float [In reply to]

On 2012-07-30 at 00:44:04 +0000,
Steven D'Aprano <steve+comp.lang.python [at] pearwood> wrote:

> I wish to extract the bit fields from a Python float, call it x. First I
> cast the float to 8-bytes:
>
> s = struct.pack('=d', x)
> i = struct.unpack('=q', s)[0]
>
> Then I extract the bit fields from the int, e.g. to grab the sign bit:
>
> (i & 0x8000000000000000) >> 63

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

No, but perhaps this would be clearer:

import math
sign = math.copysign(1.0, x)

There are solutions that use math.frexp, too, but IMO they're more
obtuse.

HTH,
Dan
--
http://mail.python.org/mailman/listinfo/python-list

tjreedy at udel

Jul 29, 2012, 10:17 PM

Post #3 of 12 (817 views)
Permalink

Re: Extracting bit fields from an IEEE-784 float [In reply to]

On 7/29/2012 8:44 PM, Steven D'Aprano wrote:
> I wish to extract the bit fields from a Python float, call it x. First I
> cast the float to 8-bytes:
>
> s = struct.pack('=d', x)
> i = struct.unpack('=q', s)[0]
>
> Then I extract the bit fields from the int, e.g. to grab the sign bit:
>
> (i & 0x8000000000000000) >> 63
>
>
> Questions:
>
> 1) Are there any known implementations or platforms where Python floats
> are not C doubles? If so, what are they?

CPython floats are C doubles, which should be IEEE doubles. Other
implementations have a different to probably the same thing.

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

The math modules functions to disassemble floats will not care.

--
Terry Jan Reedy

--
http://mail.python.org/mailman/listinfo/python-list

ulrich.eckhardt at dominolaser

Jul 29, 2012, 11:42 PM

Post #4 of 12 (822 views)
Permalink

Re: Extracting bit fields from an IEEE-784 float [In reply to]

Am 30.07.2012 02:44, schrieb Steven D'Aprano:
> I wish to extract the bit fields from a Python float, call it x. First I
> cast the float to 8-bytes:
>
> s = struct.pack('=d', x)
> i = struct.unpack('=q', s)[0]
>
> Then I extract the bit fields from the int, e.g. to grab the sign bit:
>
> (i & 0x8000000000000000) >> 63
>
>
> Questions:
>
> 1) Are there any known implementations or platforms where Python floats
> are not C doubles? If so, what are they?

The struct docs refer to C's double type, so it depends on that type
probably. However, regardless of C's double type, the same docs refer to
the IEEE form when packed into a byte array. Is it just the
representation you are after or some specific behaviour?

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

Yes, the code is fine. If you have doubts, I have a big-endian system at
home (Linux/PowerPC) where I could run tests.

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

Python docs refer to IEEE-754, not 784? Typo?

Uli

--
http://mail.python.org/mailman/listinfo/python-list

dickinsm at gmail

Jul 30, 2012, 12:57 AM

Post #5 of 12 (816 views)
Permalink

Re: Extracting bit fields from an IEEE-784 float [In reply to]

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
--
http://mail.python.org/mailman/listinfo/python-list

invalid at invalid

Jul 30, 2012, 7:16 AM

Post #6 of 12 (814 views)
Permalink

Re: Extracting bit fields from an IEEE-784 float [In reply to]

On 2012-07-30, Steven D'Aprano <steve+comp.lang.python [at] pearwood> wrote:

> 1) Are there any known implementations or platforms where Python floats
> are not C doubles? If so, what are they?

And the question you didn't ask: are there any platforms where a C
double isn't IEEE-754?

The last ones I worked on that where the FP format wasn't IEEE were
the DEC VAX and TI's line if 32-bit floating-point DSPs. I don't
think Python runs on the latter, but it might on the former.

--
Grant Edwards grant.b.edwards Yow! I was born in a
at Hostess Cupcake factory
gmail.com before the sexual
revolution!
--
http://mail.python.org/mailman/listinfo/python-list

roy at panix

Jul 30, 2012, 7:28 AM

Post #7 of 12 (819 views)
Permalink

Re: Extracting bit fields from an IEEE-784 float [In reply to]

In article <jv64v5$g2n$2 [at] reader1>,
Grant Edwards <invalid [at] invalid> wrote:

> The last ones I worked on that where the FP format wasn't IEEE were
> the DEC VAX

According to http://en.wikipedia.org/wiki/Vax#History, the last VAX was
produced 7 years ago. I'm sure there's still more than a few chugging
away in corporate data centers and manufacturing floors, but as an
architecture, it's pretty much a dead parrot.

IEEE floating point is as near to a universal standard as it gets in the
computer world. About the only thing that has it beat for market
penetration and longevity are 2's complement integers and 8-bit bytes.
--
http://mail.python.org/mailman/listinfo/python-list

breamoreboy at yahoo

Jul 30, 2012, 7:50 AM

Post #8 of 12 (814 views)
Permalink

Re: Extracting bit fields from an IEEE-784 float [In reply to]

On 30/07/2012 15:16, Grant Edwards wrote:
> On 2012-07-30, Steven D'Aprano <steve+comp.lang.python [at] pearwood> wrote:
>
>> 1) Are there any known implementations or platforms where Python floats
>> are not C doubles? If so, what are they?
>
> And the question you didn't ask: are there any platforms where a C
> double isn't IEEE-754?
>
> The last ones I worked on that where the FP format wasn't IEEE were
> the DEC VAX and TI's line if 32-bit floating-point DSPs. I don't
> think Python runs on the latter, but it might on the former.
>

Support for Python on VMS has been dropped for v3.3 see
http://bugs.python.org/issue11918

--
Cheers.

Mark Lawrence.

--
http://mail.python.org/mailman/listinfo/python-list

invalid at invalid

Jul 30, 2012, 8:47 AM

Post #9 of 12 (815 views)
Permalink

Re: Extracting bit fields from an IEEE-784 float [In reply to]

On 2012-07-30, Mark Lawrence <breamoreboy [at] yahoo> wrote:
> On 30/07/2012 15:16, Grant Edwards wrote:
>> On 2012-07-30, Steven D'Aprano <steve+comp.lang.python [at] pearwood> wrote:
>>
>>> 1) Are there any known implementations or platforms where Python floats
>>> are not C doubles? If so, what are they?
>>
>> And the question you didn't ask: are there any platforms where a C
>> double isn't IEEE-754?
>>
>> The last ones I worked on that where the FP format wasn't IEEE were
>> the DEC VAX and TI's line if 32-bit floating-point DSPs. I don't
>> think Python runs on the latter, but it might on the former.
>>
>
> Support for Python on VMS has been dropped for v3.3 see
> http://bugs.python.org/issue11918

I imagine that VAXes running Unix went extinct in the wild long before
VAXes running VMS.

--
Grant Edwards grant.b.edwards Yow! Did YOU find a
at DIGITAL WATCH in YOUR box
gmail.com of VELVEETA?
--
http://mail.python.org/mailman/listinfo/python-list

dickinsm at gmail

Jul 30, 2012, 9:14 AM

Post #10 of 12 (823 views)
Permalink

Re: Extracting bit fields from an IEEE-784 float [In reply to]

On Monday, July 30, 2012 3:16:05 PM UTC+1, Grant Edwards wrote:
> The last ones I worked on that where the FP format wasn't IEEE were
>
> the DEC VAX and TI's line if 32-bit floating-point DSPs. I don't
>
> think Python runs on the latter, but it might on the former.

For current hardware, there's also IBM big iron: the IBM System z10 apparently has hardware support for IBM's hexadecimal floating-point format in addition to IEEE 754 binary *and* decimal floating-point. But IIUC, a typical Linux installation on one of these machines uses the IEEE 754 stuff, not the hexadecimal bits. So unlikely to be an issue for Python.

--
Mark
--
http://mail.python.org/mailman/listinfo/python-list

drsalists at gmail

Jul 30, 2012, 9:52 AM

Post #11 of 12 (817 views)
Permalink

Re: Extracting bit fields from an IEEE-784 float [In reply to]

On Mon, Jul 30, 2012 at 12:44 AM, Steven D'Aprano <
steve+comp.lang.python [at] pearwood> wrote:

> I wish to extract the bit fields from a Python float, call it x. First I
> cast the float to 8-bytes:
>
> s = struct.pack('=d', x)
> i = struct.unpack('=q', s)[0]
>
> Then I extract the bit fields from the int, e.g. to grab the sign bit:
>
> (i & 0x8000000000000000) >> 63
>
>
> Questions:
>
> 1) Are there any known implementations or platforms where Python floats
> are not C doubles? If so, what are they?
>
Last I heard, DEC Alpha chips did not use IEEE floating point.

> 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?
>
> 3) Any other problems with the way I am doing this?
>
It gives me the heebie jeebies. Why go to all the trouble and incur the
lack of portability to esoteric platforms, when you can just use arithmetic
expressions? It's fancy, and it'll probably almost always work, but it's
probably not so wise.

roy at panix

Jul 30, 2012, 1:50 PM

Post #12 of 12 (820 views)
Permalink

Re: Extracting bit fields from an IEEE-784 float [In reply to]

In article <jv6ab7$jne$1 [at] reader1>,
Grant Edwards <invalid [at] invalid> wrote:

> I imagine that VAXes running Unix went extinct in the wild long before
> VAXes running VMS.

Of course they did. VMS is all about vendor lock-in. People who
continue to run VAXen don't do so because they're wedded to the
hardware. They do so because they're wedded to some specific VMS
application (and the business processes which depend on it).
--
http://mail.python.org/mailman/listinfo/python-list

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads