[Numpy-discussion] NEP: Random Number Generator Policy
einstein.edison at gmail.com
Mon Jun 4 01:55:17 EDT 2018
How about this:
"There will be no concept of a separate RNG version. In order to get
consistent or reproducible results from the RNG, it will be necessary to
specify the NumPy version that was used to generate those results. Results
from the RNG may change across different releases of Num Py."
Sent from Astro <https://www.helloastro.com> for Mac
On 4. Jun 2018 at 10:47, Robert Kern <robert.kern at gmail.com> wrote:
On Sun, Jun 3, 2018 at 10:29 PM Charles R Harris <charlesr.harris at gmail.com>
> On Sun, Jun 3, 2018 at 11:03 PM, Robert Kern <robert.kern at gmail.com>
>> On Sun, Jun 3, 2018 at 9:24 PM Charles R Harris <
>> charlesr.harris at gmail.com> wrote:
>>> On Sat, Jun 2, 2018 at 1:04 PM, Robert Kern <robert.kern at gmail.com>
>>>> This policy was first instated in Nov 2008 (in essence; the full set of
>> I meant "instated"; c.f. for another usage:
>> But "instituted" would work just as well. It may be that "instated a
>> policy" is just an idiosyncratic back-formation of "reinstated a policy",
>> which even to me feels more right.
>> Not Versioning
>>>> For a long time, we considered that the way to allow algorithmic
>>>> while maintaining the stream was to apply some form of versioning.
>>>> That is,
>>>> every time we make a stream change in one of the distributions, we
>>>> some version number somewhere. ``numpy.random`` would keep all past
>>>> of the code, and there would be a way to get the old versions.
>>>> Proposals of
>>>> how to do this exactly varied widely, but we will not exhaustively list
>>>> here. We spent years going back and forth on these designs and were
>>>> not able
>>>> to find one that sufficed. Let that time lost, and more importantly,
>>>> contributors that we lost while we dithered, serve as evidence against
>>>> Concretely, adding in versioning makes maintenance of ``numpy.random``
>>>> difficult. Necessarily, we would be keeping lots of versions of the
>>>> same code
>>>> around. Adding a new algorithm safely would still be quite hard.
>>>> But most importantly, versioning is fundamentally difficult to *use*
>>>> We want to make it easy and straightforward to get the latest, fastest,
>>>> versions of the distribution algorithms; otherwise, what's the point?
>>>> The way
>>>> to make that easy is to make the latest the default. But the default
>>>> necessarily change from release to release, so the user’s code would
>>>> need to be
>>>> altered anyway to specify the specific version that one wants to
>>>> Adding in versioning to maintain stream-compatibility would still only
>>>> the same level of stream-compatibility that we currently do, with all
>>>> of the
>>>> limitations described earlier. Given that the standard practice for
>>>> such needs
>>>> is to pin the release of ``numpy`` as a whole, versioning
>>>> ``RandomState`` alone
>>>> is superfluous.
>>> This section is a bit unclear. Would it be correct to say that the rng
>>> version is the numpy version? If so, it might be best to say that up front
>>> before justifying it.
>> I'm sorry, I'm unclear on what you are asking me to make clearer. There
>> is currently no such thing as "the rng version". The thrust of this section
>> of the NEP is to reject the previously floated idea of introducing the
>> concept at all. So I would certainly not say anything along the lines that
>> "the rng version is the numpy version". I do say, here and earlier, that
>> the way to get the same RNG code is to get the same version of numpy.
> Just so, and you could make that clearer, as you do here.
I don't understand. All I did was repeat what I already said twice. If
you'd like to provide some text that would have clarified things for you,
I'll see about inserting it, but I'm at a loss for writing that text.
NumPy-Discussion mailing list
NumPy-Discussion at python.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the NumPy-Discussion