[Numpy-discussion] Incomplete support in certain Numeric emulation functions in numarray
jmiller at stsci.edu
Wed Jan 22 06:52:08 EST 2003
Francesc Alted wrote:
>I have discovered that the Numeric emulation functions in numarray doesn't
>accept a character typecode as type parameter.
>This is not immediately apparent because type parameter is of type 'int',
>and passing it a 'char' maybe not a good practice.
I wrote the emulation functions using the manual and intuition rather
than the existing code. There will be others like this.
>But the fact is that
>Numeric *do* accept the charcodes in the type parameter.
No argument here. numarray can "always" be more compatible than it is
"now", for any value of always or now. I think the only real way to
avoid that would be to build Numeric into numarray, which sounds
>For example, this is the normal way to call the PyArray_FromDims function:
>arr = PyArray_FromDims(self.rank, self.dimensions, tFloat64)
>but, in Numeric, this other manner also works:
>arr = PyArray_FromDims(self.rank, self.dimensions, 'd')
This was nicely illustrated.
>Now, in numarray, if you pass a character to the type parameter, a
>"segmentation fault" is issued.
Decidedly not good.
>Look at the end of Numeric-22.0/Src/arraytypes.c, to see how characters are
>handled as types in Numeric. I think something like this should be added to
>the deferred_libnumarray_init in numarray-0.4/Src/newarray.ch.
I did a simple implementation of PyArray_DescrFromType trying to add
support for f2py.
There are 2 real issues with it that I see:
1. It still doesn't handle character codes. I think it could handle
both NumericTypes and character codes without conflict because of the
way the ASCII character set is layed out.
2. I just added it so that it *could* be called since I think f2py
needed it. I didn't call it anywhere from the other compatability
Care to do another patch?
>Another thing. It seems to me that NA_New and NA_Empty functions are not
>well documented in the numarray documentation as they differ from the
>definitions in numarray-0.4/Src/newarray.ch. I hope that the latter will
>stay, because I prefer them a lot more than the documented ones :-)
If you're working from CVS, the form they're in now was the result of
someone's detailed comments.
They're still not quite right, because the interface is written in
terms of int arrays, which is not good for LP64 platforms where long is
really what is needed to avoid creating 2G bottlenecks. The naming is
also not consistent and I will want to make it so before release of
More information about the NumPy-Discussion