<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Mar 11, 2021 at 6:08 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">On Thu, 2021-03-11 at 12:37 +0100, Ralf Gommers wrote:<br>
> On Wed, Mar 10, 2021 at 6:41 PM Sebastian Berg < <br>
> <a href="mailto:sebastian@sipsolutions.net" target="_blank">sebastian@sipsolutions.net</a>><br>
> wrote:<br>
> <br>
> > 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<br>
> > now.<br>
> > <br>
> <br>
> All great questions, that Sebastian. Let me reply to the questions<br>
> that<br>
> Aaron didn't reply to inline below.<br>
> <br>
<br>
To be clear, I do not expect complete answers to these questions right<br>
now.  (Although being unsure about some of them does make me slightly<br>
reluctant to merge the work-in-progress into NumPy proper as opposed to<br>
a separate repo.)<br>
<br>
Also, yes, most/all questions are hopefully are just trivialities to<br>
check of (or no more than seeds for thought).  Or even just a starting<br>
point for making NEP 47's "Usage and Impact" section more complete<br>
including them as either "example usage patterns" or "limitations".<br></blockquote><div><br></div><div>Yes, those are always good to have more of.</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>
My second takeaway from the questions is that I have doubts the<br>
"minimal" version will pan out, it feels like many of the questions<br>
might disappear if you drop that part. </blockquote><div><br></div><div>My impression is that a strictly compliant (or "minimal") version is *more* useful than something that's a mix between portable and non-portable functionality. The reason to add more than the minimum required functionality would be that it's too hard to hide the numpy-specific extras. E.g., if we'd do `np.array_api.int32 = np.int32` then that dtype would have methods and behavior that's NumPy-specific. But it'd be hard to hide, so we'd accept it.<br></div><div><br></div><div>It's maybe easier to discuss in a call, I've put it on the community meeting agenda.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">So, from my current thinking,<br>
the minimal implementation may not be a good "NEP 47" implementation.<br>
<br>
That does _not_ mean that I think you should pause and reconsider or<br>
even worry about pleasing me with good answers!  Just continue under<br>
whatever assumption you prefer and if it turns out that "minimal" won't<br>
work for NEP 47: no harm done!  We need a "minimal implementation" in<br>
any case.<br></blockquote><div><br></div><div>Yes, I agree.</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>
Cheers,<br>
<br>
Sebastian<br>
<br>
<br>
<br>
[1] If SciPy needs an additional NumPy code path to keep support<br>
`object` arrays or other dtypes – right now even complex –, then the<br>
reader needs to be aware of that to make a decision if NEP 47 will<br>
actually help for their library.<br></blockquote><div><br></div><div>Clearly. This is why we'd like to have some WIP PRs for other libraries, actual code to review will be more helpful than only a proposal. <br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Will AstroPy have to reimplement `astropy.units.Quantity` to be<br>
"standard conform" (is that even possible!?) before it can easily adopt<br>
it any of its API that currently works with `astropy.units.Quantity`?<br></blockquote><div><br></div>I'm not sure if the question is well-defined, so let me answer both cases:</div><div class="gmail_quote"><br></div><div class="gmail_quote">1. If the APIs in question require units, then there's no other array/tensor types that have unit support, so those APIs accept *only* Quantity. Adopting the standard isn't possible.<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">2. If the units are unnecessary/optional, then Quantity is not special and can be treated exactly the same as a `numpy.ndarray`. We don't intend to make any changes to how ndarray subclasses work, so if ndarray works with that API after adoption of the standard then Quantity works too.</div><div class="gmail_quote"><br></div><div class="gmail_quote">Cheers,<br></div><div class="gmail_quote">Ralf</div><div class="gmail_quote"><br></div><div class="gmail_quote"><br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<br>
> <br>
> > 1. I still need clarity how a library is supposed to use this<br>
> > 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<br>
> > decorator,<br>
> > but it seems important.<br>
> > <br>
> <br>
> I agree that it will be a common pattern that libraries will accept<br>
> all<br>
> standard-compliant array types plus numpy.ndarray. And the output<br>
> array<br>
> type should match the input type. In Aaron's implementation the new<br>
> array<br>
> object has a numpy.ndarray as private attribute, so that's the<br>
> instance<br>
> that should be returned. A decorator seems like a sensible way to<br>
> handle<br>
> that. Or a simple utility function, something like `return<br>
> correct_arraytype(out)`.<br>
> <br>
> Either way, that pattern should be added to NEP 47. I don't see a<br>
> fundamental problem here, we just need to find the nicest UX for it.<br>
> <br>
> 3. For all other function, the same problem applies. You don't<br>
> actually<br>
> > have anything to fix NumPy promotion rules.  You could bake your<br>
> > own<br>
> > cake here for numeric types, but I am not sure, you might also need<br>
> > NEP<br>
> > 43 in all its promotion power to pull it off.<br>
> > <br>
> <br>
> This is probably the single most difficult question implementation-<br>
> wise.<br>
> Note that there are only numerical dtypes (plus boolean), so dealing<br>
> with<br>
> string, datetime, object or third-party dtypes is a non-issue.<br>
> <br>
> 4. The PR makes no attempt at handling binary operators in any way<br>
> > aside from greedily coercing the other operand.<br>
> > <br>
> <br>
> Agreed. This is the same point as (3) I think - how to handle dtype<br>
> promotion is the main open question.<br>
><br>
> <br>
> > 5. What happens with a mix of array-likes or even array subclasses<br>
> > like<br>
> > `astropy.quantity`?<br>
> > <br>
> <br>
> Array-likes (e.g. list) should raise an exception, the NEP clearly<br>
> says "do<br>
> not accept array_like dtypes". This is what every other array/tensor<br>
> library already does.<br>
> <br>
> Array subclasses should work as expected, assuming they're valid<br>
> subclasses<br>
> and not things like np.matrix. Using Mypy will help avoid writing<br>
> more<br>
> subclasses that break the Liskov substitution principle. More<br>
> comments in<br>
> <a href="https://numpy.org/neps/nep-0047-array-api-standard.html#the-asarray-asanyarray-pattern" rel="noreferrer" target="_blank">https://numpy.org/neps/nep-0047-array-api-standard.html#the-asarray-asanyarray-pattern</a><br>
> <br>
> Mixing two different types of arrays into a single function call<br>
> should<br>
> raise an exception. A design goal is: enable writing functions<br>
> `somefunc(x1, x2)` that work for any type of array where `x1, x2`<br>
> come from<br>
> the same library = so they're either the same type, or two types for<br>
> which<br>
> the library itself knows how to mix them. If x1 and x2 are from<br>
> different<br>
> libraries, this will raise an exception.<br>
> <br>
> To be clear, it is not intended that `np.array_api.somefunc(x_cupy)`<br>
> works<br>
> - this will raise an exception.<br>
> <br>
> Cheers,<br>
> Ralf<br>
> <br>
> <br>
> <br>
> > <br>
> > I don't think we have to figure out everything up-front, but I do<br>
> > think<br>
> > there are a few very fundamental questions still open, at least for<br>
> > me<br>
> > personally.<br>
> > <br>
> > Cheers,<br>
> > <br>
> > Sebastian<br>
> > <br>
> > <br>
> > <br>
> _______________________________________________<br>
> NumPy-Discussion mailing list<br>
> <a href="mailto:NumPy-Discussion@python.org" target="_blank">NumPy-Discussion@python.org</a><br>
> <a href="https://mail.python.org/mailman/listinfo/numpy-discussion" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/numpy-discussion</a><br>
<br>
_______________________________________________<br>
NumPy-Discussion mailing list<br>
<a href="mailto:NumPy-Discussion@python.org" target="_blank">NumPy-Discussion@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/numpy-discussion" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/numpy-discussion</a><br>
</blockquote></div></div>