[Numpy-discussion] Math Library

Sebastian Walter sebastian.walter@gmail....
Sun Apr 11 16:17:58 CDT 2010

On Sun, Apr 11, 2010 at 12:59 PM, Sebastian Walter
<sebastian.walter@gmail.com> wrote:
> On Tue, Apr 6, 2010 at 9:16 PM, Travis Oliphant <oliphant@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 <oliphant@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

More information about the NumPy-Discussion mailing list