[Numpy-discussion] Numeric 24.0

[David M. Cooke]

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 at physics.mcmaster.ca