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