[Numpy-discussion] Incomplete support in certain Numeric emulation functions in numarray

[Todd Miller]

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