<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, May 29, 2017 at 12:32 PM, Marten van Kerkwijk <span dir="ltr"><<a href="mailto:m.h.vankerkwijk@gmail.com" target="_blank">m.h.vankerkwijk@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Chuck,<br>
<br>
Like Sebastian, I wonder a little about what level you are talking<br>
about. Presumably, it is the actual implementation of the ufunc? I.e.,<br>
this is not about the upper logic that decides which `__array_ufunc__`<br>
to call, etc.<br>
<br>
If so, I agree with you that it would seem to make most sense to move<br>
the implementation to `multiarray`; the current structure certainly is<br>
a major hurdle to understanding how things work!<br>
<br>
Indeed, I guess in terms of my earlier suggestion to make much of a<br>
ufunc happen in `ndarray.__array_ufunc__`, one could seem the type<br>
resolution and iteration happening there. If one were to expose the<br>
inner loops, anyone working with buffers could then use the ufuncs by<br>
defining their own __array_ufunc__.<br></blockquote><div><br></div><div>The idea of separating ufuncs from ndarray was put forward many years ago, maybe five or six. What I seek here is a record that we have given up on that ambition, so do not need to take it into consideration in the future. In particular, we can feel free to couple ufuncs even more tightly with ndarray.<br><br></div><div>Chuck <br></div><br></div></div></div>