[Numpy-discussion] Please keep Numpy master working on Py3

Mark Wiebe mwwiebe at gmail.com
Thu Feb 3 13:07:39 EST 2011

On Tue, Feb 1, 2011 at 10:09 PM, David <david at silveregg.co.jp> wrote:

> On 02/02/2011 02:57 PM, Mark Wiebe wrote:
> > On Tue, Feb 1, 2011 at 9:49 PM, David <david at silveregg.co.jp
> > <mailto:david at silveregg.co.jp>> wrote:
> >
> >     <snip>
> >
> >
> >      > In the meantime, I put the relevant header in
> >     numpy/core/src/private, to
> >      > make the dependency clearer.
> >
> >     Following that argument, there are other unwanted dependencies
> between
> >     multiarray and ufunc, causing circular dependencies. I don't think
> they
> >     were there before, and it makes building numpy with a
> dependency-based
> >     tool like scons or waf extremely difficult.
> >
> >
> > This particular separation of two components felt somewhat artificial to
> > me.  For the iterator buffering, as an example, I initially thought it
> > would be good to use the same default as the ufuncs do.  Instead I ended
> > up just using a hard-coded default.
> Not sure I understand the exact argument, but if it is just a matter of
> getting default values, it is easy to share them using a common header.

I guess my argument was just that a few more ufunc features need to migrate
to the core.  I don't think this needs to be done at the moment, though.

> > I think the error handling policy
> > in the ufuncs could also be useful for computations in the core.
> At the moment, ufunc and multiarray are separate extensions. If each
> depends on the other API-wise, it is an issue. If there are some
> commonalities, then they can be put in a separate extensions. They are
> already way too big as they are (historical reasons), we should really
> fight this for maintanability.
> I realize the code organization and the build stuff is a bit of a mess
> at the moment, so if you have questions on that aspect, feel free to ask
> clarification or help,

Yeah, I understand it's the result of organic growth and merging from many
different sources. The core library should probably become layered in a
manner roughly as follows, with each layer depending only on the previous
APIs.  This is what Travis was getting at, I believe, with the generator
array idea affecting mainly the Storage and Iteration APIs, generalizing
them so that new storage and iteration methods can be plugged in.

Data Type API: data type numbers, casting, byte-swapping, etc.
Array Storage API: array creation/manipulation/deletion.
Array Iteration API: array iterators, copying routines.
Array Calculation API: typedefs for various types of calculation
functions, common calculation idioms, ufunc creation API, etc.

Then, the ufunc module would use the Array Calculation API to implement all
the ufuncs and other routines like inner, dot, trace, diag, tensordot,
einsum, etc.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20110203/cb1c219a/attachment.html>

More information about the NumPy-Discussion mailing list