Velocity Reviews > struct, IEEE-754 and internal representation

# struct, IEEE-754 and internal representation

ej
Guest
Posts: n/a

 11-09-2005

I ran into something today I don't quite understand and I don't know all the
nitty gritty details about how Python stores and handles data internally.
(I think) I understand why, when you type in certain floating point values,
Python doesn't display exactly what you typed (because not all decimal
numbers are exactly representable in binary, and Python shows you the full
precision of what is representable). For example:

>>> 0.9

0.90000000000000002

and

>>> 148.73

148.72999999999999

So, I think I've got a pretty good handle on what the struct module is all
about. Let's take that number, 148.73, and use struct functions to look at
the raw bit pattern of what would be in a 32-bit register using IEEE754
float representation:

>>> hex(unpack('L', pack('f', x))[0])

'0x4314BAE1L'

That is, the four bytes representing this are 0x43, 0x14, 0xBA, 0xE1

Now let's go back the other way, starting with this 32 bit representation,
and turn it back into a float:

>>> unpack('>f', pack('BBBB', 0x43, 0x14, 0xBA, 0xE1))[0]

148.72999572753906

Hmmmm... Close, but I seem to be losing more the I would expect here. I
initially thought I should be able to get back to at least what python
previously displayed: 148.72999999999999

I know there are 23 bits of mantissa in an IEEE-754, with a free '1'...

>>> hex(14872999)

'0xe2f1a7'

Looks like it takes 6 * 4 = 24 bits to represent that as an int....

I am starting to think my expectation is wrong...

If that's true, then I guess I am confused why Python is displaying
148.72999572753906 when you unpack the 4 bytes, implying a lot more
precision that was available in the original 32-bits? Python is doing
64-bit floating point here? I'm obviously not understanding something...
help?

-ej

Robert Kern
Guest
Posts: n/a

 11-09-2005
ej wrote:

> If that's true, then I guess I am confused why Python is displaying
> 148.72999572753906 when you unpack the 4 bytes, implying a lot more
> precision that was available in the original 32-bits? Python is doing
> 64-bit floating point here? I'm obviously not understanding something...
> help?

Yes, Python uses C double precision floats for float objects.

--
Robert Kern
http://www.velocityreviews.com/forums/(E-Mail Removed)

"In the fields of hell where the grass grows high
Are the graves of dreams allowed to die."
-- Richard Harter

Grant Edwards
Guest
Posts: n/a

 11-09-2005
On 2005-11-09, ej <> wrote:

> If that's true, then I guess I am confused why Python is displaying
> 148.72999572753906 when you unpack the 4 bytes, implying a lot more
> precision that was available in the original 32-bits? Python is doing
> 64-bit floating point here?

Yes. C-Python "float" objects are of the C type "double" and
use 64-bit IEEE-754 representation on all the common platforms
I know about.

--
Grant Edwards grante Yow! .. or were you
at driving the PONTIAC that
visi.com HONKED at me in MIAMI last
Tuesday?

jepler@unpythonic.net
Guest
Posts: n/a

 11-09-2005
Use 'd' as the format character for 64-bit double precision numbers with struct.

>>> x = 148.73
>>> unpack("<d", pack("<d", x))[0] == x

True
>>> unpack("<f", pack("<f", x))[0] == x

False

Jeff

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDcohCJd01MZaTXX0RAgEKAJwNYt7Rb/yeaLle4c2XsbIpAoLVXACghpMo
XpcFtakHKmBkf+H4svGrZ5A=
=dw0q
-----END PGP SIGNATURE-----

ej
Guest
Posts: n/a

 11-09-2005
Ah! Well! That explains it. I started to suspect that but (obviously) did
not know that. LOL

Thanks for your prompt reply, Grant.

-ej

 Thread Tools

 Posting Rules You may not post new threads You may not post replies You may not post attachments You may not edit your posts BB code is On Smilies are On [IMG] code is On HTML code is OffTrackbacks are On Pingbacks are On Refbacks are Off Forum Rules

 Similar Threads Thread Thread Starter Forum Replies Last Post Joe Attardi Java 13 03-21-2006 10:39 PM Sathyaish C Programming 5 06-27-2005 10:06 PM jdog1016@gmail.com C++ 7 04-22-2005 11:15 PM Benji Java 2 12-18-2003 05:58 PM Alexander Sourjikov Python 4 10-22-2003 08:22 PM

Advertisments