[Numpy-discussion] Numeric 24.0

David M. Cooke cookedm at physics.mcmaster.ca
Wed Apr 6 14:04:36 EDT 2005

Travis Oliphant <oliphant at ee.byu.edu> writes:

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

I think if the bug is assigned to you, you get email.
>> 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.
> 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.

I don't think this is good -- it's just papering over the problem. It
leads to different behaviour on machines where sizeof(long) !=
sizeof(int) (specifically, the problem reported by Nils Wagner *won't*
be fixed by this on my machine). On some machines x[0] will give you a
int (where x is an array of Int32), on others an array: not fun.

I see you already beat me in changing PyArray_PyIntAsInt to support
rank-0 integer arrays. How about changing that to instead using
anything that int() can handle (using PyNumber_AsInt)? This would
include anything int-like (rank-0 integer arrays, scipy.base array
scalars, etc.).

The side-effect is that you can index using floats (since int() of a
float truncates it towards 0). If this is a big deal, I can
special-case floats to raise an error.

This would make (almost) all Numeric behaviour consistent with regards
to using Python ints, Python longs, and rank-0 integer arrays, and
other int-like objects.

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

I'd prefer having a[0,0] and a[0][0] return the same thing: it's not
the special case of how to do two indices: it's the special-casing of
rank-1 arrays as compared to rank-n arrays.

|David M. Cooke                      http://arbutus.physics.mcmaster.ca/dmc/
|cookedm at physics.mcmaster.ca

More information about the NumPy-Discussion mailing list