[Numpy-discussion] byteswap() not doing anything !?

[Todd Miller]

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