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