<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Sun, Jun 3, 2018 at 4:35 PM Eric Wieser <<a href="mailto:wieser.eric%2Bnumpy@gmail.com">wieser.eric+numpy@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="m_9031842199576249835markdown-here-wrapper" style="font-size:1em;font-family:Helvetica,arial,freesans,clean,sans-serif;color:rgb(34,34,34);background-color:rgb(255,255,255);border:none;line-height:1.2"><p style="margin:1em 0px">You make a bunch of good points refuting reproducible research as an argument for not changing the random number streams.</p>
<p style="margin:1em 0px">However, there’s a second use-case you don’t address - unit tests. For better or worse, downstream, or <a href="https://github.com/numpy/numpy/blob/c4813a9/numpy/core/tests/test_multiarray.py#L5093-L5108" style="color:rgb(51,51,238);text-decoration:none" target="_blank">even our own</a>, unit tests use a seeded random number generator as a shorthand to produce some arbirary array, and then hard-code the expected output in their tests. Breaking stream compatibility will break these tests.</p>
<p style="margin:1em 0px">I don’t think writing tests in this way is particularly good idea, but unfortunately they do still exist.</p>
<p style="margin:1em 0px">It would be good to address this use case in the NEP, even if the conclusion is just “changing the stream will break tests of this form”</p></div></div></blockquote><div><br></div><div>I do! Search for "unit test" or "StableRandom". :-) </div></div><div><br></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">Robert Kern</div></div>