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

[Sebastian Berg]

On Do, 2016-01-21 at 09:38 +, Robert Kern wrote:
> On Tue, Jan 19, 2016 at 5:35 PM, Sebastian Berg <
> sebast...@sipsolutions.net> wrote:
> >
> > On Di, 2016-01-19 at 16:28 +, 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

signature.asc
Description: This is a digitally signed message part
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

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

[Robert Kern]

On Thu, Jan 21, 2016 at 7:06 AM, Jaime Fernández del Río <
jaime.f...@gmail.com> wrote:
>
> There doesn't seem to be much of a consensus on the way to go, so leaving
things as they are and have been seems the wisest choice for now, thanks
for all the feedback. I will work with Greg on documenting the status quo
properly.

Ugh. Be careful in documenting the way things currently work. No one
intended for it to work that way! No one should rely on high___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

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

[Robert Kern]

On Tue, Jan 19, 2016 at 5:35 PM, Sebastian Berg 
wrote:
>
> On Di, 2016-01-19 at 16:28 +, 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.html#numpy.random.uniform

--
Robert Kern
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

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

[Peter Creasey]

>> I would also point out that requiring open vs closed intervals (in
>> doubles) is already an extremely specialised use case. In terms of
>> *sampling the reals*, there is no difference between the intervals
>> (a,b) and [a,b], because the endpoints have measure 0, and even with
>> double-precision arithmetic, you are going to have to make several
>> petabytes of random data before you hit an endpoint...
>>
> Petabytes ain't what they used to be ;) I remember testing some hardware
> which, due to grounding/timing issues would occasionally goof up a readable
> register. The hardware designers never saw it because they didn't test for
> hours and days at high data rates. But it was there, and it would show up
> in the data. Measure zero is about as real as real numbers...
>
> Chuck

Actually, your point is well taken and I am quite mistaken. If you
pick some values like uniform(low, low * (1+2**-52)) then you can hit
your endpoints pretty easily. I am out of practice making
pathological tests for double precision arithmetic.

I guess my suggestion would be to add the deprecation warning and
change the docstring to warn that the interval is not guaranteed to be
right-open.

Peter
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

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

[Jaime Fernández del Río]

There doesn't seem to be much of a consensus on the way to go, so leaving
things as they are and have been seems the wisest choice for now, thanks
for all the feedback. I will work with Greg on documenting the status quo
properly.

We probably want to follow the lead of the stdlib's random.uniform on how
the openness of the interval actually results in practice:

https://docs.python.org/3.6/library/random.html#random.uniform


On Thu, Jan 21, 2016 at 2:55 AM, Peter Creasey <
p.e.creasey...@googlemail.com> wrote:

> >> I would also point out that requiring open vs closed intervals (in
> >> doubles) is already an extremely specialised use case. In terms of
> >> *sampling the reals*, there is no difference between the intervals
> >> (a,b) and [a,b], because the endpoints have measure 0, and even with
> >> double-precision arithmetic, you are going to have to make several
> >> petabytes of random data before you hit an endpoint...
> >>
> > Petabytes ain't what they used to be ;) I remember testing some hardware
> > which, due to grounding/timing issues would occasionally goof up a
> readable
> > register. The hardware designers never saw it because they didn't test
> for
> > hours and days at high data rates. But it was there, and it would show up
> > in the data. Measure zero is about as real as real numbers...
> >
> > Chuck
>
> Actually, your point is well taken and I am quite mistaken. If you
> pick some values like uniform(low, low * (1+2**-52)) then you can hit
> your endpoints pretty easily. I  am out of practice making
> pathological tests for double precision arithmetic.
>
> I guess my suggestion would be to add the deprecation warning and
> change the docstring to warn that the interval is not guaranteed to be
> right-open.
>
> Peter
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>



