Re: [Numpy-discussion] NEP: Random Number Generator Policy

On Sun, Jun 3, 2018 at 10:27 PM wrote: > > > On Mon, Jun 4, 2018 at 12:53 AM, Stephan Hoyer wrote: > >> On Sun, Jun 3, 2018 at 8:22 PM Ralf Gommers >> wrote: >> >>> It may be worth having a look at test suites for scipy, statsmodels, >>> scikit-learn, etc. and estimate how much work this NEP ca

Re: [Numpy-discussion] NEP: Dispatch Mechanism for NumPy’s high level API

On Sun, Jun 3, 2018 at 9:54 PM Hameer Abbasi wrote: > Mixed return values of NotImplementedButCoercible and NotImplemented would > still result in TypeError, and there would be no second chances for > overloads. > > > I would like to differ with you here: It can be quite useful to have > second c

Re: [Numpy-discussion] NEP: Random Number Generator Policy

On Sun, Jun 3, 2018 at 11:07 PM Kevin Sheppard wrote: > The seed() discussion seems unnecessary. StableRandom will need to have a > method to set/get state > > which can be used by any project that needs to get reproducible numbers > from the module-level generator. > > > > While this is an impl

Re: [Numpy-discussion] NEP: Random Number Generator Policy

The seed() discussion seems unnecessary. StableRandom will need to have a method to set/get state which can be used by any project that needs to get reproducible numbers from the module-level generator. While this is an implementation detail, many generators have much smaller states than MT199

Re: [Numpy-discussion] NEP: Random Number Generator Policy

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." S

Re: [Numpy-discussion] NEP: Random Number Generator Policy

On Sun, Jun 3, 2018 at 10:29 PM Charles R Harris wrote: > > > On Sun, Jun 3, 2018 at 11:03 PM, Robert Kern > 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 >>> wrote: This policy

Re: [Numpy-discussion] NEP: Random Number Generator Policy

On Sun, Jun 3, 2018 at 11:03 PM, Robert Kern wrote: > On Sun, Jun 3, 2018 at 9:24 PM Charles R Harris > wrote: > >> >> On Sat, Jun 2, 2018 at 1:04 PM, Robert Kern >> wrote: >>> >>> This policy was first instated in Nov 2008 (in essence; the full set of >>> weasel >>> >> >> Instituted? >> > > I

Re: [Numpy-discussion] NEP: Random Number Generator Policy

On Mon, Jun 4, 2018 at 12:53 AM, Stephan Hoyer wrote: > On Sun, Jun 3, 2018 at 8:22 PM Ralf Gommers > wrote: > >> It may be worth having a look at test suites for scipy, statsmodels, >> scikit-learn, etc. and estimate how much work this NEP causes those >> projects. If the devs of those packages

Re: [Numpy-discussion] NEP: Random Number Generator Policy

On Sun, Jun 3, 2018 at 9:24 PM Charles R Harris wrote: > > On Sat, Jun 2, 2018 at 1:04 PM, Robert Kern 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/

Re: [Numpy-discussion] NEP: Random Number Generator Policy

On Sun, Jun 3, 2018 at 8:22 PM Ralf Gommers wrote: > It may be worth having a look at test suites for scipy, statsmodels, > scikit-learn, etc. and estimate how much work this NEP causes those > projects. If the devs of those packages are forced to do large scale > migrations from RandomState to S

Re: [Numpy-discussion] NEP: Dispatch Mechanism for NumPy’s high level API

Mixed return values of NotImplementedButCoercible and NotImplemented would still result in TypeError, and there would be no second chances for overloads. I would like to differ with you here: It can be quite useful to have second chances for overloads. Think ``np.func(list, custom_array))``: If s

Re: [Numpy-discussion] NEP: Random Number Generator Policy

On Sun, Jun 3, 2018 at 11:20 PM, Ralf Gommers wrote: > > > On Sun, Jun 3, 2018 at 6:54 PM, wrote: > >> >> >> On Sun, Jun 3, 2018 at 9:08 PM, Robert Kern >> wrote: >> >>> On Sun, Jun 3, 2018 at 5:46 PM wrote: >>> On Sun, Jun 3, 2018 at 8:21 PM, Robert Kern wrote: >

Re: [Numpy-discussion] NEP: Random Number Generator Policy

On Sat, Jun 2, 2018 at 1:04 PM, Robert Kern wrote: > As promised distressingly many months ago, I have written up a NEP about > relaxing the stream-compatibility policy that we currently have. > > https://github.com/numpy/numpy/pull/11229 > https://github.com/rkern/numpy/blob/nep/rng/doc/neps/ >

Re: [Numpy-discussion] NEP: Random Number Generator Policy

On Sun, Jun 3, 2018 at 6:54 PM, wrote: > > > On Sun, Jun 3, 2018 at 9:08 PM, Robert Kern wrote: > >> On Sun, Jun 3, 2018 at 5:46 PM wrote: >> >>> >>> >>> On Sun, Jun 3, 2018 at 8:21 PM, Robert Kern >>> wrote: >>> The list of ``StableRandom`` methods should be chosen to support unit >

