[Numpy-discussion] Optionally using Numeric in another compiled extension package.

[Chris Barker]

Francesc Alted wrote:

> that having a small core with the "glue"
> functionality between numarray objects and 3rd party extensions in C (or
> SWIG, Pyrex or whatever) can be a good thing (until numarray is in the
> Standard Library).
> 
> That way, people interested in supporting numarray objects in their
> extensions has only to install this small core (or even include it as part
> of the extension).

I think that's a fabulous idea, but I have no idea how hard it would be.
There would still be the problem of keeping versions in-sync. If I
distributed my package with the glue code, it would only work on
installations using the same version of Numeric (or NumArray, I suppose)


Thanks to all who have commented on my post. These are some ideas I now
have based on your comments:

> > Use the Python C-API and string literals as the basis for the
> > interface. I think the steps are something like this:
> >
> > 1.  Import "Numeric". (PyImport_ImportModule)
> >
> > 2.  Get the module dictionary.    (PyModule_GetDict)
> >
> > 3.  Get "array" out of the dictionary.   (PyDict_GetItemString)
> >
> > 4.  Call "isinstance" on Numeric.array and the object.
> > (PyObject_IsInstance)

OK, so now I can know, at runtime, whether Numeric has been imported.

> But...  It's not clear to me that knowing an object is an array will
> help since getting data elements still has to be done fast,  and that
> seems hard to do without knowing the arrayobject struct.

Exactly. that's my whole problem. However, I have an idea about this. If
I do the above test, I can now put all the Numeric specific code into a
conditional, so it would only get called in Numeric were imported. My
idea is that I could make sure Numeric was around at compile time, so I
could use all the Numeric API to access the array data, but it wouldn't
have to be installed at runtime, as none of the Numeric calls would be
executed if Numeric hadn't been imported. Would this work, or would the
system try to load the .dll or .so or whatever even if the calls weren't
executed?

All that being said, Tim Hochberg has mentioned that when he first made
wxPython DCs work with Numeric Arrays,( sorry I didn't give him credit
before, I had forgotten who did that, thanks Tim ) he did some timing
and discovered that the the overhead of the drawing calls was
substantially larger than the overhead of the indexing anyway, so
speedin up that process couldn't make much difference. 

My timing indicated something different, but I'm using Linux/wxGTK/X11,
and I think the drawing calls return after the message has been sent to
X, but X may not have completed the actual drawing yet. This means that
I'm not timing the whole process, and if I did, I might not see such a
difference. I did some tests with 100,000 points, and found that I could
see the difference with a List and Array, and the List was about twice
as fast. Drawing rectangles, however, I can't see the difference.

So, I think I'll probably shelve this for the moment, and concentrate on
getting all the drawing shapes supported by DrawXXXList methods.

Thanks for all your input.

-Chris











-- 
Christopher Barker, Ph.D.
Oceanographer
                                    		
NOAA/OR&R/HAZMAT         (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov