[Numpy-discussion] Backwards-incompatible improvements to numpy.random.RandomState

[josef.pktd at gmail.com]

On Sun, May 24, 2015 at 11:13 AM, Anne Archibald <archibald at 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 at gmail.com> wrote:
>
>> On Sun, May 24, 2015 at 9:08 AM, Alan G Isaac <alan.isaac at 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 at scipy.org
>>> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>>>
>> _______________________________________________
>> NumPy-Discussion mailing list
>> NumPy-Discussion at scipy.org
>> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>>
>
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20150524/2b8ec346/attachment.html>