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

Charles R Harris charlesr.harris at gmail.com
Thu Feb 3 13:50:28 EST 2011


On Thu, Feb 3, 2011 at 11:07 AM, Mark Wiebe <mwwiebe at gmail.com> wrote:

> 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.
>
>
I like the lower two levels if, as I assume, they are basically aimed at
allocating, deallocating blocks of memory (or equivalent) and doing basic
manipulations such as dealing with endianess and casting. Where do you see
array methods making an appearance? The original Numeric only had three
(IIRC) rather basic methods and everything else was function based, an
approach which is probably easier to maintain. The extensive use of methods
came from numarray and might be something that could be added at a higher
level so that the current ndarrays would be objects combining ow level
arrays and ufuncs.

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


More information about the NumPy-Discussion mailing list