[Numpy-discussion] Numeric 24.0
oliphant at ee.byu.edu
Wed Apr 6 12:41:31 CDT 2005
Sébastien de Menten wrote:
> Hi Travis,
> Could you look at bug
> [ 635104 ] segfault unpickling Numeric 'O' array
> [ 567796 ] unpickling of 'O' arrays causes segfault (duplicate of
> previous one)
> I proposed a (rather simple) solution that I put in the comment of bug
> [ 635104 ]. But apparently, nobody is looking at those bugs...
One thing I don't like about sourceforge bug tracker is that I don't get
any email notification of bugs. Is there an option for that? I check
my email, far more often than I check a website. Sourceforge can be
quite slow to manipulate around in.
Now, that you've mentioned it, I'll look into it. I'm not sure that
object arrays could every be pickled correctly.
>> I'd like to release a Numeric 24.0 to get the array interface out
>> there. There are also some other bug fixes in Numeric 24.0
>> Here is the list so far from Numeric 23.7
>> [Greenfield] Changed so a[0,0] and a returns same type when a
>> is 2-d of Int16
> This is quite disturbing. In fact for all types that are not exactly
> equivalent to python type, indexing a multidimensional array (rank >
> 1) return arrays even if the final shape is ().
So, what should it do? This is the crux of a long-standing wart in
Numerical Python that nobody has had a good solution to (I think the
array scalars that have been introduced for scipy.base are the best
Right now, the point is that different things are done for different
indexing strategies. Is this a good thing? Maybe it is. We can
certainly leave it the way it is now and back-out the change.
The current behavior is:
Subscripting always produces a rank-0 array if the type doesn't match a
basic Python type.
Item getting always produces a basic Python type (even if there is no
So a[0,0] and a will return different things if a is an array of
short's for example. This may be what we live with and just call it a
> type(zeros((5,2,4), Int8 )[0,0,0]) => <type 'array'>
> type(zeros((5,2,4), Int32 )[0,0,0]) => <type 'array'>
> type(zeros((5,2), Float32 )[0,0]) => <type 'array'>
> type(zeros((5,2,4), Int )[0,0,0]) => <type 'int'>
> type(zeros((5,2,4), Float64)[0,0,0]) => <type 'float'>
> type(zeros((5,2,4), Float)[0,0,0]) => <type 'float'>
> type(zeros((5,2,4), PyObject)[0,0,0]) => <type 'int'>
> Notice too the weird difference betweeb Int <> Int32 and Float ==
This has been in Numeric for a long time (the coercion problems was one
of the big reasons for it). If you return a Python integer when
indexing an Int8 array then use that for multiplication you get
undesired up-casting. There is no scalar Int8 type to return (thus a
0-dimensional array that can act like a scalar is returned). In
scipy.base there are now scalar-like objects for all of the supported
array types which is one solution to this problem that was made possible
by the ability to inherit in C that is now part of Python.
What platform are you on? Notice that Int is interpreted as C-long
(PyArray_LONG) while Int32 is PyArray_INT. This has been another
wart in Numerical Python.
By the way, I've fixed PyArray_Return so that if
sizeof(long)==sizeof(int) then PyArray_INT also returns a Python
integer. I think for places where sizeof(long)==sizeof(int)
PyArray_LONG and PyArray_INT should be treated identically.
> However, when indexing a onedimensional array (rank == 1), then we get
> back scalar for indexing operations on all types.
> So, when you say "return the same type", do you think scalar or array
> (it smells like a recent discussion on Numeric3 ...) ?
I just think the behavior ought to be the same for a[0,0] or a
but maybe I'm wrong and we should keep the dichotomy to satisfy both
groups of people. Because of the problems I alluded to, sometimes a
0-dimensional array should be returned.
More information about the Numpy-discussion