On Tue, Feb 1, 2011 at 10:09 PM, David <da...@silveregg.co.jp> wrote:
> On 02/02/2011 02:57 PM, Mark Wiebe wrote: > > On Tue, Feb 1, 2011 at 9:49 PM, David <da...@silveregg.co.jp > > <mailto:da...@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. -Mark
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
