On Sat, Jan 20, 2018 at 2:27 AM, <josef.p...@gmail.com> wrote: > I'm not sure I fully understand > Is the proposal to drop stream-backward compatibility completely for the future or just a one time change?
For all future. > > No version-selection API would be required as you select the version by installing the desired version of numpy. > > That's not useful if we want to have unit tests that run in the same way across numpy versions. > > There are many unit tests that rely on fixed streams and have hard coded results that rely on specific numbers (up to floating point, numerical noise). > Giving up stream compatibility would essentially kill using np.random for these unit tests. This is a use case that I am sensitive to. However, it should be noted that relying on the exact stream for unit tests makes you vulnerable to platform differences. That's something that we've never guaranteed (because we can't). That said, there are some of the simpler distributions that are more robust to such things, and those are fairly typical in unit tests. As I mentioned, I am open to a small set of methods that we do guarantee stream-compatibility for. I think that unit tests are the obvious use case that should determine what that set is. Unit tests rarely need `noncentral_chisquare()`, for instance. I'd also be willing to make the API a little clunkier in order to maintain the stable set of methods. For example, two methods that are common in unit testing are `normal()` and `choice()`, but those have been the target of the most attempted innovation. I'd be willing to leave them alone while providing other methods that do the same thing but are allowed to innovate. > Similar, reproducibility from another user, e.g. in notebooks, would break without stream compatibility across numpy versions. That is the reproducible-research use case that I discussed already. I argued that the stability that our policy actually provides is rather more muted than what it seems on its face. > One possibility is to keep the current stream-compatible np.random version and maintain it in future for those usecases, and add a new "high-performance" version with the new features. That is one of the alternatives I raised. -- Robert Kern
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
