<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Jun 10, 2018 at 5:57 PM, Robert Kern <span dir="ltr"><<a href="mailto:robert.kern@gmail.com" target="_blank">robert.kern@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span class="">On Sun, Jun 10, 2018 at 5:47 PM Ralf Gommers <<a href="mailto:ralf.gommers@gmail.com" target="_blank">ralf.gommers@gmail.com</a>> wrote:<br>><br>> On Sun, Jun 3, 2018 at 9:23 PM, Warren Weckesser <<a href="mailto:warren.weckesser@gmail.com" target="_blank">warren.weckesser@gmail.com</a>> wrote:<br><br></span><span class="">>> I suspect many of the tests will be easy to update, so fixing 300 or so tests does not seem like a monumental task. <br>><br>> It's all not monumental, but it adds up quickly. In addition to changing tests, one will also need compatibility code when supporting multiple numpy versions (e.g. scipy when get a copy of RandomStable in scipy/_lib/_numpy_compat.py).<br>><br>> A quick count of just np.random.seed occurrences with ``$ grep -roh --include \*.py np.random.seed . | wc -w`` for some packages:<br>> numpy: 77<br>> scipy: 462<br>> matplotlib: 204<br>> statsmodels: 461<br>> pymc3: 36<br>> scikit-image: 63<br>> scikit-learn: 69<br>> keras: 46<br>> pytorch: 0<br>> tensorflow: 368<br>> astropy: 24<br>><br>> And note, these are *not* incorrect/broken usages, this is code that works and has done so for years.<br><br></span>Yes, some of them are incorrect and broken. Failure can be difficult to detect. This module from keras is particularly problematic:<div><br></div><div>  <a href="https://github.com/keras-team/keras-preprocessing/blob/master/keras_preprocessing/image.py" target="_blank">https://github.com/keras-team/<wbr>keras-preprocessing/blob/<wbr>master/keras_preprocessing/<wbr>image.py</a><span class=""><br></span></div></div></blockquote><div><br></div><div>You have to appreciate that we're not all thinking at lightning speed and in the same direction. If there is a difficult to detect problem, it may be useful to give a brief code example (or even line of reasoning) of how this actually breaks something. <br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><span class=""><br>> Conclusion: the current proposal will cause work for the vast majority of libraries that depends on numpy. The total amount of that work will certainly not be counted in person-days/weeks, and more likely in years than months. So I'm not convinced yet that the current proposal is the best way forward.<br><br></span>The mere usage of np.random.seed() doesn't imply that these packages actually require stream-compatibility. Some might, for sure, like where they are used in the unit tests, but that's not what you counted. At best, these numbers just mean that we can't eliminate np.random.seed() in a new system right away.<br></div></div></blockquote><div><br></div><div>Well, mere usage has been called an antipattern (also on your behalf), plus for scipy over half of the usages do give test failures (Warren's quick test). So I'd say that counting usages is a decent proxy for the work that has to be done.</div><div><br></div>Cheers,<br></div><div class="gmail_quote">Ralf</div><div class="gmail_quote"><br></div><br></div></div>