On Jun 9, 8:28�pm, John Yeung <gallium.arsen...@gmail.com> wrote: > On Jun 9, 8:45�pm, Mensanator <mensana...@aol.com> wrote: > > > On Jun 9, 6:05�pm, "Gabriel Genellina" <gagsl-...@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 and buy Mathematica. 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 -- http://mail.python.org/mailman/listinfo/python-list