# random number including 1 - i.e. [0,1]

Mensanator mensanator at aol.com
Wed Jun 10 06:04:49 CEST 2009

```On Jun 9, 8:28�pm, John Yeung <gallium.arsen... at gmail.com> wrote:
> On Jun 9, 8:45�pm, Mensanator <mensana... at aol.com> wrote:
>
> > On Jun 9, 6:05�pm, "Gabriel Genellina" <gagsl-... at yahoo.com.ar> wrote:
> > > py> a+(b-a)*z < b # the expression used for uniform(a,b)
> > > False
> > > py> a+(b-a)*z
> > > 11.0
>
> > What you do with the number after it's created is not
> > random's concern.
>
> Mensanator, you missed Gabriel's point. �What he's saying is that,
> effectively, random.uniform(a, b) returns a + (b - a) * random.random
> (). �So z may not be random()'s concern, but it very much is uniform
> ()'s concern.
>
> > > The docs are already updated to reflect this:http://svn.python.org/view/python/trunk/Doc/library/random.rst?r1=687...
>
> > The docs are now wrong. Why would they do that?
>
> The docs are now... sort of correct. �

I'm not actually disputing that. I'm simply puzzled why this
issue was swept under the rug by pretending it's supposed
to work that way. We're not children here, you can explain
that what is supposed to work in theory sometimes has problems
in practice. We're not all going to abandon Python and run out

Look at how the change of random to the Mersenne Twister
was handled. That's what we, the users, want to see. Otherwise,
it creates endless confusion.

Maybe something along the lines of "Changed in 2.6.2 to reflect
the realities of floating point math." That way, when a contradiction
arises, we'll know why.

> For some values of a and b,
> uniform() can never return b. �Notably, I believe uniform(0, 1) is
> equivalent to random(), and will never return 1. �However, uniform(1,
> 2) CAN return 2, if this is any indication:
>
> >>> a=0.0
> >>> b=1.0
> >>> a+(b-a)*z < b
> True
> >>> a=1.0
> >>> b=2.0
> >>> a+(b-a)*z < b
>
> False
>
> John

```