numpy-discussion

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

[Francesc A. <fa...@op...>]

Hi,

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. But the fact is that
Numeric *do* accept the charcodes in the type parameter.=20

For example, this is the normal way to call the PyArray_FromDims function=
:

arr =3D PyArray_FromDims(self.rank, self.dimensions, tFloat64)

but, in Numeric, this other manner also works:

arr =3D PyArray_FromDims(self.rank, self.dimensions, 'd')

Now, in numarray, if you pass a character to the type parameter, a
"segmentation fault" is issued.

Look at the end of Numeric-22.0/Src/arraytypes.c, to see how characters a=
re
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.

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 :-)

Bye,

--=20
Francesc Alted

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

[Todd M. <jm...@st...>]

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

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

[Francesc A. <fa...@op...>]

A Dimecres 22 Gener 2003 15:51, Todd Miller va escriure:
>
> 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.

I think so

>
> 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.
>

I tried to patch your PyArray_DescrFromType, but nothing has changed
because, as you said, any compatabilty function call it.

> Care to do another patch?

Well, I've tried to patch the NA_NewAll funtion in newarray.c:

        typeObject =3D pNumType[type];
        if (!typeObject) {
           /* Test if it is a Numeric charcode */
           sprintf(strcharcode, "%c", type);
           charcode =3D PyString_FromString(strcharcode);
           typeobj =3D PyDict_GetItemString(pNumericTypesTDict, strcharco=
de);
           if (typeobj) {
              typeObject =3D typeobj;
           } else
             return (PyArrayObject *) PyErr_Format(_Error,
                   "Type object lookup returned NULL for type %d", type);
        }

instead of the original code:

        typeObject =3D pNumType[type];
        if (!typeObject)
                return (PyArrayObject *) PyErr_Format(_Error,
                    "Type object lookup returned NULL for type %d", type)=
;
       =20
with no luck as the segmentation fault continues to appear.

Anyway, I've already patched my original code to use only integer codes, =
not
character, so it would be a problem (at least for me).

> 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 i=
s
> 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.

Ok, so perhaps it's better to use the PyArray_FromDims rather than NA_Emp=
ty
(at least, until the C-API stabilizes). It's good to know that!.

BTW, during the patching work of numarray sources I perceived some missin=
g
character code types in numerictypes.py. These are the correspondents to:
UInt16, Int64 and UInt64. In recarray, they don't appear neither (except =
for
Int64 which appears as 'N' in numfmt, but with no correspondant in revfmt=
),
so one can't build-up recarrays with these types because you need a charc=
ode
for the "formats" string.

Is this intentional? Do you plan to fill these gaps (it would be nice,
specially for recarrays)?

Thanks,

--=20
Francesc Alted