<div class="gmail_quote">On Tue, Feb 1, 2011 at 10:09 PM, David <span dir="ltr"><<a href="mailto:david@silveregg.co.jp" target="_blank">david@silveregg.co.jp</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

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

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><br>
> I think the error handling policy<br>
> in the ufuncs could also be useful for computations in the core.<br>
<br>
</div>At the moment, ufunc and multiarray are separate extensions. If each<br>
depends on the other API-wise, it is an issue. If there are some<br>
commonalities, then they can be put in a separate extensions. They are<br>
already way too big as they are (historical reasons), we should really<br>
fight this for maintanability.<br>
<br>
I realize the code organization and the build stuff is a bit of a mess<br>
at the moment, so if you have questions on that aspect, feel free to ask<br>
clarification or help,</blockquote><div> </div><div>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.</div>
<div><br></div><div>Data Type API: data type numbers, casting, byte-swapping, etc.</div><div>Array Storage API: array creation/manipulation/deletion.</div><div>Array Iteration API: array iterators, copying routines.</div>
<div>Array Calculation API: typedefs for various types of calculation functions, common calculation idioms, ufunc creation API, etc.</div><meta http-equiv="content-type" content="text/html; charset=utf-8"><div><br></div><div>
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.</div><div><br></div><div>-Mark</div></div>