Francesc Alted wrote:
Hi,
I have discovered that the Numeric emulation functions in numarray doesn't accept a character typecode as type parameter.
Interesting.
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 dubious. :)
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 functions. 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 numarray-0.5.
Bye,
Todd