Numerical Python

Sebastian Haase wrote:

>>>>xx = na.array((1,2,3))
>>>>xx
>>>>        
>>>>
>array([1, 2, 3])
>  
>
>>>>xx.byteswap()
>>>>xx
>>>>        
>>>>
>array([1, 2, 3])
>  
>
>>>>xx.type()
>>>>        
>>>>
>Int32
>
>Hi all,
>I was reading the documentation for array 0.4
>but I get the about results.
>How do I get the bytes swaped like it says in the manual:
>
>numbyteswap()
>   The byteswap method performs a byte swapping 
>   operation on all the elements in the array, 
>   working inplace (i.e. it returns None). 
>   >>> 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.

>
>
>Thanks,
>Sebastian
>
>  
>
Todd

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 wa=
nt.

This is already decided?. Because I like the present behaviour.

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 representati=
on
of the data in array independently of which architecture you have written
the array.

If you byteswap() an array, the _byteorder property is also changed, so y=
ou
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 wo=
uld
be the expected behaviour of the future .byteswap(), ._byteswap() and
=2E_byteorder?

Thanks,

--=20
Francesc Alted

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

A Dijous 20 Febrer 2003 15:36, Todd Miller va escriure:
>
> The current "plan" is that byteswap() and _byteswap() will both behave
> as _byteswap() does now;  i.e., they will be Numeric compatible synonym=
s.
>
> 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.

Well, I've been doing some tests, and I think I'll be able to produce a
version of my code that will be compatible with numarray 0.4 and future
versions (I'm just no using byteswap() at all).

However, I've detected a side effect on this change: copy() method is
broken now in CVS:

In [131]: a=3Dnumarray.array([1,2])

In [132]: a.togglebyteorder()

In [133]: b=3Da.copy()

In [134]: a
Out[134]: array([16777216, 33554432])

In [135]: b
Out[135]: array([1, 2])

In [136]: a._byteorder
Out[136]: 'big'

In [137]: b._byteorder
Out[137]: 'big'

so, you don't get a well-behaved copy of original array a in b

I think the next patch should cure it:

--- numarray.py Tue Feb 18 16:35:16 2003
+++ /usr/local/lib/python2.2/site-packages/numarray/numarray.py Thu Feb 2=
0=20
19:36:07 2003
@@ -609,6 +609,7 @@
         c._type =3D self._type
         if self.isbyteswapped():
             c.byteswap()
+           c.togglebyteorder()
         return c


--=20
Francesc Alted

Francesc Alted wrote:

>A Dijous 20 Febrer 2003 15:36, Todd Miller va escriure:
>  
>
>>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.
>>    
>>
>
>Well, I've been doing some tests, and I think I'll be able to produce a
>version of my code that will be compatible with numarray 0.4 and future
>versions (I'm just no using byteswap() at all).
>
>However, I've detected a side effect on this change: copy() method is
>broken now in CVS:
>
>In [131]: a=numarray.array([1,2])
>
>In [132]: a.togglebyteorder()
>
>In [133]: b=a.copy()
>
>In [134]: a
>Out[134]: array([16777216, 33554432])
>
>In [135]: b
>Out[135]: array([1, 2])
>
>In [136]: a._byteorder
>Out[136]: 'big'
>
>In [137]: b._byteorder
>Out[137]: 'big'
>
>so, you don't get a well-behaved copy of original array a in b
>  
>
Doh!

>I think the next patch should cure it:
>
>--- numarray.py Tue Feb 18 16:35:16 2003
>+++ /usr/local/lib/python2.2/site-packages/numarray/numarray.py Thu Feb 20 
>19:36:07 2003
>@@ -609,6 +609,7 @@
>         c._type = self._type
>         if self.isbyteswapped():
>             c.byteswap()
>+           c.togglebyteorder()
>         return c
>  
>
Thanks!

Todd