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.bar...@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 <gfyoun...@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.r...@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.f...@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 > >
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
