On Wed, Apr 06, 2005 at 07:33:56AM +0000, 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...
This is too true. Travis added myself and Michiel de Hoon recently to the developers, so there's some new blood, and we've been banging on things, though. I'll have a look at it if I've got time. I personally really hate bugs that crash my interpreter :-)
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 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.
That's because Int is *not* Int32. Int32 is the first typecode of '1sil' that has 32 bits. For (all?) platforms I've seen, that'll be 'i'. Int corresponds to a Python integer, and Float corresponds to a Python float. Now, a Python integer is actually a C long, and a Python float is actually a C double. I've made a table: Numeric type typecode Python type C type Array type Int 'l' int long PyArray_LONG Int32 'i' [1] N/A int PyArray_INT Float 'd' float double PyArray_DOUBLE Float32 'f' N/A float PyArray_FLOAT Float64 'd' float double PyArray_DOUBLE [1] assuming sizeof(int)==4, which is true on most platforms. There are some 64-bit platforms where this won't be true, I think. On (all? most?) 32-bit platforms, sizeof(int) == sizeof(long) == 4, so both Int and Int32 be 32-bit quantities. Not so on some 64-bit platforms (Linux on an Athlon 64, like the one I'm typing at now), where sizeof(long) == 8. I've been fixing oodles of assumptions in Numeric where ints and longs have been used interchangeably, hence the extended discussion :-) [I haven't addressed here why you get an array sometimes and a Python type the others. This is the standard, old, behaviour -- it's likely not going to change in Numeric. Whether it's a *good* thing is another question. scipy.base and numarray do it differently.] -- |>|\/|< /--------------------------------------------------------------------------\ |David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/ |cookedm@physics.mcmaster.ca