Using 'd' rather than 'f' doesn't fix the problem...
Python 2.3.4 (#1, Jan 9 2007, 16:40:09)
[GCC 3.4.6 20060404 (Red Hat 3.4.6-3)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import struct
>>> struct.pack('d', -0.0)
'\x00\x00\x00\x00\x00\x00\x00\x80' <-- Correct signbit
>>> struct.pack('>d', -0.0)
'\x00\x00\x00\x00\x00\x00\x00\x00' <-- No signbit. Unpacks to 0.0
>>> struct.pack('<d', -0.0)
'\x00\x00\x00\x00\x00\x00\x00\x00' <-- No signbit.
>>>
In python 2.6 it works fine. -0.0 packs to
'\x00\x00\x00\x00\x00\x00\x00\x80' or '\x80\x00...' as it should.
I'm assuming it's a bug that was fixed somewhere in between?
On Tue, Sep 29, 2009 at 4:39 PM, Robert Kern <robert.k...@gmail.com> wrote:
> On Tue, Sep 29, 2009 at 16:37, Joe Kington <jking...@wisc.edu> wrote:
> > I know it's a bit pointless profiling these, but just so I can avoid
> doing
> > real work for a bit...
> >
> > In [1]: import sys, struct, math
> >
> > In [2]: def comp_struct(x):
> > ...: # Get the first or last byte, depending on endianness
> > ...: # (using '>f' or '<f' loses the signbit for -0.0 in older
> > python's)
>
> Did you try 'd'? I wonder if the extra conversion step from a C double
> to a C float is causing this issue.
>
> --
> Robert Kern
>
> "I have come to believe that the whole world is an enigma, a harmless
> enigma that is made terrible by our own mad attempt to interpret it as
> though it had an underlying truth."
> -- Umberto Eco
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
