[Numpy-discussion] Behavior of np.random.uniform

[G Young]

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 at 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 at 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 at 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 at 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 at scipy.org
>>> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>>>
>>>
>>
>> _______________________________________________
>> NumPy-Discussion mailing list
>> NumPy-Discussion at scipy.org
>> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>>
>>
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20160119/fbdeb231/attachment.html>