-- 
(\__/)
( 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

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

[Charles R Harris]

On Wed, Jan 20, 2016 at 11:57 AM, Peter Creasey <
p.e.creasey...@googlemail.com> wrote:

> +1 for the deprecation warning for low>high, I think the cases where
> that is called are more likely to be unintentional rather than someone
> trying to use uniform(closed_end, open_end) and you might help users
> find bugs -  i.e. the idioms of ‘explicit is better than implicit’ and
> ‘fail early and fail loudly’ apply.
>
> I would also point out that requiring open vs closed intervals (in
> doubles) is already an extremely specialised use case. In terms of
> *sampling the reals*, there is no difference between the intervals
> (a,b) and [a,b], because the endpoints have measure 0, and even with
> double-precision arithmetic, you are going to have to make several
> petabytes of random data before you hit an endpoint...
>

Petabytes ain't what they used to be ;) I remember testing some hardware
which, due to grounding/timing issues would occasionally goof up a readable
register. The hardware designers never saw it because they didn't test for
hours and days at high data rates. But it was there, and it would show up
in the data. Measure zero is about as real as real numbers...

Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

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

[Peter Creasey]

+1 for the deprecation warning for low>high, I think the cases where
that is called are more likely to be unintentional rather than someone
trying to use uniform(closed_end, open_end) and you might help users
find bugs -  i.e. the idioms of ‘explicit is better than implicit’ and
‘fail early and fail loudly’ apply.

I would also point out that requiring open vs closed intervals (in
doubles) is already an extremely specialised use case. In terms of
*sampling the reals*, there is no difference between the intervals
(a,b) and [a,b], because the endpoints have measure 0, and even with
double-precision arithmetic, you are going to have to make several
petabytes of random data before you hit an endpoint...

Peter
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

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

[Robert Kern]

On Tue, Jan 19, 2016 at 5:40 PM, Charles R Harris 
wrote:
>
> On Tue, Jan 19, 2016 at 10:36 AM, Robert Kern 
wrote:
>>
>> On Tue, Jan 19, 2016 at 5:27 PM, Charles R Harris <
charlesr.har...@gmail.com> wrote:
>> >
>>
>> > On Tue, Jan 19, 2016 at 9:23 AM, 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> >
>> > 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
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

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

[Charles R Harris]

On Tue, Jan 19, 2016 at 10:42 AM, Robert Kern  wrote:

> On Tue, Jan 19, 2016 at 5:40 PM, Charles R Harris <
> charlesr.har...@gmail.com> wrote:
> >
> > On Tue, Jan 19, 2016 at 10:36 AM, Robert Kern 
> wrote:
> >>
> >> On Tue, Jan 19, 2016 at 5:27 PM, Charles R Harris <
> charlesr.har...@gmail.com> wrote:
> >> >
> >>
> >> > On Tue, Jan 19, 2016 at 9:23 AM, 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 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
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

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

[josef.pktd]

On Tue, Jan 19, 2016 at 12:43 PM, Charles R Harris <
charlesr.har...@gmail.com> wrote:

>
>
> On Tue, Jan 19, 2016 at 10:42 AM, Robert Kern 
> wrote:
>
>> On Tue, Jan 19, 2016 at 5:40 PM, Charles R Harris <
>> charlesr.har...@gmail.com> wrote:
>> >
>> > On Tue, Jan 19, 2016 at 10:36 AM, Robert Kern 
>> wrote:
>> >>
>> >> On Tue, Jan 19, 2016 at 5:27 PM, Charles R Harris <
>> charlesr.har...@gmail.com> wrote:
>> >> >
>> >>
>> >> > On Tue, Jan 19, 2016 at 9:23 AM, 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> 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
>
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

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

[Chris Barker]

On Tue, Jan 19, 2016 at 9:27 AM, Charles R Harris  wrote:

> On Tue, Jan 19, 2016 at 9:23 AM, 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> 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(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

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

[G Young]

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  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 ) 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

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

[Benjamin Root]

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 ) 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

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

[Marten van Kerkwijk]

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
​
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [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.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 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  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 
> 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 ) 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

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

[Chris Barker - NOAA Federal]

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 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  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 ) 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

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

[Alan G Isaac]

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_endpoints

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/.


___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

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

[Charles R Harris]

On Tue, Jan 19, 2016 at 9:23 AM, 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 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
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

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

[Charles R Harris]

On Tue, Jan 19, 2016 at 10:27 AM, Charles R Harris <
charlesr.har...@gmail.com> wrote:

>
>
> On Tue, Jan 19, 2016 at 9:23 AM, 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> 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
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

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

[Sebastian Berg]

On Di, 2016-01-19 at 16:28 +, 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.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 > 
> > (Sorry, on a phone, can't check)
> > 
> > CHB
> > 
> > 
> > 
> > On Jan 19, 2016, at 6: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.
> > > 
> > > 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) 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

signature.asc
Description: This is a digitally signed message part
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

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

[Robert Kern]

On Tue, Jan 19, 2016 at 5:27 PM, Charles R Harris 
wrote:
>

> On Tue, Jan 19, 2016 at 9:23 AM, 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
> 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
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

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

[Charles R Harris]

On Tue, Jan 19, 2016 at 10:36 AM, Robert Kern  wrote:

> On Tue, Jan 19, 2016 at 5:27 PM, Charles R Harris <
> charlesr.har...@gmail.com> wrote:
> >
>
> > On Tue, Jan 19, 2016 at 9:23 AM, 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 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
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

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

[Robert Kern]

On Tue, Jan 19, 2016 at 5:36 PM, Robert Kern  wrote:
>
> On Tue, Jan 19, 2016 at 5:27 PM, Charles R Harris <
charlesr.har...@gmail.com> wrote:
> >
>
> > On Tue, Jan 19, 2016 at 9:23 AM, 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 >
> > 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
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion