[Numpy-discussion] byteswap() not doing anything !?
Todd Miller
jmiller at stsci.edu
Thu Feb 20 06:20:13 EST 2003
Francesc Alted wrote:
>A Dimecres 19 Febrer 2003 21:42, Todd Miller va escriure:
>
>
>>> >>> print a
>>>
>>> [1 2 3]
>>>
>>> >>> a.byteswap()
>>> >>> print a
>>>
>>> [16777216 33554432 50331648]
>>>
>>>
>>This is a known bug/incompatability. The behavior will be changed for
>>the next release of numarray. Right now, _byteswap() does what you want.
>>
>>
>
>This is already decided?. Because I like the present behaviour.
>
It's already in CVS. Let me know what you think about the stuff below.
>
>At first, I've found this behaviour a bit strange, but after get used to it,
>I admit that it is elegant because you can always see a sane representation
>of the data in array independently of which architecture you have written
>the array.
>
>
I think byteswap() came to be the way it is in numarray-0.4 as a result
of my experiences with cross-platform pickling. It made sense to me at
the time. However, it is definitely a new point of confusion, and not
backwards compatible with Numeric, so I think the numarray-0.4
byteswap() behavior was a mistake.
>If you byteswap() an array, the _byteorder property is also changed, so you
>can check if your array is bytswapped or not just by writing:
>
>if a._byteorder <> sys.byteorder:
> print "a is byteswapped"
>else:
> print "a is not byteswapped"
>
>And, as you said before, you can always call _byteswap() if you *really*
>want to *only* byteswap the array.
>
>PyTables already makes use of byteswap() as it is now, and that's nice
>because an array can be restored from disk safely by just looking at the
>byte order on disk and then setting properly the ._byteorder attribute.
>That's all! This allows also to work seamlessly with objects coming from a
>mixture of big-endian and low-endian machines.
>
>But, anyway, if you plan to do the change, may you please tell us what would
>be the expected behaviour of the future .byteswap(), ._byteswap() and
>._byteorder?
>
>
The current "plan" is that byteswap() and _byteswap() will both behave
as _byteswap() does now; i.e., they will be Numeric compatible synonyms.
An explict (extra) call to togglebyteorder() will then produce the
current behavior. The meaning of _byteorder will be unchanged.
Please let me know if you see any snags in the plan.
>Thanks,
>
>
>
More information about the NumPy-Discussion
mailing list