[Numpy-discussion] slow numpy.clip ?

Charles R Harris charlesr.harris at gmail.com
Wed Dec 20 09:25:13 CST 2006


On 12/20/06, Travis Oliphant <oliphant at ee.byu.edu> wrote:
>
>
> >     My question is then: is there any plan to change this ? If not, is
> >     this
> >     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.


I've been thinking about that a bit. One solution is to have a small python
program that takes all the pieces and writes one big build file, I think
something like that happens now. Another might be to use includes in a base
file; there is nothing sacred about not including .c files or not putting
code in .h files, it is just a convention, we could even chose another
extension.  I also wonder if we couldn't just link in object files. The
table of function pointers just needs some addresses and, while the python
convention of hiding all the function names by using static functions is
nice, it is probably not required. Maybe we could use ctypes in some way?

I am not pushing any of these alternatives at the moment, just putting them
down. Maybe there are others?

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://projects.scipy.org/pipermail/numpy-discussion/attachments/20061220/4214798a/attachment.html 


More information about the Numpy-discussion mailing list