Re: [Numpy-discussion] NEP: Dispatch Mechanism for NumPy’s high level API

On Sun, Jun 3, 2018 at 5:44 PM Marten van Kerkwijk < m.h.vankerkw...@gmail.com> wrote: > Although I'm still not 100% convinced by NotImplementedButCoercible, I do > like the idea that this is the default for items that do not implement > `__array_function__`. And it might help avoid trying to find

Re: [Numpy-discussion] NEP: Random Number Generator Policy

On Sun, Jun 3, 2018 at 5:39 PM Robert Kern wrote: > You and I both agree that this is an anti-pattern for numpy.random, but >> certainly there is plenty of code that relies on the stability of random >> numbers when seeds are set by np.random.seed(). Similar to the case for >> RandomState, we wou

Re: [Numpy-discussion] NEP: Random Number Generator Policy

On Sun, Jun 3, 2018 at 9:08 PM, Robert Kern wrote: > On Sun, Jun 3, 2018 at 5:46 PM wrote: > >> >> >> On Sun, Jun 3, 2018 at 8:21 PM, Robert Kern >> wrote: >> >>> >>> The list of ``StableRandom`` methods should be chosen to support unit tests: * ``.randint()`` * ``.u

Re: [Numpy-discussion] NEP: Random Number Generator Policy

On Sun, Jun 3, 2018 at 6:26 PM wrote: > > > On Sun, Jun 3, 2018 at 9:04 PM, Robert Kern wrote: > >> On Sun, Jun 3, 2018 at 6:01 PM wrote: >> >>> >>> >>> On Sun, Jun 3, 2018 at 8:36 PM, Robert Kern >>> wrote: >>> On Sun, Jun 3, 2018 at 4:35 PM Eric Wieser wrote: > You make a

Re: [Numpy-discussion] NEP: Random Number Generator Policy

On Sat, Jun 2, 2018 at 3:04 PM, Robert Kern wrote: > As promised distressingly many months ago, I have written up a NEP about > relaxing the stream-compatibility policy that we currently have. > > https://github.com/numpy/numpy/pull/11229 > https://github.com/rkern/numpy/blob/nep/rng/doc/neps/ >

Re: [Numpy-discussion] NEP: Random Number Generator Policy

On Sun, Jun 3, 2018 at 9:04 PM, Robert Kern wrote: > On Sun, Jun 3, 2018 at 6:01 PM wrote: > >> >> >> On Sun, Jun 3, 2018 at 8:36 PM, Robert Kern >> wrote: >> >>> On Sun, Jun 3, 2018 at 4:35 PM Eric Wieser >>> wrote: >>> You make a bunch of good points refuting reproducible research as an

Re: [Numpy-discussion] NEP: Random Number Generator Policy

On Sun, Jun 3, 2018 at 5:46 PM wrote: > > > On Sun, Jun 3, 2018 at 8:21 PM, Robert Kern wrote: > >> >> The list of ``StableRandom`` methods should be chosen to support unit >>> tests: >>> >>> * ``.randint()`` >>> * ``.uniform()`` >>> * ``.normal()`` >>> * ``.standard_normal()`` >

Re: [Numpy-discussion] NEP: Random Number Generator Policy

On Sun, Jun 3, 2018 at 6:01 PM wrote: > > > On Sun, Jun 3, 2018 at 8:36 PM, Robert Kern wrote: > >> On Sun, Jun 3, 2018 at 4:35 PM Eric Wieser >> wrote: >> >>> You make a bunch of good points refuting reproducible research as an >>> argument for not changing the random number streams. >>> >>> H

Re: [Numpy-discussion] NEP: Random Number Generator Policy

On Sun, Jun 3, 2018 at 8:36 PM, Robert Kern wrote: > On Sun, Jun 3, 2018 at 4:35 PM Eric Wieser > wrote: > >> You make a bunch of good points refuting reproducible research as an >> argument for not changing the random number streams. >> >> However, there’s a second use-case you don’t address -

Re: [Numpy-discussion] NEP: Random Number Generator Policy

On Sun, Jun 3, 2018 at 8:21 PM, Robert Kern wrote: > Moving some of the Github PR comments here: > > Implementation >> -- >> >> We propose first freezing ``RandomState`` as it is and developing a new >> RNG >> subsystem alongside it. This allows anyone who has been relying on our >>

Re: [Numpy-discussion] NEP: Dispatch Mechanism for NumPy’s high level API

This in certainly true in general, but given the complete flexibility of __array_function__ there's no way we can make every check convenient. The best we can do is make it easy to handle the common cases, where the argument position does not matter. I think those cases may not be as common as you

Re: [Numpy-discussion] NEP: Dispatch Mechanism for NumPy’s high level API

Although I'm still not 100% convinced by NotImplementedButCoercible, I do like the idea that this is the default for items that do not implement `__array_function__`. And it might help avoid trying to find oneself in a possibly long list. -- Marten ___ N

Re: [Numpy-discussion] NEP: Random Number Generator Policy

