Travis Oliphant <oliphant@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@physics.mcmaster.ca