On May 24, 2015 8:15 AM, "Anne Archibald" <archib...@astron.nl> wrote: > > Do we want a deprecation-like approach, so that eventually people who want replicability will specify versions, and everyone else gets bug fixes and improvements? This would presumably take several major versions, but it might avoid people getting unintentionally trapped on this version.
I'm not sure what you're envisioning as needing a deprecation cycle? The neat thing about random is that we already have a way for users to say that they want replicability -- the use of an explicit seed -- so we can just immediately go to the world you describe, where people who seed get to pick their version (or default to version 0 for backcompat), and everyone else gets the improvements automatically. Or is this different from what you meant somehow? Fortunately we haven't yet run into any really serious bugs in random, like "oops we're sampling from the wrong distribution" type bugs. Mostly it's more like "oops this is really inefficient" or "oops this crashes in this edge case", so there's no real harm in letting people use old versions. If we did run into a case where we were giving flat out wrong results, then I guess we'd still want to keep the code around because reproducibility is still important, but perhaps with a requirement that you pass an extra argument like I_know_its_broken=True or something so that people couldn't end up running the broken code accidentally? I guess we'll cross that bridge when we come to it. > Incidentally, bug fixes are complicated: if a bug fix uses more or fewer raw random numbers, it breaks repeatability not just for the call that got fixed but for all successive random number generations. Yep. This is why we mostly haven't been able to change behavior at *all* except in cases where there was a clear error so we know no-one was using something. -n
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
