<div dir="ltr">This slide deck from Matthew Rocklin at SciPy 2019 might be relevant:<div><a href="https://matthewrocklin.com/slides/scipy-2019#/">https://matthewrocklin.com/slides/scipy-2019#/</a>  <br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jun 4, 2019 at 12:06 AM Ralf Gommers <<a href="mailto:ralf.gommers@gmail.com">ralf.gommers@gmail.com</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"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jun 3, 2019 at 7:56 PM Sebastian Berg <<a href="mailto:sebastian@sipsolutions.net" target="_blank">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 Sun, 2019-06-02 at 08:42 +0200, Ralf Gommers wrote:<br>
> <br>
> <br>
<snip><br>
> > > <br>
> > <br>
> > This sounds like a restructuring or factorization of the API, in<br>
> > order to make it smaller, and thus easier to learn and use.<br>
> > It may start with the docs, by paying more attention to the "core"<br>
> > or important functions and methods, and noting the deprecated, or<br>
> > not frequently used, or not important functions. This could also<br>
> > help the satellite projects, which use NumPy API as an example, and<br>
> > may also be influenced by them and their decisions.<br>
> > <br>
> <br>
>  Indeed. It will help restructure our docs. Perhaps not the reference<br>
> guide (not sure yet), but definitely the user guide and other high-<br>
> level docs we (or third parties) may want to create.<br>
> <br>
<br>
Trying to follow the discussion, there seems to be various ideas? Do I<br>
understand it right that the original proposal was much like doing a<br>
list of:<br>
<br>
  * np.ndarray.cumprod: low importance -> prefer np.multiply.accumulate<br>
  * np.ravel_multi_index: low importance, but distinct feature<br></blockquote><div><br></div><div>Indeed. Certainly no more than that was my idea.</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>
Maybe with added groups such as "transpose-like" and "reshape-like"<br>
functions?<br>
This would be based on 1. "Experience" and 2. usage statistics. This<br>
seems mostly a task for 2-3 people to then throw out there for<br>
discussion.<br>
There will be some very difficult/impossible calls, since in the end<br>
Nathaniel is right, we do not quite know the question we want to<br>
answer. But for a huge part of the API it may not be problematic?<br></blockquote><div><br></div><div>Agreed, won't be problematic.<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>
Then there is an idea of providing better mixins (and tests).<br>
This could be made easier by the first idea, for prioritization.<br>
Although, the first idea is probably not really necessary to kick this<br>
off at all. The interesting parts to me seem likely how to best solve<br>
testing of the mixins and numpy-api-duplicators in general.<br>
<br>
Implementing a growing set of mixin seems likely fairly straight<br>
forwrad (although maybe much easier to approach if there is a list from<br>
the first project)? </blockquote><div><br></div><div>Indeed. I think there's actually 3 levels here (at least):</div><div>1. function name: high/low importance or some such simple classification<br></div><div>2. function signature and behavior: is the behavior optimal, what would be change, etc.</div><div>3. making duck arrays and subclasses that rely on all those functions and their behavior easier to implemement/use</div><div><br></div><div>Mixins are a specific answer to (3). And it's unclear if they're the best answer (could be, I don't know - please don't start a discussion on that here). Either way, working on (3) will be helped by having a better sense of (1) and (2). <br></div><div><br></div><div>Also think about effort: (2) is at least an order of magnitude more work than (1), and (3) likely even more work than (2).<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">And, once we have a start, maybe we can rely on the<br>
array-like implementors to be the main developers (limiting us mostly<br>
to review).<br>
<br>
<br>
The last part would be probably for users and consumers of array-likes. <br>
This largely overlaps, but comes closer to the problem of "standard".<br>
If we have a list of functions that we tend to see as more or less<br>
important, it may be interesting for downstream projects to restrict<br>
themselves to simplify interoperability e.g. with dask.<br>
<br>
Maybe we do not have to draw a strict line though? How plausible would<br>
it be to set up a list (best auto-updating) saying nothing but:<br>
<br>
`np.concatenate` supported by: dask, jax, cupy<br></blockquote><div><br></div><div>That's probably not that hard, and I agree it would be quite useful. The namespaces of each of those libraries is probably not the same, but with dir() and some strings and lists you'll get a long way here I think. <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 am not sure if this is helpful, but it feels to me that the first<br>
part is what Ralf was thinking of? Just to kick of such a a "living<br>
document".</blockquote><div><br></div><div>Indeed.</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"> I could maybe help with providing the second pair of eyes<br>
for a first iteration there, Ralf. </blockquote><div><br></div><div>Awesome, thanks Sebastian.</div><div><br></div><div>Cheers,</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">The last list I would actually find<br>
interesting myself, but not sure how easy it would be to approach it?<br>
<br>
Best,<br>
<br>
Sebastian<br>
<br>
<br>
> Ralf<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>
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>
_______________________________________________<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><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div><span style="font-size:12.8px">Mark Mikofski, PhD (2005)</span><br></div><div><span style="font-size:12.8px"><i>Fiat Lux</i></span><br></div></div></div></div>