[Numpy-discussion] slow numpy.clip ?
oliphant at ee.byu.edu
Wed Dec 20 03:03:16 CST 2006
> My question is then: is there any plan to change this ? If not, is
> for some reasons I don't see, or is this just because of lack of
> manpower ?
> I raised the possibility of breaking up the files before and Travis
> was agreeable to the idea. It is still in the back of my mind but I
> haven't got around to doing anything about it. Maybe we should put
> together a step by step approach, agree on some file names for the new
> files, fix the build so it loads in the new stub files in the correct
> order, and then start moving stuff. My own original desire was to
> break out the keyword parsers into a separate file but I think Travis
> had different priorities.
The problem with separate files is (and has always been) the NumPy
C-API. I tried to use separate files to some extent (and then use
#include to make it all one big file). The C-API is exposed by filling
in a table of function pointers. You will notice that when
arrayobject.h is included for an extension module, all of the C-API is
defined to pull a particular function pointer out of a table that is
stored in a Python CObject in the multiarray module extension itself.
Basically, NumPy is following the standard Python advice (as Numeric and
Numarray did) about how to expose a C-API, but it's just gotten a bit big.
Solutions to that problem are always welcome.
More information about the Numpy-discussion