On Sun, Apr 11, 2010 at 12:59 PM, Sebastian Walter <sebastian.wal...@gmail.com> wrote: > On Tue, Apr 6, 2010 at 9:16 PM, Travis Oliphant <oliph...@enthought.com> > wrote: >> >> On Apr 6, 2010, at 9:08 AM, David Cournapeau wrote: >> >> Hi Travis, >> >> On Tue, Apr 6, 2010 at 7:43 AM, Travis Oliphant <oliph...@enthought.com> >> wrote: >> >> >> I should have some time over the next couple of weeks, and I am very >> >> interested in refactoring the NumPy code to separate out the Python >> >> interface layer from the "library" layer as much as possible. I had >> >> some discussions with people at PyCon about making it easier for >> >> Jython, IronPython, and perhaps even other high-level languages to >> >> utilize NumPy. >> >> Is there a willingness to consider as part of this reorganization >> >> creating a clear boundary between the NumPy library code and the >> >> Python-specific interface to it? What other re-organization thoughts >> >> are you having David? >> >> This is mainly it, reorganizing the code for clearer boundaries >> between boilerplate (python C API) and actual compuational code. >> Besides helping other python implementations, I think this would >> benefit NumPy itself in the long run (code maintainability), as well >> as scipy (and other C extensions). I think the npymath effort is a >> good example: albeit simple in nature (the API and boundaries are >> obvious), it has already helped a lot to solve numerous platform >> specific issues in numpy and scipy, and I think the overall code >> quality is better. >> >> My own goals were: >> - exposing core computational parts through an exported C API, so >> that other C extensions may use it (for example, exposing basic >> blas/lapack operations) >> - dynamic loading of the code (for example depending on the CPU >> capabilities - I have a git branch somewhere where I started exposing >> a simple C API to query cpu capabilities like cache size or SSE >> dynamically to that intent) >> - more amenable codebase: I think multiarray in particular is too >> big. I don't know the code well enough to know what can be split and >> how, but I would have hoped that the scalartypes, the type descriptor >> could be put out of multiarray proper. Also, exposing an API for >> things like fancy indexing would be very useful, but I don't know if >> it even makes sense - I think a pure python implementation of fancy >> indexing as a reference would be very useful for array-like classes (I >> am thinking about scipy.sparse, for example). >> >> Unfortunately, I won't be able to help much in the near future (except >> maybe for the fancy indexing as this could be useful for my job), >> >> >> I understand. It just happens that there is some significant time for me >> to look at this over the next few weeks and I would really like to make >> progress on re-factoring. I think it's O.K. if you don't have time right >> now to help as long as you have time to offer criticism and suggestions. >> We could even do that over Skype with whomever else wanted to join us (we >> could do a GotoMeeting discussion as well) if you think it would be faster >> to just talk in a group setting instead of email. Of course, a summary >> of any off-line discussion should be sent to the list. > > I'm not sure how much I could contribute to the discussion since I > have only quite hazy > knowledge of the numpy core. However, I'm interested in the outcome of > the refactoring > since I'm facing a "similar" problem in > http://github.com/b45ch1/taylorpoly where I've implemented core > algorithms in C > for formal power series over the reals. Basically the formal > powerseries are a new dtype and the goal is to be able to > do computations like > x = numpy.zeros((2,3),dtype='name of the formal powerseries') > y = numpy.sin(x)
Ermm, the reply above is quite poor, sorry about that. What I meant to say is the following: If there is going to be a discussion about creating a pure C numpy library I'd like to join ;) > > Sebastian > > >> Thanks for the input, >> -Travis >> >> >> >> >> _______________________________________________ >> NumPy-Discussion mailing list >> NumPy-Discussion@scipy.org >> http://mail.scipy.org/mailman/listinfo/numpy-discussion >> >> > _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
