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.