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 needed.
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. http://thinkgeek.com/sf _______________________________________________ Numpy-discussion mailing list Numpyfirstname.lastname@example.org https://lists.sourceforge.net/lists/listinfo/numpy-discussion