<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Sun, Jun 3, 2018 at 6:01 PM <<a href="mailto:josef.pktd@gmail.com">josef.pktd@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"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Jun 3, 2018 at 8:36 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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><span><div dir="ltr">On Sun, Jun 3, 2018 at 4:35 PM Eric Wieser <<a href="mailto:wieser.eric%2Bnumpy@gmail.com" target="_blank">wieser.eric+numpy@gmail.com</a>> wrote:<br></div></span><span><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 class="m_-7451846191987309144gmail-m_-6094868146745275123m_-8997880885796611111m_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></div></div></blockquote></span><div>By the way, the reason that I didn't mention this use case as a motivation in the Status Quo section because, as I reviewed my mail archive, this wasn't actually a motivating use case for the policy. It's certainly a use case that developed once we did make these (*cough*extravagant*cough*) guarantees, though, as people started to rely on it, and I hope that my StableRandom proposal addresses it to your satisfaction.<span style="color:rgb(34,34,34);font-family:sans-serif;font-size:13px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span> </span>I could add some more details about that history if you think it would be useful.</span></div></div></div></blockquote><div><br></div><div>I don't think that's accurate.</div><div>The unit tests for stable random numbers were added when Enthought silently changed the normal random numbers and we got messages from users that the unit tests fail and they cannot reproduce our results.</div><div><br></div><div>6/12/10</div><div>[SciPy-Dev] seeded randn gets different values on osx<br></div><div><br></div><div>(I don't find an online copy, this is from my own mail archive)</div></div></div></div></blockquote><div><br></div><div>The policy was in place Nov 2008.</div></div><div><br></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">Robert Kern</div></div>