[Numpy-discussion] Incomplete support in certain Numeric emulation functions in numarray
Francesc Alted
falted at openlc.org
Wed Jan 22 09:48:03 EST 2003
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 = pNumType[type];
if (!typeObject) {
/* Test if it is a Numeric charcode */
sprintf(strcharcode, "%c", type);
charcode = PyString_FromString(strcharcode);
typeobj = PyDict_GetItemString(pNumericTypesTDict, strcharcode);
if (typeobj) {
typeObject = typeobj;
} else
return (PyArrayObject *) PyErr_Format(_Error,
"Type object lookup returned NULL for type %d", type);
}
instead of the original code:
typeObject = pNumType[type];
if (!typeObject)
return (PyArrayObject *) PyErr_Format(_Error,
"Type object lookup returned NULL for type %d", type);
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 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.
Ok, so perhaps it's better to use the PyArray_FromDims rather than NA_Empty
(at least, until the C-API stabilizes). It's good to know that!.
BTW, during the patching work of numarray sources I perceived some missing
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 charcode
for the "formats" string.
Is this intentional? Do you plan to fill these gaps (it would be nice,
specially for recarrays)?
Thanks,
--
Francesc Alted
More information about the NumPy-Discussion
mailing list