[Numpy-discussion] Math Library

[Sebastian Walter]

On Tue, Apr 6, 2010 at 9:16 PM, Travis Oliphant <oliphant at 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 at 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)

Sebastian


> Thanks for the input,
> -Travis
>
>
>
>
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>