Re: [Numpy-discussion] Behavior of np.random.uniform

I would also point out that requiring open vs closed intervals (in doubles) is already an extremely specialised use case. In terms of *sampling the reals*, there is no difference between the intervals (a,b) and [a,b], because the endpoints have measure 0, and even with double-precision arithmetic, you are going to have to make several petabytes of random data before you hit an endpoint...
Petabytes ain't what they used to be ;) I remember testing some hardware which, due to grounding/timing issues would occasionally goof up a readable register. The hardware designers never saw it because they didn't test for hours and days at high data rates. But it was there, and it would show up in the data. Measure zero is about as real as real numbers...
Chuck
Actually, your point is well taken and I am quite mistaken. If you pick some values like uniform(low, low * (1+2**-52)) then you can hit your endpoints pretty easily. I am out of practice making pathological tests for double precision arithmetic. I guess my suggestion would be to add the deprecation warning and change the docstring to warn that the interval is not guaranteed to be right-open. Peter

There doesn't seem to be much of a consensus on the way to go, so leaving things as they are and have been seems the wisest choice for now, thanks for all the feedback. I will work with Greg on documenting the status quo properly. We probably want to follow the lead of the stdlib's random.uniform on how the openness of the interval actually results in practice: https://docs.python.org/3.6/library/random.html#random.uniform On Thu, Jan 21, 2016 at 2:55 AM, Peter Creasey < p.e.creasey.00@googlemail.com> wrote:
I would also point out that requiring open vs closed intervals (in doubles) is already an extremely specialised use case. In terms of *sampling the reals*, there is no difference between the intervals (a,b) and [a,b], because the endpoints have measure 0, and even with double-precision arithmetic, you are going to have to make several petabytes of random data before you hit an endpoint...
Petabytes ain't what they used to be ;) I remember testing some hardware which, due to grounding/timing issues would occasionally goof up a readable register. The hardware designers never saw it because they didn't test for hours and days at high data rates. But it was there, and it would show up in the data. Measure zero is about as real as real numbers...
Chuck
Actually, your point is well taken and I am quite mistaken. If you pick some values like uniform(low, low * (1+2**-52)) then you can hit your endpoints pretty easily. I am out of practice making pathological tests for double precision arithmetic.
I guess my suggestion would be to add the deprecation warning and change the docstring to warn that the interval is not guaranteed to be right-open.
Peter _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
-- (\__/) ( O.o) ( > <) Este es Conejo. Copia a Conejo en tu firma y ayúdale en sus planes de dominación mundial.

On Thu, Jan 21, 2016 at 7:06 AM, Jaime Fernández del Río < jaime.frio@gmail.com> wrote:
There doesn't seem to be much of a consensus on the way to go, so leaving
things as they are and have been seems the wisest choice for now, thanks for all the feedback. I will work with Greg on documenting the status quo properly. Ugh. Be careful in documenting the way things currently work. No one intended for it to work that way! No one should rely on high<low being allowed in the future. I'm tempted to just make a PR adding the deprecation lack-of-consensus-be-damned. It is currently documented correctly for the way it is supposed to be used, and that is a good thing. Please relegate discussions of the counter-documented behavior to the Notes. -- Robert Kern
participants (3)
-
Jaime Fernández del Río
-
Peter Creasey
-
Robert Kern