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