random number including 1 - i.e. [0,1]
mensanator at aol.com
Wed Jun 10 02:45:05 CEST 2009
On Jun 9, 6:05 pm, "Gabriel Genellina" <gagsl-... at yahoo.com.ar> wrote:
> En Tue, 09 Jun 2009 18:33:39 -0300, Esmail <ebo... at hotmail.com> escribió:
> > random.random() will generate a random value in the range [0, 1).
> > Is there an easy way to generate random values in the range [0, 1]?
> > I.e., including 1?
> I think you shouldn't worry about that - the difference may be as small as
> 2**-53, or 0.0000000000000001
> > I am implementing an algorithm and want to stay as true to the
> > original design specifications as possible though I suppose the
> > difference between the two max values might be minimal.
> > ps: I'm confused by the docs for uniform():
> > random.uniform(a, b)
> > Return a random floating point number N such that a <= N <= b for a
> > <= b
> > this seems to imply an inclusive range, ie. [a,b]
> random() guarantees a semi-open interval (could return 0, but never 1).
> But once you start to operate with the numbers, the limits become fuzzy.
> a<b & n>0 => n.a<n.b
> The above holds for real numbers but not always for floating point
> arithmetic, so one cannot guarantee the semi-open interval anymore:
> py> a=10.0
> py> b=11.0
> py> z = 0.9999999999999999 # assume random.random returned this
> py> z<1
That means the interval is still [0,1). To put it another way:
> py> a+(b-a)*z < b # the expression used for uniform(a,b)
> py> a+(b-a)*z
What you do with the number after it's created is not
> 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?
> Gabriel Genellina
More information about the Python-list