[Numpy-discussion] libnumarray.h and NO_IMPORT_ARRAY
jmiller at stsci.edu
Wed Oct 9 11:48:02 CDT 2002
Philip Austin wrote:
>Todd, thanks for the quick response. Regarding your header comments:
>Extensions constructed from seperate compilation units can access the
>C-API defined here by defining "libnumarray_UNIQUE_SYMBOL" to a global
>name unique to the extension. Doing this circumvents the requirement
>to import libnumarray into each compilation unit, but is nevertheless
>mildly discouraged as "outside the Python norm" and potentially
>leading to problems. Looking around at "existing Python art", most
>extension modules are monolithic C files, and likely for good reason.
>I'd agree with this sentiment, but with numarray's NDInfo interface I
>think we were stuck (we have an implementation file for a bunch of
>boost numarray helper functions that require the API but have static
>data initializations, so they can't go into a header).
Long term, you would be better off ditching NDInfo and working with the
Numeric compatability API. Since it's a subset of the Numeric API, it
may not support your purposes. However, if it doesn't, I want to
extend it until it does.
>With Numeric, we could avoid import_array altogether, and get
>everything we needed from PyObject_CallObject calls to Numeric to
>create arrays using zeros or ones, followed by a cast to
>PyArrayObject* to get the data pointer and fill the array. With
>numarray, we need (or needed) getNDInfo to do the same thing,
>mandating an import_libnumarray. Are the plans for the revised
>interface to behave in the same way as NDInfo?
The current plan is to deprecate the "native" APIs which make use of
NDInfo and to make numarray as compatible as possible with Numeric.
The bulk of the changes which make this reasonable are in numarray CVS
now. In a nutshell, prior to our use of C basetypes, we needed
something like NDInfo. Now that we're using C basetypes, NDInfo
appears less efficient, less compatible, and more complex than the
"Numeric compatability" interface. Its possible for our "basetypes" to
appear to be Numeric arrays, so that's what we did. If you guys find
that you need missing parts of the Numeric C-API, I'll add them to
numarray. So far, I've just added what I needed or knew someone else
> It's not a big deal to
>us one way or another, but it would simplify Dave Abraham's boost
>support for numeric/numarray if much of the functionality could be
>done through python calls from the C side.
Can you send me the Numeric wrapper code or let me know where to get it?
>This sf.net email is sponsored by:ThinkGeek
>Welcome to geek heaven.
>Numpy-discussion mailing list
>Numpy-discussion at lists.sourceforge.net
Todd Miller jmiller at stsci.edu
STSCI / SSB
More information about the Numpy-discussion