On Sun, Jun 3, 2018 at 5:23 PM Stephan Hoyer wrote: > On Sat, Jun 2, 2018 at 12:06 PM Robert Kern wrote: > >> We propose first freezing ``RandomState`` as it is and developing a new >> RNG >> subsystem alongside it. This allows anyone who has been relying on our >> old >> stream-compatibility g

Re: [Numpy-discussion] NEP: Random Number Generator Policy

On Sun, Jun 3, 2018 at 4:35 PM Eric Wieser wrote: > You make a bunch of good points refuting reproducible research as an > argument for not changing the random number streams. > > However, there’s a second use-case you don’t address - unit tests. For > better or worse, downstream, or even our own

Re: [Numpy-discussion] NEP: Random Number Generator Policy

Moving some of the Github PR comments here: Implementation > -- > > We propose first freezing ``RandomState`` as it is and developing a new RNG > subsystem alongside it. This allows anyone who has been relying on our old > stream-compatibility guarantee to have plenty of time to migra

Re: [Numpy-discussion] NEP: Random Number Generator Policy

On Sat, Jun 2, 2018 at 12:06 PM Robert Kern wrote: > We propose first freezing ``RandomState`` as it is and developing a new RNG > subsystem alongside it. This allows anyone who has been relying on our old > stream-compatibility guarantee to have plenty of time to migrate. > ``RandomState`` will

Re: [Numpy-discussion] NEP: Dispatch Mechanism for NumPy’s high level API

On Sun, Jun 3, 2018 at 4:25 PM Marten van Kerkwijk < m.h.vankerkw...@gmail.com> wrote: > I think one might still want to know *where* the type occurs (e.g., as an > output or index would have different implications). > This in certainly true in general, but given the complete flexibility of __arr

Re: [Numpy-discussion] NEP: Random Number Generator Policy

On Sun, Jun 3, 2018 at 4:35 PM Eric Wieser wrote: > You make a bunch of good points refuting reproducible research as an > argument for not changing the random number streams. > > However, there’s a second use-case you don’t address - unit tests. For > better or worse, downstream, or even our own

Re: [Numpy-discussion] NEP: Random Number Generator Policy

You make a bunch of good points refuting reproducible research as an argument for not changing the random number streams. However, there’s a second use-case you don’t address - unit tests. For better or worse, downstream, or even our own

Re: [Numpy-discussion] NEP: Dispatch Mechanism for NumPy’s high level API

On Sun, Jun 3, 2018 at 11:12 AM Marten van Kerkwijk < m.h.vankerkw...@gmail.com> wrote: > On Sun, Jun 3, 2018 at 2:00 PM, Hameer Abbasi > wrote: > >> >>- Objects that don’t implement ``__array_function__`` should be >>treated as having returned ``np.NotImplementedButCoercible``. >>

Re: [Numpy-discussion] NEP: Dispatch Mechanism for NumPy’s high level API

> > In most cases, I suspect that the overhead of a function call and checking > several arguments for "__array_function__" will be negligible, like the > situation for __array_ufunc__. I'm not strongly opposed to either of your > proposed solutions, but I do think it would be a little strange to i

Re: [Numpy-discussion] NEP: Random Number Generator Policy

On Sat, Jun 2, 2018 at 3:04 PM, Robert Kern wrote: > As promised distressingly many months ago, I have written up a NEP about > relaxing the stream-compatibility policy that we currently have. > > https://github.com/numpy/numpy/pull/11229 > https://github.com/rkern/numpy/blob/nep/rng/doc/neps/ >

Re: [Numpy-discussion] NEP: Dispatch Mechanism for NumPy’s high level API

On Sun, Jun 3, 2018 at 8:19 AM Marten van Kerkwijk < m.h.vankerkw...@gmail.com> wrote: > My more general comment is one of speed: for *normal* operation > performance should be impacted as minimally as possible. I think this is a > serious issue and feel strongly it *has* to be possible to avoid a

Re: [Numpy-discussion] NEP: Dispatch Mechanism for NumPy’s high level API

I also am not sure there is an actual problem: In the scheme as proposed, implementations could just coerce themselves to array and call the routine again. (Or, in the scheme I proposed, call the routine again but with `coerce=True`.) Ah, I didn’t think of the first solution. `coerce=True` may no

Re: [Numpy-discussion] NEP: Dispatch Mechanism for NumPy’s high level API

On Sun, Jun 3, 2018 at 2:00 PM, Hameer Abbasi wrote: > The rules for dispatch with ``__array_function__`` match those for > ``__array_ufunc__`` (see > `NEP-13 `_). > In particular: > > - NumPy will gather implementations of ``__array_funct

Re: [Numpy-discussion] NEP: Dispatch Mechanism for NumPy’s high level API

The rules for dispatch with ``__array_function__`` match those for ``__array_ufunc__`` (see `NEP-13 `_). In particular: - NumPy will gather implementations of ``__array_function__`` from all specified inputs and call them in order: subcl

Re: [Numpy-discussion] NEP: Dispatch Mechanism for NumPy’s high level API

Hi Stephan, Thanks for posting. Overall, this is great! My more general comment is one of speed: for *normal* operation performance should be impacted as minimally as possible. I think this is a serious issue and feel strongly it *has* to be possible to avoid all arguments being checked for the `