<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Mar 10, 2021 at 6:41 PM Sebastian Berg <<a href="mailto:sebastian@sipsolutions.net">sebastian@sipsolutions.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Top Posting, to discuss post specific questions about NEP 47 and<br>
partially the start on implementing it in:<br>
<br>
    <a href="https://github.com/numpy/numpy/pull/18585" rel="noreferrer" target="_blank">https://github.com/numpy/numpy/pull/18585</a><br>
<br>
There are probably many more that will crop up. But for me, each of<br>
these is a pretty major difficulty without a clear answer as of now.<br></blockquote><div><br></div><div>All great questions, that Sebastian. Let me reply to the questions that Aaron didn't reply to inline below.<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
1. I still need clarity how a library is supposed to use this namespace<br>
when the user passes in a NumPy array (mentioned before).  The user<br>
must get back a NumPy array after all.  Maybe that is just a decorator,<br>
but it seems important.<br></blockquote><div><br></div><div>I agree that it will be a common pattern that libraries will accept all standard-compliant array types plus numpy.ndarray. And the output array type should match the input type. In Aaron's implementation the new array object has a numpy.ndarray as private attribute, so that's the instance that should be returned. A decorator seems like a sensible way to handle that. Or a simple utility function, something like `return correct_arraytype(out)`. <br></div><div><br></div><div>Either way, that pattern should be added to NEP 47. I don't see a fundamental problem here, we just need to find the nicest UX for it.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">


3. For all other function, the same problem applies. You don't actually<br>
have anything to fix NumPy promotion rules.  You could bake your own<br>
cake here for numeric types, but I am not sure, you might also need NEP<br>
43 in all its promotion power to pull it off.<br></blockquote><div><br></div><div>This is probably the single most difficult question implementation-wise. Note that there are only numerical dtypes (plus boolean), so dealing with string, datetime, object or third-party dtypes is a non-issue.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

4. The PR makes no attempt at handling binary operators in any way<br>
aside from greedily coercing the other operand.<br></blockquote><div><br></div><div>Agreed. This is the same point as (3) I think - how to handle dtype promotion is the main open question.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
5. What happens with a mix of array-likes or even array subclasses like<br>
`astropy.quantity`?<br></blockquote><div><br></div><div>Array-likes (e.g. list) should raise an exception, the NEP clearly says "do not accept array_like dtypes". This is what every other array/tensor library already does.</div><div><br></div><div>Array subclasses should work as expected, assuming they're valid subclasses and not things like np.matrix. Using Mypy will help avoid writing more subclasses that break the Liskov substitution principle. More comments in <a href="https://numpy.org/neps/nep-0047-array-api-standard.html#the-asarray-asanyarray-pattern">https://numpy.org/neps/nep-0047-array-api-standard.html#the-asarray-asanyarray-pattern</a></div><div><br></div><div>Mixing two different types of arrays into a single function call should raise an exception. A design goal is: enable writing functions `somefunc(x1, x2)` that work for any type of array where `x1, x2` come from the same library = so they're either the same type, or two types for which the library itself knows how to mix them. If x1 and x2 are from different libraries, this will raise an exception.</div><div><br></div><div>To be clear, it is not intended that `np.array_api.somefunc(x_cupy)` works - this will raise an exception. <br></div><div><br> </div><div>Cheers,<br></div><div>Ralf</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<br>
I don't think we have to figure out everything up-front, but I do think<br>
there are a few very fundamental questions still open, at least for me<br>
personally.<br>
<br>
Cheers,<br>
<br>
Sebastian<br>
<br>
<br>
</blockquote></div></div>