On Di, 2016-01-19 at 16:28 +0000, G Young wrote:
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.
Well, actually random.uniform docstring says: Get a random number in the range [a, b) or [a, b] depending on rounding. and is true to the word, it does not care about the relative value of a vs. b. So my guess it is identical to your version (though one could check a bit more careful with corner cases) Quick check would suggests it is the same (though I guess if there was a slight rounding issue somewhere, it could be different):
np.random.set_state(('MT19937', random.getstate()[1][:-1], random.getstate()[1][-1]))
Will enable you to draw the same numbers with random.uniform and np.random.uniform. - Sebastian
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) 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