Hi, Is this a bug?:
# (import numarray as na ; 'd' is a 3 dimensional array) d.type() Float32 d[80, 136, 122] 80.3997039795 na.maximum.reduce(d[:,136, 122]) 85.8426361084 na.maximum.reduce(d) [136, 122] 37.3658103943
na.maximum.reduce(d,0)[136, 122] 37.3658103943 na.maximum.reduce(d,1)[136, 122] Traceback (most recent call last): File "<input>", line 1, in ? IndexError: Index out of range
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:
a = na.arange(4*4*4) a.shape=(4,4,4) na.maximum.reduce(a) [[48 49 50 51] [52 53 54 55] [56 57 58 59] [60 61 62 63]] a = na.arange(4*4*4).astype(na.Float32) a.shape=(4,4,4) na.maximum.reduce(a) [[ 48. 49. 50. 51.] [ 52. 53. 54. 55.] [ 56. 57. 58. 59.] [ 60. 61. 62. 63.]]
Any hint ? Regards, Sebastian Haase
On Tuesday 29 June 2004 05:05 pm, Sebastian Haase wrote:
Hi,
Is this a bug?:
# (import numarray as na ; 'd' is a 3 dimensional array) d.type()
Float32
d[80, 136, 122]
80.3997039795
na.maximum.reduce(d[:,136, 122])
85.8426361084
na.maximum.reduce(d) [136, 122]
37.3658103943
na.maximum.reduce(d,0)[136, 122]
37.3658103943
na.maximum.reduce(d,1)[136, 122]
Traceback (most recent call last): File "<input>", line 1, in ? IndexError: Index out of range
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:
a = na.arange(4*4*4) a.shape=(4,4,4) na.maximum.reduce(a)
[[48 49 50 51] [52 53 54 55] [56 57 58 59] [60 61 62 63]]
a = na.arange(4*4*4).astype(na.Float32) a.shape=(4,4,4) na.maximum.reduce(a)
[[ 48. 49. 50. 51.] [ 52. 53. 54. 55.] [ 56. 57. 58. 59.] [ 60. 61. 62. 63.]]
Any hint ?
Regards, Sebastian Haase
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 !
d.info() class: <class 'numarray.numarraycore.NumArray'> shape: (80, 150, 150) strides: (90000, 600, 4) byteoffset: 0 bytestride: 4 itemsize: 4 aligned: 1 contiguous: 1 data: <MemmapSlice of length:7290000 readonly> byteorder: big byteswap: 1 type: Float32 dd = d.copy() na.maximum.reduce(dd[:,136, 122]) 85.8426361084 na.maximum.reduce(dd)[136, 122] 85.8426361084
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
On Fri, 2004-07-02 at 11:27, Sebastian Haase wrote:
On Tuesday 29 June 2004 05:05 pm, Sebastian Haase wrote:
Hi,
Is this a bug?:
# (import numarray as na ; 'd' is a 3 dimensional array) d.type()
Float32
d[80, 136, 122]
80.3997039795
na.maximum.reduce(d[:,136, 122])
85.8426361084
na.maximum.reduce(d) [136, 122]
37.3658103943
na.maximum.reduce(d,0)[136, 122]
37.3658103943
na.maximum.reduce(d,1)[136, 122]
Traceback (most recent call last): File "<input>", line 1, in ? IndexError: Index out of range
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:
a = na.arange(4*4*4) a.shape=(4,4,4) na.maximum.reduce(a)
[[48 49 50 51] [52 53 54 55] [56 57 58 59] [60 61 62 63]]
a = na.arange(4*4*4).astype(na.Float32) a.shape=(4,4,4) na.maximum.reduce(a)
[[ 48. 49. 50. 51.] [ 52. 53. 54. 55.] [ 56. 57. 58. 59.] [ 60. 61. 62. 63.]]
Any hint ?
Regards, Sebastian Haase
Hi again, I think the reason that no one responded to this is that it just sounds to unbelievable ...
This just slipped through the cracks for me.
Sorry for the missing piece of information, but 'd' is actually a memmapped array !
d.info() class: <class 'numarray.numarraycore.NumArray'> shape: (80, 150, 150) strides: (90000, 600, 4) byteoffset: 0 bytestride: 4 itemsize: 4 aligned: 1 contiguous: 1 data: <MemmapSlice of length:7290000 readonly> byteorder: big byteswap: 1 type: Float32 dd = d.copy() na.maximum.reduce(dd[:,136, 122]) 85.8426361084 na.maximum.reduce(dd)[136, 122] 85.8426361084
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?
I think byteorder is a good guess at this point. What version of Python and numarray are you using? Regards, Todd
On Friday 02 July 2004 09:02 am, Todd Miller wrote:
On Fri, 2004-07-02 at 11:27, Sebastian Haase wrote:
On Tuesday 29 June 2004 05:05 pm, Sebastian Haase wrote:
Hi,
Is this a bug?:
# (import numarray as na ; 'd' is a 3 dimensional array) d.type()
Float32
d[80, 136, 122]
80.3997039795
na.maximum.reduce(d[:,136, 122])
85.8426361084
na.maximum.reduce(d) [136, 122]
37.3658103943
na.maximum.reduce(d,0)[136, 122]
37.3658103943
na.maximum.reduce(d,1)[136, 122]
Traceback (most recent call last): File "<input>", line 1, in ? IndexError: Index out of range
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:
a = na.arange(4*4*4) a.shape=(4,4,4) na.maximum.reduce(a)
[[48 49 50 51] [52 53 54 55] [56 57 58 59] [60 61 62 63]]
a = na.arange(4*4*4).astype(na.Float32) a.shape=(4,4,4) na.maximum.reduce(a)
[[ 48. 49. 50. 51.] [ 52. 53. 54. 55.] [ 56. 57. 58. 59.] [ 60. 61. 62. 63.]]
Any hint ?
Regards, Sebastian Haase
Hi again, I think the reason that no one responded to this is that it just sounds to unbelievable ...
This just slipped through the cracks for me.
Sorry for the missing piece of information, but 'd' is actually a memmapped array !
d.info()
class: <class 'numarray.numarraycore.NumArray'> shape: (80, 150, 150) strides: (90000, 600, 4) byteoffset: 0 bytestride: 4 itemsize: 4 aligned: 1 contiguous: 1 data: <MemmapSlice of length:7290000 readonly> byteorder: big byteswap: 1 type: Float32
dd = d.copy() na.maximum.reduce(dd[:,136, 122])
85.8426361084
na.maximum.reduce(dd)[136, 122]
85.8426361084
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?
I think byteorder is a good guess at this point. What version of Python and numarray are you using?
Python 2.2.1 (#1, Feb 28 2004, 00:52:10) [GCC 2.95.4 20011002 (Debian prerelease)] on linux2 numarray 0.9 - from CVS on 2004-05-13. Regards, Sebastian Haase
On Fri, 2004-07-02 at 13:45, Sebastian Haase wrote:
On Friday 02 July 2004 09:02 am, Todd Miller wrote:
On Fri, 2004-07-02 at 11:27, Sebastian Haase wrote:
On Tuesday 29 June 2004 05:05 pm, Sebastian Haase wrote:
Hi,
Is this a bug?:
> # (import numarray as na ; 'd' is a 3 dimensional array) > d.type()
Float32
> d[80, 136, 122]
80.3997039795
> na.maximum.reduce(d[:,136, 122])
85.8426361084
> na.maximum.reduce(d) [136, 122]
37.3658103943
> na.maximum.reduce(d,0)[136, 122]
37.3658103943
> na.maximum.reduce(d,1)[136, 122]
Traceback (most recent call last): File "<input>", line 1, in ? IndexError: Index out of range
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:
> a = na.arange(4*4*4) > a.shape=(4,4,4) > na.maximum.reduce(a)
[[48 49 50 51] [52 53 54 55] [56 57 58 59] [60 61 62 63]]
> a = na.arange(4*4*4).astype(na.Float32) > a.shape=(4,4,4) > na.maximum.reduce(a)
[[ 48. 49. 50. 51.] [ 52. 53. 54. 55.] [ 56. 57. 58. 59.] [ 60. 61. 62. 63.]]
Any hint ?
Regards, Sebastian Haase
Hi again, I think the reason that no one responded to this is that it just sounds to unbelievable ...
This just slipped through the cracks for me.
Sorry for the missing piece of information, but 'd' is actually a memmapped array !
d.info()
class: <class 'numarray.numarraycore.NumArray'> shape: (80, 150, 150) strides: (90000, 600, 4) byteoffset: 0 bytestride: 4 itemsize: 4 aligned: 1 contiguous: 1 data: <MemmapSlice of length:7290000 readonly> byteorder: big byteswap: 1 type: Float32
dd = d.copy() na.maximum.reduce(dd[:,136, 122])
85.8426361084
na.maximum.reduce(dd)[136, 122]
85.8426361084
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?
I think byteorder is a good guess at this point. What version of Python and numarray are you using?
Python 2.2.1 (#1, Feb 28 2004, 00:52:10) [GCC 2.95.4 20011002 (Debian prerelease)] on linux2
numarray 0.9 - from CVS on 2004-05-13.
Regards, Sebastian Haase
Hi Sebastian, I logged this on SF as a bug but won't get to it until next week after numarray-1.0 comes out. Regards, Todd
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
On Sat, 2004-07-03 at 13:10, Philip Austin wrote:
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'?
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
Todd Miller writes:
Should this print 'U'?
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.
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
With numarray 1.0 and Mandrake 10 i686 I get the following:
y=N.array([1,1,2,1],type="Float64") y array([ 1., 1., 2., 1.]) y.byteswap() y array([ 3.03865194e-319, 3.03865194e-319, 3.16202013e-322, 3.03865194e-319]) y.isbyteswapped() 0
Should this be 1? Thanks, Phil
On Tue, 2004-07-06 at 19:07, Philip Austin wrote:
With numarray 1.0 and Mandrake 10 i686 I get the following:
y=N.array([1,1,2,1],type="Float64") y array([ 1., 1., 2., 1.]) y.byteswap() y array([ 3.03865194e-319, 3.03865194e-319, 3.16202013e-322, 3.03865194e-319]) y.isbyteswapped() 0
Should this be 1?
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