On Sun, May 24, 2015 at 11:13 AM, Anne Archibald <archibald@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. 

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. 

Reminder: we are bottom or inline posting

 


Anne

On Sun, May 24, 2015 at 5:04 PM <josef.pktd@gmail.com> wrote:
On Sun, May 24, 2015 at 9:08 AM, Alan G Isaac <alan.isaac@gmail.com> wrote:
On 5/24/2015 8:47 AM, Ralf Gommers wrote:
> Values only change if you leave out the call to seed()


OK, but this claim seems to conflict with the following language:
"the global RandomState object should use the latest implementation of the methods".
I take it that this is what Nathan meant by
"I think this is just a bug in the description of the proposal here, not in the proposal itself".

So, is the correct phrasing
"the global RandomState object should use the latest implementation of the methods, unless explicitly seeded"?

that's how I understand it.

I don't see any problems with the clarified proposal for the use cases that I know of.

Can we choose the version also for the global random state, for example to fix both version and seed in unit tests, with version > 0?


BTW: I would expect that bug fixes are still exempt from backwards compatibility.

fixing #5851 should be independent of the version, (without having looked at the issue)

I skimmed the issue. 
In a strict sense it's not really a bug, the user doesn't get wrong numbers, he or she gets Not A Number.

So there are no current usages that use the function in that range.

Josef

 

(If you need to replicate bugs, then use an old version of a package.)

Josef
 

Thanks,
Alan
_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion