<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Sep 7, 2019 at 4:16 PM Nathaniel Smith <<a href="mailto:njs@pobox.com">njs@pobox.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">On Fri, Sep 6, 2019 at 11:04 PM Ralf Gommers <<a href="mailto:ralf.gommers@gmail.com" target="_blank">ralf.gommers@gmail.com</a>> wrote:<br>
>  Vendoring means "include the code". So no dependency on an external package. If we don't vendor, it's going to be either unused, or end up as a dependency for the whole SciPy/PyData stack.<br>
<br>
If we vendor it then it also ends up as a dependency for the whole<br>
SciPy/PyData stack...<br></blockquote><div><br></div><div>It seems you're just using an unusual definition here. Dependency == a package you have to install, is present in pyproject.toml/install_requires, shows up in <a href="https://github.com/numpy/numpy/network/dependencies">https://github.com/numpy/numpy/network/dependencies</a>, etc.</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>
> Actually, now that we've discussed the fft issue, I'd suggest to change the NEP to: vendor, and make default for fft, random, and linalg.<br>
<br>
There's no way we can have an effective discussion of duck arrays, fft<br>
backends, random backends, and linalg backends all at once in a single<br>
thread.<br>
<br>
Can you write separate NEPs for each of these? Some questions I'd like<br>
to see addressed:<br>
<br>
For fft:<br>
- fft is an entirely self-contained operation, with no interactions<br>
with the rest of the system; the only difference between<br>
implementations is speed. What problems are caused by monkeypatching,<br></blockquote><div><br></div><div>It was already explained in this thread, it's been on our roadmap for ~2 years at least, and monkeypatching is pretty much universally understood to be bad. If that's not enough, please search the NumPy issues for "monkeypatching". You'll find issues like <a href="https://github.com/numpy/numpy/issues/12374#issuecomment-438725645">https://github.com/numpy/numpy/issues/12374#issuecomment-438725645</a>. At the moment this is very confusing, and hard to diagnose - you have to install a whole new NumPy and then find that the problem is gone (or not). Being able to switch backends in one line of code and re-test would be very valuable.<br></div><div><br></div><div> It seems perhaps more useful to have a call so we can communicate with higher bandwidth, rather than lots of writing new NEPs here? In preparation, we need to write up in more detail how __array_function__ and unumpy fit together, rather than treat different pieces all separately (because the problems and pros/cons really won't change much between functions and submodules). I'll defer answering your other questions till that's done, so the discussion is hopefully a bit more structured.<br></div><div><br></div><div>Cheers,</div><div>Ralf</div><div><br></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">
and how is uarray materially different from monkeypatching?<br>
<br>
For random:<br>
- I thought the new random implementation with pluggable generators<br>
etc. was supposed to solve this problem already. Why doesn't it?<br>
- The biggest issue with MKL monkeypatching random is that it breaks<br>
stream stability. How does the uarray approach address this?<br>
<br>
For linalg:<br>
- linalg already support __array_ufunc__ for overrides. Why do we need<br>
a second override system? Isn't that redundant?<br>
<br>
-n<br>
<br>
-- <br>
Nathaniel J. Smith -- <a href="https://vorpus.org" rel="noreferrer" target="_blank">https://vorpus.org</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>