[Numpy-discussion] Numeric 24.0

Travis Oliphant 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.

-Travis

>
>>
>> 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[0][0] 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 
solution yet). 

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 
match). 

So a[0,0] and a[0][0]  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 
"feature"


> So
> 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'>
> But
> 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 == 
> Float64.


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[0][0]  
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.

-Travis








More information about the Numpy-discussion mailing list