Behavior of np.random.uniform
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.
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
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
For what it is worth, the current behaviour seems the most logical to me, i.e., that the first limit is always the one that is included in the interval, and the second is not. -- Marten
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
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
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
On Tue, Jan 19, 2016 at 5:35 PM, Sebastian Berg <sebastian@sipsolutions.net> wrote:
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.
Which docstring are you looking at? The current one says [low, high) http://docs.scipy.org/doc/numpy/reference/generated/numpy.random.uniform.htm... -- Robert Kern
On Do, 2016-01-21 at 09:38 +0000, Robert Kern wrote:
On Tue, Jan 19, 2016 at 5:35 PM, Sebastian Berg < sebastian@sipsolutions.net> wrote:
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.
Which docstring are you looking at? The current one says [low, high)
Sorry, I was referring to the python random.uniform function. And as far as I now understand the current numpy equivalent (intentionally or not) seems to do the same thing, which suits fine with me. - Sebastian
http://docs.scipy.org/doc/numpy/reference/generated/numpy.random.unif orm.html#numpy.random.uniform
-- Robert Kern _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
On Tue, Jan 19, 2016 at 9:23 AM, 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.
randint is not closed on the high end. The now deprecated random_integers is the function that does that. For floats, it's good to have various interval options. For instance, in generating numbers that will be inverted or have their log taken it is good to avoid zero. However, the names 'low' and 'high' are misleading... Chuck
On Tue, Jan 19, 2016 at 10:27 AM, Charles R Harris < charlesr.harris@gmail.com> wrote:
On Tue, Jan 19, 2016 at 9:23 AM, 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.
randint is not closed on the high end. The now deprecated random_integers is the function that does that.
For floats, it's good to have various interval options. For instance, in generating numbers that will be inverted or have their log taken it is good to avoid zero. However, the names 'low' and 'high' are misleading...
Note that we also have both arange and linspace for floats. What works well for integers is not always the best for floats. Chuck
On Tue, Jan 19, 2016 at 5:27 PM, Charles R Harris <charlesr.harris@gmail.com> wrote:
On Tue, Jan 19, 2016 at 9:23 AM, 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.
randint is not closed on the high end. The now deprecated random_integers
is the function that does that.
For floats, it's good to have various interval options. For instance, in
generating numbers that will be inverted or have their log taken it is good to avoid zero. However, the names 'low' and 'high' are misleading... They are correctly leading the users to the manner in which the author intended the function to be used. The *implementation* is misleading by allowing users to do things contrary to the documented intent. ;-) With floating point and general intervals, there is not really a good way to guarantee that the generated results avoid the "open" end of the specified interval or even stay *within* that interval. This function is definitely not intended to be used as `uniform(closed_end, open_end)`. -- Robert Kern
On Tue, Jan 19, 2016 at 10:36 AM, Robert Kern <robert.kern@gmail.com> wrote:
On Tue, Jan 19, 2016 at 5:27 PM, Charles R Harris < charlesr.harris@gmail.com> wrote:
On Tue, Jan 19, 2016 at 9:23 AM, 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.
randint is not closed on the high end. The now deprecated random_integers is the function that does that.
For floats, it's good to have various interval options. For instance, in generating numbers that will be inverted or have their log taken it is good to avoid zero. However, the names 'low' and 'high' are misleading...
They are correctly leading the users to the manner in which the author intended the function to be used. The *implementation* is misleading by allowing users to do things contrary to the documented intent. ;-)
With floating point and general intervals, there is not really a good way to guarantee that the generated results avoid the "open" end of the specified interval or even stay *within* that interval. This function is definitely not intended to be used as `uniform(closed_end, open_end)`.
Well, it is possible to make that happen if one is careful or directly sets the bits in ieee types... Chuck
On Tue, Jan 19, 2016 at 5:40 PM, Charles R Harris <charlesr.harris@gmail.com> wrote:
On Tue, Jan 19, 2016 at 10:36 AM, Robert Kern <robert.kern@gmail.com>
On Tue, Jan 19, 2016 at 5:27 PM, Charles R Harris <
charlesr.harris@gmail.com> wrote:
On Tue, Jan 19, 2016 at 9:23 AM, 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,
wrote: then that's a precedent we could follow.
randint is not closed on the high end. The now deprecated
random_integers is the function that does that.
For floats, it's good to have various interval options. For instance,
in generating numbers that will be inverted or have their log taken it is good to avoid zero. However, the names 'low' and 'high' are misleading...
They are correctly leading the users to the manner in which the author intended the function to be used. The *implementation* is misleading by allowing users to do things contrary to the documented intent. ;-)
With floating point and general intervals, there is not really a good way to guarantee that the generated results avoid the "open" end of the specified interval or even stay *within* that interval. This function is definitely not intended to be used as `uniform(closed_end, open_end)`.
Well, it is possible to make that happen if one is careful or directly sets the bits in ieee types...
For the unit interval, certainly. For general bounds, I am not so sure. -- Robert Kern
On Tue, Jan 19, 2016 at 10:42 AM, Robert Kern <robert.kern@gmail.com> wrote:
On Tue, Jan 19, 2016 at 5:40 PM, Charles R Harris < charlesr.harris@gmail.com> wrote:
On Tue, Jan 19, 2016 at 10:36 AM, Robert Kern <robert.kern@gmail.com>
On Tue, Jan 19, 2016 at 5:27 PM, Charles R Harris <
charlesr.harris@gmail.com> wrote:
On Tue, Jan 19, 2016 at 9:23 AM, 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,
wrote: then that's a precedent we could follow.
randint is not closed on the high end. The now deprecated
random_integers is the function that does that.
For floats, it's good to have various interval options. For instance,
in generating numbers that will be inverted or have their log taken it is good to avoid zero. However, the names 'low' and 'high' are misleading...
They are correctly leading the users to the manner in which the author intended the function to be used. The *implementation* is misleading by allowing users to do things contrary to the documented intent. ;-)
With floating point and general intervals, there is not really a good way to guarantee that the generated results avoid the "open" end of the specified interval or even stay *within* that interval. This function is definitely not intended to be used as `uniform(closed_end, open_end)`.
Well, it is possible to make that happen if one is careful or directly sets the bits in ieee types...
For the unit interval, certainly. For general bounds, I am not so sure.
Point taken. Chuck
On Tue, Jan 19, 2016 at 12:43 PM, Charles R Harris < charlesr.harris@gmail.com> wrote:
On Tue, Jan 19, 2016 at 10:42 AM, Robert Kern <robert.kern@gmail.com> wrote:
On Tue, Jan 19, 2016 at 5:40 PM, Charles R Harris < charlesr.harris@gmail.com> wrote:
On Tue, Jan 19, 2016 at 10:36 AM, Robert Kern <robert.kern@gmail.com>
On Tue, Jan 19, 2016 at 5:27 PM, Charles R Harris <
charlesr.harris@gmail.com> wrote:
On Tue, Jan 19, 2016 at 9:23 AM, 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,
wrote: then that's a precedent we could follow.
randint is not closed on the high end. The now deprecated
random_integers is the function that does that.
For floats, it's good to have various interval options. For
instance, in generating numbers that will be inverted or have their log taken it is good to avoid zero. However, the names 'low' and 'high' are misleading...
They are correctly leading the users to the manner in which the author intended the function to be used. The *implementation* is misleading by allowing users to do things contrary to the documented intent. ;-)
With floating point and general intervals, there is not really a good way to guarantee that the generated results avoid the "open" end of the specified interval or even stay *within* that interval. This function is definitely not intended to be used as `uniform(closed_end, open_end)`.
Well, it is possible to make that happen if one is careful or directly sets the bits in ieee types...
For the unit interval, certainly. For general bounds, I am not so sure.
Point taken.
What's the practical importance of this. The boundary points have probability zero, theoretically. What happens if low and high are only a few nulps apart? If you clip the distribution to obey boundary rules you create mass points :) Josef
Chuck
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
On Tue, Jan 19, 2016 at 5:36 PM, Robert Kern <robert.kern@gmail.com> wrote:
On Tue, Jan 19, 2016 at 5:27 PM, Charles R Harris <
On Tue, Jan 19, 2016 at 9:23 AM, 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,
charlesr.harris@gmail.com> wrote: then that's a precedent we could follow.
randint is not closed on the high end. The now deprecated
random_integers is the function that does that.
For floats, it's good to have various interval options. For instance,
in generating numbers that will be inverted or have their log taken it is good to avoid zero. However, the names 'low' and 'high' are misleading...
They are correctly leading the users to the manner in which the author intended the function to be used. The *implementation* is misleading by allowing users to do things contrary to the documented intent. ;-)
With floating point and general intervals, there is not really a good way to guarantee that the generated results avoid the "open" end of the specified interval or even stay *within* that interval. This function is definitely not intended to be used as `uniform(closed_end, open_end)`.
There are special cases that *can* be implemented and are worth doing so as they are building blocks for other distributions that do need to avoid 0 or 1 as you say. Full-featured RNG suites do offer these: [0, 1] [0, 1) (0, 1] (0, 1) -- Robert Kern
On Tue, Jan 19, 2016 at 9:27 AM, Charles R Harris <charlesr.harris@gmail.com
wrote:
On Tue, Jan 19, 2016 at 9:23 AM, 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.
randint is not closed on the high end. The now deprecated random_integers is the function that does that.
I was referring to the stdlib randint: In [*7*]: [random.randint(2,5) for i in range(10)] Out[*7*]: [5, 5, 2, 4, 5, 5, 3, 5, 2, 2] thinking that compatibility with that would be good -- but that ship has sailed. randrange is open on the high end, as range is, (duh!) [random.randrange(2,5) for i in range(10)] Out[*9*]: [3, 3, 4, 3, 3, 2, 4, 2, 3, 3] but you get an exception is low >=high: In [*10*]: random.randrange(5,2) ValueError: empty range for randrange() (5,2, -3) I like the exception idea best -- but backward compatibility and all that. -CHB -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
In principle, if we are describing an *interval*, that is the right thing to do: https://en.wikipedia.org/wiki/Interval_(mathematics)#Including_or_excluding_... Alan Isaac On 1/19/2016 9:21 AM, G Young 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/.
participants (11)
-
Alan G Isaac -
Benjamin Root -
Charles R Harris -
Chris Barker -
Chris Barker - NOAA Federal
-
G Young -
Jaime Fernández del Río -
josef.pktd＠gmail.com -
Marten van Kerkwijk -
Robert Kern -
Sebastian Berg