![](https://secure.gravatar.com/avatar/6194b135cba546afa82516de1537de49.jpg?s=120&d=mm&r=g)
Hi, Is this a bug?:
I was using na.maximum.reduce(d) to get a "pixelwise" maximum along Z (axis 0). But as seen above it does not get it right. I then tried to reproduce this with some simple arrays, but here it works just fine:
Any hint ? Regards, Sebastian Haase
![](https://secure.gravatar.com/avatar/6194b135cba546afa82516de1537de49.jpg?s=120&d=mm&r=g)
On Tuesday 29 June 2004 05:05 pm, Sebastian Haase wrote:
Hi again, I think the reason that no one responded to this is that it just sounds to unbelievable ... Sorry for the missing piece of information, but 'd' is actually a memmapped array !
Apparently we are using memmap so frequently now that I didn't even think about that - which is good news for everyone, because it means that it works (mostly). I just see that 'byteorder' is 'big' - I'm running this on an Intel Linux PC. Could this be the problem? Please some comments ! Thanks, Sebastian
![](https://secure.gravatar.com/avatar/13d4ef1dbfd985740cdf7c04ce11fe92.jpg?s=120&d=mm&r=g)
I'm in the process of switching to numarray, but I still need typecode(). I notice that, although it's discouraged, the typecode ids have been extended to all new numarray types described in table 4.1 (p. 19) of the manual, except UInt64. That is, the following script: import numarray as Na print "Numarray version: ",Na.__version__ print Na.array([1],'Int8').typecode() print Na.array([1],'UInt8').typecode() print Na.array([1],'Int16').typecode() print Na.array([1],'UInt16').typecode() print Na.array([1],'Int32').typecode() print Na.array([1],'UInt32').typecode() print Na.array([1],'Float32').typecode() print Na.array([1],'Float64').typecode() print Na.array([1],'Complex32').typecode() print Na.array([1],'Complex64').typecode() print Na.array([1],'Bool').typecode() print Na.array([1],'UInt64').typecode() prints: Numarray version: 1.0 1 b s w l u f d F D 1 Traceback (most recent call last): File "<stdin>", line 14, in ? File "/usr/lib/python2.3/site-packages/numarray/numarraycore.py", line 1092, in typecode return _nt.typecode[self._type] KeyError: UInt64 Should this print 'U'? Regards, Phil Austin
![](https://secure.gravatar.com/avatar/faf9400121dca9940496a7473b1d8179.jpg?s=120&d=mm&r=g)
On Sat, 2004-07-03 at 13:10, Philip Austin wrote:
I think it could, but I wouldn't go so far as to say it should. typecode() is there for backward compatibility with Numeric. Since 'U' doesn't work for Numeric, I see no point in adding it to numarray. I'm not sure it would hurt anything other than create the illusion that something which works on numarray will also work on Numeric. If anyone has a good reason to add it, please speak up. Regards, Todd
![](https://secure.gravatar.com/avatar/13d4ef1dbfd985740cdf7c04ce11fe92.jpg?s=120&d=mm&r=g)
Todd Miller writes:
I don't necessarily need typecode, but I couldn't find the inverse of a = array([10], type = 'UInt8') (p. 19) in the manual. That is, I need a method that returns the string representation of a numarray type in a single call (as opposed to the two-step repr(array.type()). This is for code that uses the Boost C++ bindings to numarray. These bindings work via callbacks to python (which eliminates the need to link to the numarray or numeric api). Currently I use typecode() to get an index into a map of types when I need to check that the type of a passed argument is correct: void check_type(boost::python::numeric::array arr, string expected_type){ string actual_type = arr.typecode(); if (actual_type != expected_type) { std::ostringstream stream; stream << "expected Numeric type " << kindstrings[expected_type] << ", found Numeric type " << kindstrings[actual_type] << std::ends; PyErr_SetString(PyExc_TypeError, stream.str().c_str()); throw_error_already_set(); } return; } Unless I'm missing something, without typecode I need a second interpreter call to repr, or I need to import numarray and load all the types into storage for a type object comparison. It's not a showstopper, but since I check every argument in every call, I'd like to avoid this unless absolutely necessary. Regards, Phil
![](https://secure.gravatar.com/avatar/faf9400121dca9940496a7473b1d8179.jpg?s=120&d=mm&r=g)
On Tue, 2004-07-06 at 19:07, Philip Austin wrote:
The behavior of byteswap() has been controversial in the past, at one time implementing exactly the behavior I think you expected. Without giving any guarantee for the future, here's how things work now: byteswap() just swaps the bytes. There's a related method, togglebyteorder(), which inverts the sense of the byteorder: >>> y.byteswap() >>> y.togglebyteorder() >>> y.isbyteswapped() 1 The ability to munge bytes and change the sense of byteorder independently is definitely needed... but you're certainly not the first one to ask this question. There is also (Numeric compatible) byteswapped(), which both swaps and changes sense, but it creates a copy rather than operating in place: >>> x = y.byteswapped() >>> (x is not y) and (x._data is not y._data) 1 Regards, Todd
![](https://secure.gravatar.com/avatar/6194b135cba546afa82516de1537de49.jpg?s=120&d=mm&r=g)
On Tuesday 29 June 2004 05:05 pm, Sebastian Haase wrote:
Hi again, I think the reason that no one responded to this is that it just sounds to unbelievable ... Sorry for the missing piece of information, but 'd' is actually a memmapped array !
Apparently we are using memmap so frequently now that I didn't even think about that - which is good news for everyone, because it means that it works (mostly). I just see that 'byteorder' is 'big' - I'm running this on an Intel Linux PC. Could this be the problem? Please some comments ! Thanks, Sebastian
![](https://secure.gravatar.com/avatar/13d4ef1dbfd985740cdf7c04ce11fe92.jpg?s=120&d=mm&r=g)
I'm in the process of switching to numarray, but I still need typecode(). I notice that, although it's discouraged, the typecode ids have been extended to all new numarray types described in table 4.1 (p. 19) of the manual, except UInt64. That is, the following script: import numarray as Na print "Numarray version: ",Na.__version__ print Na.array([1],'Int8').typecode() print Na.array([1],'UInt8').typecode() print Na.array([1],'Int16').typecode() print Na.array([1],'UInt16').typecode() print Na.array([1],'Int32').typecode() print Na.array([1],'UInt32').typecode() print Na.array([1],'Float32').typecode() print Na.array([1],'Float64').typecode() print Na.array([1],'Complex32').typecode() print Na.array([1],'Complex64').typecode() print Na.array([1],'Bool').typecode() print Na.array([1],'UInt64').typecode() prints: Numarray version: 1.0 1 b s w l u f d F D 1 Traceback (most recent call last): File "<stdin>", line 14, in ? File "/usr/lib/python2.3/site-packages/numarray/numarraycore.py", line 1092, in typecode return _nt.typecode[self._type] KeyError: UInt64 Should this print 'U'? Regards, Phil Austin
![](https://secure.gravatar.com/avatar/faf9400121dca9940496a7473b1d8179.jpg?s=120&d=mm&r=g)
On Sat, 2004-07-03 at 13:10, Philip Austin wrote:
I think it could, but I wouldn't go so far as to say it should. typecode() is there for backward compatibility with Numeric. Since 'U' doesn't work for Numeric, I see no point in adding it to numarray. I'm not sure it would hurt anything other than create the illusion that something which works on numarray will also work on Numeric. If anyone has a good reason to add it, please speak up. Regards, Todd
![](https://secure.gravatar.com/avatar/13d4ef1dbfd985740cdf7c04ce11fe92.jpg?s=120&d=mm&r=g)
Todd Miller writes:
I don't necessarily need typecode, but I couldn't find the inverse of a = array([10], type = 'UInt8') (p. 19) in the manual. That is, I need a method that returns the string representation of a numarray type in a single call (as opposed to the two-step repr(array.type()). This is for code that uses the Boost C++ bindings to numarray. These bindings work via callbacks to python (which eliminates the need to link to the numarray or numeric api). Currently I use typecode() to get an index into a map of types when I need to check that the type of a passed argument is correct: void check_type(boost::python::numeric::array arr, string expected_type){ string actual_type = arr.typecode(); if (actual_type != expected_type) { std::ostringstream stream; stream << "expected Numeric type " << kindstrings[expected_type] << ", found Numeric type " << kindstrings[actual_type] << std::ends; PyErr_SetString(PyExc_TypeError, stream.str().c_str()); throw_error_already_set(); } return; } Unless I'm missing something, without typecode I need a second interpreter call to repr, or I need to import numarray and load all the types into storage for a type object comparison. It's not a showstopper, but since I check every argument in every call, I'd like to avoid this unless absolutely necessary. Regards, Phil
![](https://secure.gravatar.com/avatar/faf9400121dca9940496a7473b1d8179.jpg?s=120&d=mm&r=g)
On Tue, 2004-07-06 at 19:07, Philip Austin wrote:
The behavior of byteswap() has been controversial in the past, at one time implementing exactly the behavior I think you expected. Without giving any guarantee for the future, here's how things work now: byteswap() just swaps the bytes. There's a related method, togglebyteorder(), which inverts the sense of the byteorder: >>> y.byteswap() >>> y.togglebyteorder() >>> y.isbyteswapped() 1 The ability to munge bytes and change the sense of byteorder independently is definitely needed... but you're certainly not the first one to ask this question. There is also (Numeric compatible) byteswapped(), which both swaps and changes sense, but it creates a copy rather than operating in place: >>> x = y.byteswapped() >>> (x is not y) and (x._data is not y._data) 1 Regards, Todd
participants (3)
-
Philip Austin
-
Sebastian Haase
-
Todd Miller