On Sun, Jun 3, 2018 at 10:29 PM Charles R Harris <charlesr.har...@gmail.com>
wrote:

>
>
> On Sun, Jun 3, 2018 at 11:03 PM, Robert Kern <robert.k...@gmail.com>
> wrote:
>
>> On Sun, Jun 3, 2018 at 9:24 PM Charles R Harris <
>> charlesr.har...@gmail.com> wrote:
>>
>>>
>>> On Sat, Jun 2, 2018 at 1:04 PM, Robert Kern <robert.k...@gmail.com>
>>> wrote:
>>>>
>>>> This policy was first instated in Nov 2008 (in essence; the full set of
>>>> weasel
>>>>
>>>
>>> Instituted?
>>>
>>
>> I meant "instated"; c.f. for another usage:
>> https://www.youredm.com/2018/06/01/spotify-new-policy-update/
>>
>> 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
>>>> improvements
>>>> 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
>>>> increment
>>>> some version number somewhere.  ``numpy.random`` would keep all past
>>>> versions
>>>> 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
>>>> them
>>>> 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,
>>>> the
>>>> contributors that we lost while we dithered, serve as evidence against
>>>> the
>>>> notion.
>>>>
>>>> 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*
>>>> correctly.
>>>> We want to make it easy and straightforward to get the latest, fastest,
>>>> best
>>>> 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
>>>> will
>>>> 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
>>>> replicate.
>>>>
>>>> Adding in versioning to maintain stream-compatibility would still only
>>>> provide
>>>> 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.

-- 
Robert Kern
_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Reply via email to