In rand range, it raises an exception if low >= high. I should also add that AFAIK enforcing low >= high with floats is a lot trickier than it is for integers. I have been knee-deep in corner cases for some time with *randint* where numbers that are visually different are cast as the same number by *numpy* due to rounding and representation issues. That situation only gets worse with floats. Greg On Tue, Jan 19, 2016 at 4:23 PM, Chris Barker - NOAA Federal < chris.barker@noaa.gov> wrote:
What does the standard lib do for rand range? I see that randint Is closed on both ends, so order doesn't matter, though if it raises for b<a, then that's a precedent we could follow.
(Sorry, on a phone, can't check)
CHB
On Jan 19, 2016, at 6:21 AM, G Young <gfyoung17@gmail.com> wrote:
Of the methods defined in *numpy/mtrand.pyx* (excluding helper functions and *random_integers*, as they are all related to *randint*), *randint* is the only other function with *low* and *high* parameters. However, it enforces *high* > *low*.
Greg
On Tue, Jan 19, 2016 at 1:36 PM, Benjamin Root <ben.v.root@gmail.com> wrote:
Are there other functions where this behavior may or may not be happening? If it isn't consistent across all np.random functions, it probably should be, one way or the other.
Ben Root
On Tue, Jan 19, 2016 at 5:10 AM, Jaime Fernández del Río < jaime.frio@gmail.com> wrote:
Hi all,
There is a PR (#7026 <https://github.com/numpy/numpy/pull/7026>) that documents the current behavior of np.random.uniform when the low and high parameters it takes do not conform to the expected low < high. Basically:
- if low < high, random numbers are drawn from [low, high), - if low = high, all random numbers will be equal to low, and - if low > high, random numbers are drawn from (high, low] (notice the change in the open side of the interval.)
My only worry is that, once we document this, we can no longer claim that it is a bug. So I would like to hear from others what do they think. The other more or less obvious options would be to:
- Raise an error, but this would require a deprecation cycle, as people may be relying on the current undocumented behavior. - Check the inputs and draw numbers from [min(low, high), max(low, high)), which is minimally different from current behavior.
I will be merging the current documentation changes in the next few days, so it would be good if any concerns were voiced before that.
Thanks,
Jaime
-- (\__/) ( O.o) ( > <) Este es Conejo. Copia a Conejo en tu firma y ayúdale en sus planes de dominación mundial.
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion