Re: random number including 1 - i.e. [0,1]
In message qoteitso8ru@ruuvi.it.helsinki.fi, Jussi Piitulainen wrote:
Miles Kaufmann writes:
I'm curious what algorithm calls for random numbers on a closed
interval.
The Box-Muller transform, polar form. At least Wikipedia says so.
Doesn't seem to be necessary, if I interpret the following correctly
http://en.wikipedia.org/wiki/Box-Muller_transform#Polar_form:
Given u and v, independent and uniformly distributed in the closed
interval [−1, +1], set s = R2 = u2 + v2. (Clearly \scriptstyle R =
\sqrt{s}.) If s = 0 or s 1, throw u and v away and try another pair
(u, v). Continue until a pair with s in the open interval (0, 1) is
found.
Since s is supposed to be in an open interval, I don't see how it makes any
difference if u and v are chosen from an open or semiopen interval. The
probability of hitting the exact endpoints is 0, after all.
--
http://mail.python.org/mailman/listinfo/python-list
Re: random number including 1 - i.e. [0,1]
In message mailman.1366.1244592006.8015.python-l...@python.org, Esmail wrote: I'm implementing a Particle Swarm Optimizer. Depending on what paper you read you'll see mention of required random values between 0 and 1 which is somewhat ambiguous. I came across one paper that specified the range [0,1], so inclusive 1, which was the reason for my question. Sounds like some of their descriptions are a bit sloppy. Maybe best to clear it up by trying to think what a value of exactly or exactly 1 for the random value might mean: are those boundaries meant to be inside the set, or outside? Is it meaningful to concatenate two adjacent intervals? In that case any point can only belong to one of the intervals, not both. -- http://mail.python.org/mailman/listinfo/python-list
Re: random number including 1 - i.e. [0,1]
In message mailman.1368.1244607807.8015.python-l...@python.org, Esmail wrote: Here is part of the specification of an algorithm I'm implementing that shows the reason for my original query: vid = w * vid + c1 * rand( ) * ( pid – xid ) + c2 * Rand( ) * (pgd –xid ) (1a) xid = xid + vid (1b) Are the terms meant to be clamped to a particular range of values? Otherwise it probably doesn't matter. -- http://mail.python.org/mailman/listinfo/python-list
Re: random number including 1 - i.e. [0,1]
Thanks everyone, I learned more than I expected about floats :-) and got some good explanations and ideas about all of this. Esmail -- http://mail.python.org/mailman/listinfo/python-list
Re: random number including 1 - i.e. [0,1]
Steven D'Aprano wrote: On Tue, 09 Jun 2009 18:28:23 -0700, John Yeung wrote: The docs are now... sort of correct. 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 But you haven't shown what value z has, so there's no way of interpreting that example. I'd say that uniform(1, 2) should NOT return 2, at least for systems which round correctly. Given a random z such that: 0 = z 1 and two floats a, b such that: a b (b is strictly the larger of the two) then: 0 = z 1 Multiply all sides by (b-a): 0 = (b-a)*z (b-a) Add a to all sides: a = a + (b-a)*z b Hence uniform(a, b) should always return a result less than b, and greater or equal to a. However, there is one proviso: floats are not reals. The above holds true for real numbers, but floats are subject to weird rounding effects. That means that there may be weird edge cases where Bad Things happen and things cancel catastrophically or round incorrectly. A realistic edge case is that a + (b-a) doesn't always give b: a = -1e90 b = 1.0 a b True a + (b-a) == b False a + (b-a) 0.0 However, even in this case, it merely narrows the range of possible results, it doesn't widen it. Did you try to find the edge case for z ? For the following, I'm using Python 2.6.2, running on XP, on a Pentium Core Duo. I figure the highest theoretical value that random.random() should return is a number just under 1.0 The easiest way to generate that value is using the fromhex() method of float. z = float.fromhex(0x1.fp-1) z 0.99989 z1.0 True z2 = 1.0 + z z2 2.0 z2 2.0 False -- http://mail.python.org/mailman/listinfo/python-list
Re: random number including 1 - i.e. [0,1]
On Jun 9, 11:28�pm, Steven D'Aprano ste...@remove.this.cybersource.com.au wrote: On Tue, 09 Jun 2009 21:04:49 -0700, Mensanator wrote: 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. Funny, saying The docs are now wrong sure sounds like you're disputing that they're correct to me! Those statements were made over two hours apart. Things can change in two hours. I'm simply puzzled why this issue was swept under the rug by pretending it's supposed to work that way. I'm completely confused. What is this issue, [0,1) vs. [0,1] and why are we pretending that it's supposed to work that way? By changing the documentation without explaining why. If the intention was [0,1), as implied by the 2.6.1 docs, but wasn't actually doing that, it should be so stated. This isn't simply fixing a typo. Yes, I've read the thread. I still have no idea what you are complaining about. According to your reply to John Young, you know exactly what the problem is. 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. Speak for yourself. What about the change that you think we, the users, want to see? Things like this: Python uses the Mersenne Twister as the core generator. It produces 53-bit precision floats and has a period of 2**19937-1. The underlying implementation in C is both fast and threadsafe. The Mersenne Twister is one of the most extensively tested random number generators in existence. Is that strictly necessary in the random documentation that defines what the random module does? _I_ appreciate it being there and am glad someone made the effort to put it there. If there is a change from a=Nb to a=N=b I would like to see that pointed out also, even if it isn't strictly part of the definition of what the function does. Otherwise, it creates endless confusion. Not as confused as this discussion. I thought you said you read the thread? -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: random number including 1 - i.e. [0,1]
On Jun 10, 1:52 am, Steven D'Aprano ste...@remove.this.cybersource.com.au wrote: On Tue, 09 Jun 2009 22:21:26 -0700, John Yeung wrote: Therefore, to me the most up-to-date docs (which say that uniform(a, b) returns a float in the closed interval [a, b]) is closer to correct than before, but still fails to point out the full subtlety of the behavior. Which is? That uniform(a, b) will return a random float in the semi-open interval [a, b) for certain values of a and b; and in the closed interval [a, b] for other values of a and b. (Swap a and b if a b.) To me, the fact that you sometimes get a semi-open interval and sometimes a closed interval is worth noting in the docs. John -- http://mail.python.org/mailman/listinfo/python-list
Re: random number including 1 - i.e. [0,1]
John Yeung wrote: On Jun 10, 1:52am, Steven D'Aprano ste...@remove.this.cybersource.com.au wrote: On Tue, 09 Jun 2009 22:21:26 -0700, John Yeung wrote: Therefore, to me the most up-to-date docs (which say that uniform(a, b) returns a float in the closed interval [a, b]) is closer to correct than before, but still fails to point out the full subtlety of the behavior. Which is? That uniform(a, b) will return a random float in the semi-open interval [a, b) for certain values of a and b; and in the closed interval [a, b] for other values of a and b. (Swap a and b if a b.) To me, the fact that you sometimes get a semi-open interval and sometimes a closed interval is worth noting in the docs. John I took the following direct from "The Python Library Reference (Release 2.6.2)" , Guido van Rossum, Fred L. Drake, Jr. editor, June 10, 2009. On p. 216, Almost all module functions depend on the basic function random(), which generates a random float uniformly in the semi-open range [0.0, 1.0). Python uses the Mersenne Twister as the core generator. It produces 53-bit precision floats and has a period of 2**19937-1. The underlying implementation in C is both fast and threadsafe. The Mersenne Twister is one of the most extensively tested random number generators in existence. However, being completely deterministic, it is not suitable for all purposes, and is completely unsuitable for cryptographic purposes. The notation above means that 0 is included but 1 is not (as pointed out by Esmail). I agree with Esmail, that it is important to know if this is correct, since the "drawing" of pseudo RVs from other distributions can depend on this function. The following is taken from MatLab (R2007b), The rand function now supports a method of random number generation called the Mersenne Twister. The algorithm used by this method, developed by Nishimura and Matsumoto, generates double precision values in the closed interval [2^(-53), 1-2^(-53)], with a period of (2^19937-1)/2. Note, that it will not generate a 0 or 1; i.e., the interval for the pseudo RV can be written as (0,1) or [2^(-53), 1-2^(-53)], where the latter is more informative. For a full description of the Mersenne twister algorithm, see http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/emt.html. If indeed Python 2.6.2 is using the Mersenne twister algorithm as defined by the creators of this algorithm (go to the link given above), then IMHO the documentation should be corrected. I hope that this helps. --V. Stokes -- http://mail.python.org/mailman/listinfo/python-list
Re: random number including 1 - i.e. [0,1]
Miles Kaufmann writes: [...] I'm curious what algorithm calls for random numbers on a closed interval. The Box-Muller transform, polar form. At least Wikipedia says so. -- http://mail.python.org/mailman/listinfo/python-list
Re: random number including 1 - i.e. [0,1]
On 10 Giu, 06:23, Esmail ebo...@hotmail.com wrote: Here is part of the specification of an algorithm I'm implementing that shows the reason for my original query: vid = w * vid + c1 * rand( ) * ( pid – xid ) + c2 * Rand( ) * (pgd –xid ) (1a) xid = xid + vid (1b) where c1 and c2 are two positive constants, rand() and Rand() are two random functions in the range [0,1], ^ and w is the inertia weight. 1) I second John Yeung's suggestion: use random integers between 0 and N-1 or N inclusive and divide by N to obtain a maximum value of (N-1)/ N or 1 as you prefer. Note that N doesn't need to be very large. 2) I'm not sure a pseudo-closed range is different from a pseudo-open one. You are perturbing vid and xid by random amounts, scaled by arbitrary coefficients c1 and c2: if you multiply or divide these coefficients by (N-1)/N the minimum and maximum results for the two choices can be made identical up to floating point mangling. Regards, Lorenzo Gatti -- http://mail.python.org/mailman/listinfo/python-list
Re: random number including 1 - i.e. [0,1]
On Jun 10, 3:24 pm, John Yeung gallium.arsen...@gmail.com wrote: Alex, did you bother to read what I quoted? Paul McGuire suggested an alternative in case the OP was choosing integers in a roundabout way. I was merely pointing out that Paul's solution can be more simply achieved using a library function. My apologies, John. I *did* read the quote, my brain just didn't parse it correctly. Sorry about that :) -- http://mail.python.org/mailman/listinfo/python-list
Re: random number including 1 - i.e. [0,1]
On Wed, Jun 10, 2009 at 8:25 AM, John Yeunggallium.arsen...@gmail.com wrote: That uniform(a, b) will return a random float in the semi-open interval [a, b) for certain values of a and b; and in the closed interval [a, b] for other values of a and b. (Swap a and b if a b.) To me, the fact that you sometimes get a semi-open interval and sometimes a closed interval is worth noting in the docs. If it is important whether b is included or not, apparently the difference between b and the largest float smaller than b is important. If a difference as small as that makes a difference, you should not be using floats, or random generators giving floats, anyway, but something with a higher precision. In other words, if you do care about the difference between [a, b) and [a, b], the random module is not giving what you meet even if it does give the 'right' one of those. -- André Engels, andreeng...@gmail.com -- http://mail.python.org/mailman/listinfo/python-list
Re: random number including 1 - i.e. [0,1]
Esmail writes: 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 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. You could generate from a larger range and reject the values that you do not want: generate from [0, 2), say, until you get a value in [0, 1]. If you generate from [0, 1 + epsilon) with small epsilon, rejections will be rare. (I didn't notice this suggestion in the thread, so I'm voicing it just in case it's not there yet.) -- http://mail.python.org/mailman/listinfo/python-list
Re: random number including 1 - i.e. [0,1]
On Jun 10, 7:25 am, John Yeung gallium.arsen...@gmail.com wrote: On Jun 10, 1:52 am, Steven D'Aprano ste...@remove.this.cybersource.com.au wrote: On Tue, 09 Jun 2009 22:21:26 -0700, John Yeung wrote: Therefore, to me the most up-to-date docs (which say that uniform(a, b) returns a float in the closed interval [a, b]) is closer to correct than before, but still fails to point out the full subtlety of the behavior. Which is? That uniform(a, b) will return a random float in the semi-open interval [a, b) for certain values of a and b; and in the closed interval [a, b] for other values of a and b. (Swap a and b if a b.) To me, the fact that you sometimes get a semi-open interval and sometimes a closed interval is worth noting in the docs. Do you want to submit a doc patch? For practical purposes, I think you'd be hard-pressed to find a statistical test that could reliably distinguish between a large sample of values from random.uniform(a, b) and a sample from a 'perfect' uniform distribution on the closed interval [a, b]. It's true that there are values of a and b such that random.uniform(a, b) can never produce b. But for given a and b, not too close together, there may be many other values that can't be produced as well, so it hardly seems worth pointing out one particular value that can never be produced. Example: on a typical system there are almost 2**62 floats in the range [0, 1); the vast majority of these can never be produced by random.random(), which can only ever return one of 2**53 distinct values (it essentially just returns a value of the form n/2**53 with n an integer in the range [0, 2**53)). So random.uniform(0, 1) will miss lots of possible values. On the other hand, it's easy to find examples of a and b such that random.uniform(a, b) has a significant chance of producing b. For example, take a = 10**16, b = 10**16 + 4, then there's about a 1 in 4 chance of getting b. Or for a more extreme example, simply take a = b. Hence the doc change. Mark -- http://mail.python.org/mailman/listinfo/python-list
Re: random number including 1 - i.e. [0,1]
Esmail ebo...@hotmail.com wrote: Hi, 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? [...] Here are three recipes, each more pedantic than the last. They all assume that Python floats are IEEE 754 binary64 format (which they almost certainly are on your machine), and that randrange generates all values with equal likelihood (which it almost certainly doesn't, but the assumption should be good enough for government work). import random def random1(): Random float in [0, 1]. Generates all floats of the form n/2**53, 0 = n = 2**53, with equal probability. return random.randrange(2**53+1)/2.**53 def random2(): Random float in [0, 1]. Generates all floats of the forn n/2**53, 0 = n = 2**53, with values in (0.0, 1.0) equally likely, and the endpoints 0.0 and 1.0 occuring with half the probability of any other value. This is equivalent to generating a random real number uniformly on the closed interval [0, 1] and then rounding that real number to the nearest float of the form n/2**53. return (random.randrange(2**54)+1)//2/2.**53 def random3(): Random float in [0, 1]. Generates *all* floats in the interval [0.0, 1.0] (including 0.0 and 1.0, but excluding -0.0). Each float is generated with a probability corresponding to the size of the subinterval of [0, 1] that rounds to the given float under round-to-nearest. This is equivalent to generating a random real number uniformly on the closed interval [0, 1] and then rounding that real number to the nearest representable floating-point number. m = (random.randrange(2**53)+1)//2 e = 1022 while random.randrange(2) and e: e -= 1 return (m+2**52) * 2.**(e-1075) if e else m*2.**-1074 -- Mark Dickinson -- http://mail.python.org/mailman/listinfo/python-list
Re: random number including 1 - i.e. [0,1]
On Jun 9, 11:23 pm, Esmail ebo...@hotmail.com wrote: Here is part of the specification of an algorithm I'm implementing that shows the reason for my original query: vid = w * vid + c1 * rand( ) * ( pid – xid ) + c2 * Rand( ) * (pgd –xid ) (1a) xid = xid + vid (1b) where c1 and c2 are two positive constants, rand() and Rand() are two random functions in the range [0,1], ^ and w is the inertia weight. It is entirely possible that the documentation you have for the original rand() and Rand() functions have misstated their range. In my experience, rand() functions that I have worked with have always been [0,1). -- Paul -- http://mail.python.org/mailman/listinfo/python-list
Re: random number including 1 - i.e. [0,1]
On Jun 10, 4:01 am, Mark Dickinson dicki...@gmail.com wrote: On Jun 10, 7:25 am, John Yeung gallium.arsen...@gmail.com wrote: On Jun 10, 1:52 am, Steven D'Aprano ste...@remove.this.cybersource.com.au wrote: On Tue, 09 Jun 2009 22:21:26 -0700, John Yeung wrote: Therefore, to me the most up-to-date docs (which say that uniform(a, b) returns a float in the closed interval [a, b]) is closer to correct than before, but still fails to point out the full subtlety of the behavior. Which is? That uniform(a, b) will return a random float in the semi-open interval [a, b) for certain values of a and b; and in the closed interval [a, b] for other values of a and b. (Swap a and b if a b.) To me, the fact that you sometimes get a semi-open interval and sometimes a closed interval is worth noting in the docs. Do you want to submit a doc patch? For practical purposes, I think you'd be hard-pressed to find a statistical test that could reliably distinguish between a large sample of values from random.uniform(a, b) and a sample from a 'perfect' uniform distribution on the closed interval [a, b]. It's true that there are values of a and b such that random.uniform(a, b) can never produce b. So, the 2.6.2 documentation is STILL wrong. Before it implied it was ALWAYS a semi-open interval, and now it says it's ALWAYS a closed interval. But neither is correct. I think a doc patch is definitely warranted. But for given a and b, not too close together, there may be many other values that can't be produced as well, so it hardly seems worth pointing out one particular value that can never be produced. Example: on a typical system there are almost 2**62 floats in the range [0, 1); the vast majority of these can never be produced by random.random(), which can only ever return one of 2**53 distinct values (it essentially just returns a value of the form n/2**53 with n an integer in the range [0, 2**53)). So random.uniform(0, 1) will miss lots of possible values. On the other hand, it's easy to find examples of a and b such that random.uniform(a, b) has a significant chance of producing b. For example, take a = 10**16, b = 10**16 + 4, then there's about a 1 in 4 chance of getting b. Or for a more extreme example, simply take a = b. Hence the doc change. Mark -- http://mail.python.org/mailman/listinfo/python-list
Re: random number including 1 - i.e. [0,1]
On Jun 10, 6:21 pm, Mensanator mensana...@aol.com wrote: So, the 2.6.2 documentation is STILL wrong. Before it implied it was ALWAYS a semi-open interval, and now it says it's ALWAYS a closed interval. But neither is correct. Exactly which bit of the 2.6.2 documentation do you think is incorrect? The documentation for random.uniform says: Return a random floating point number N such that a = N = b for a = b and b = N = a for b a. And that's precisely what it does. Nowhere does the documentation say that *every* floating-point number N in the interval [a, b] can occur. Mark -- http://mail.python.org/mailman/listinfo/python-list
Re: random number including 1 - i.e. [0,1]
On Jun 10, 12:37 pm, Mark Dickinson dicki...@gmail.com wrote: On Jun 10, 6:21 pm, Mensanator mensana...@aol.com wrote: So, the 2.6.2 documentation is STILL wrong. Before it implied it was ALWAYS a semi-open interval, and now it says it's ALWAYS a closed interval. But neither is correct. Exactly which bit of the 2.6.2 documentation do you think is incorrect? The documentation for random.uniform says: Return a random floating point number N such that a = N = b for a = b and b = N = a for b a. And that's precisely what it does. I didn't say it didn't. Nowhere does the documentation say that *every* Unless qualified otherwise, that statement implies for all (a,b). floating-point number N in the interval [a, b] can occur. Mark -- http://mail.python.org/mailman/listinfo/python-list
Re: random number including 1 - i.e. [0,1]
On 2009-06-09 19:27, Mensanator wrote: On Jun 9, 6:12 pm, Robert Kernrobert.k...@gmail.com wrote: On 2009-06-09 18:05, Mensanator wrote: On Jun 9, 4:33 pm, Esmailebo...@hotmail.comwrote: Hi, 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 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. Thanks, Esmail 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 That's wrong. Where did you get it? http://docs.python.org/library/random Ok, but the 2.6.1 docs say random.uniform(a, b) Return a random floating point number N such that a= N b for a= b and b= N a for b a. Is that a new feature of 2.6.2? As already pointed out, it's not really a new feature of the method, but rather a fix for the buggy documentation. Because of floating point arithmetic, one cannot guarantee that a+(b-a)*u is strictly in [a,b) even though u is strictly in [0,1). -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco -- http://mail.python.org/mailman/listinfo/python-list
Re: random number including 1 - i.e. [0,1]
Mensanator wrote: So, the 2.6.2 documentation is STILL wrong. Before it implied it was ALWAYS a semi-open interval, and now it says it's ALWAYS a closed interval. But neither is correct. If a x b is true, then a = x = b is true. But docs say that in general end point values might happen. They do not say that in every particular case, they will happen. A full technical discussion does not below in the docs, in my opinion. A wike article would be fine. tjr -- http://mail.python.org/mailman/listinfo/python-list
Re: random number including 1 - i.e. [0,1]
On Jun 10, 6:57 pm, Mensanator mensana...@aol.com wrote: On Jun 10, 12:37 pm, Mark Dickinson dicki...@gmail.com wrote: On Jun 10, 6:21 pm, Mensanator mensana...@aol.com wrote: So, the 2.6.2 documentation is STILL wrong. Before it implied it was ALWAYS a semi-open interval, and now it says it's ALWAYS a closed interval. But neither is correct. Exactly which bit of the 2.6.2 documentation do you think is incorrect? The documentation for random.uniform says: Return a random floating point number N such that a = N = b for a = b and b = N = a for b a. And that's precisely what it does. I didn't say it didn't. Nowhere does the documentation say that *every* Unless qualified otherwise, that statement implies for all (a,b). Sure. For all a = b, it's true that a = uniform(a, b) = b. And similarly for b = a. I really don't see the problem: the documentation is both technically correct and useful in practice. The assertion implicit in the name and description of the random.uniform function is that, to a very good approximation, the values produced by random.uniform(a, b) will be uniformly distributed on the closed interval [a, b]. And that's true (at least within the limits of floating-point arithmetic). Can you think of a single practical situation where it would matter that, for some values of a and b, uniform(a, b) can never produce the value b? Mark -- http://mail.python.org/mailman/listinfo/python-list
Re: random number including 1 - i.e. [0,1]
On 2009-06-10 13:53, Terry Reedy wrote: Mensanator wrote: So, the 2.6.2 documentation is STILL wrong. Before it implied it was ALWAYS a semi-open interval, and now it says it's ALWAYS a closed interval. But neither is correct. If a x b is true, then a = x = b is true. But docs say that in general end point values might happen. They do not say that in every particular case, they will happen. I'm not so sure. Context is important. When discussing the bounds of random number generators, specifying = instead of strongly suggests that the bound is one of the possible results. I've had to read a lot of random number generator documentation in my time. To take the point to absurdity, it would be wrong for the function to return just values within (a+0.25*b, a+0.75*b) even though the docs just say that the result will be between a and b. A full technical discussion does not below in the docs, in my opinion. A wike article would be fine. True. However, a brief note that Due to floating point arithmetic, for some values of a and b, b may or may not be one of the possible generated results. might be worthwhile. The actual details of *why* this is the case can be discussed elsewhere. -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco -- http://mail.python.org/mailman/listinfo/python-list
Re: random number including 1 - i.e. [0,1]
On Jun 10, 8:15 pm, Robert Kern robert.k...@gmail.com wrote: On 2009-06-10 13:53, Terry Reedy wrote: A full technical discussion does not below in the docs, in my opinion. A wike article would be fine. True. However, a brief note that Due to floating point arithmetic, for some values of a and b, b may or may not be one of the possible generated results. might be worthwhile. The actual details of *why* this is the case can be discussed elsewhere. I find it difficult to see how such a disclaimer would have any practical value, without also knowing *which* values of a and b are affected. It can certainly be useful to know that endpoints *aren't* included where that's true. For example, knowing that random.random() can never produce the value 1.0 means that one can safely generate a mean 1 exponential variate with -log(1-random.random()), without worrying about the possibility of taking log of 0. But I don't know why it would be useful to know that endpoints *are* sometimes included, without knowing exactly when. Mark -- http://mail.python.org/mailman/listinfo/python-list
Re: random number including 1 - i.e. [0,1]
On 2009-06-10 14:46, Mark Dickinson wrote: On Jun 10, 8:15 pm, Robert Kernrobert.k...@gmail.com wrote: On 2009-06-10 13:53, Terry Reedy wrote: A full technical discussion does not below in the docs, in my opinion. A wike article would be fine. True. However, a brief note that Due to floating point arithmetic, for some values of a and b, b may or may not be one of the possible generated results. might be worthwhile. The actual details of *why* this is the case can be discussed elsewhere. I find it difficult to see how such a disclaimer would have any practical value, without also knowing *which* values of a and b are affected. It can certainly be useful to know that endpoints *aren't* included where that's true. For example, knowing that random.random() can never produce the value 1.0 means that one can safely generate a mean 1 exponential variate with -log(1-random.random()), without worrying about the possibility of taking log of 0. But I don't know why it would be useful to know that endpoints *are* sometimes included, without knowing exactly when. That's a fair point. However, one issue that hasn't been brought up is that it might be confusing to a user why random.random() returns values in a half-open interval while random.uniform() claims a closed interval. Even for reasonably sophisticated floating point users, it's not necessarily obvious that that is the reasoning behind the different claims. -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco -- http://mail.python.org/mailman/listinfo/python-list
Re: random number including 1 - i.e. [0,1]
On 2009-06-10 15:32, Robert Kern wrote: On 2009-06-10 14:46, Mark Dickinson wrote: But I don't know why it would be useful to know that endpoints *are* sometimes included, without knowing exactly when. That's a fair point. However, one issue that hasn't been brought up is that it might be confusing to a user why random.random() returns values in a half-open interval while random.uniform() claims a closed interval. Even for reasonably sophisticated floating point users, it's not necessarily obvious that that is the reasoning behind the different claims. Basically, if we can forestall another tedious thread about imagined asymmetry and hemispatial neglect with a single sentence, I'm all for it. :-) -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco -- http://mail.python.org/mailman/listinfo/python-list
Re: random number including 1 - i.e. [0,1]
Robert Kern robert.k...@gmail.com wrote: On 2009-06-10 14:46, Mark Dickinson wrote: On Jun 10, 8:15 pm, Robert Kernrobert.k...@gmail.com wrote: On 2009-06-10 13:53, Terry Reedy wrote: A full technical discussion does not below in the docs, in my opinion. A wike article would be fine. True. However, a brief note that Due to floating point arithmetic, for some values of a and b, b may or may not be one of the possible generated results. might be worthwhile. The actual details of *why* this is the case can be discussed elsewhere. I find it difficult to see how such a disclaimer would have any practical value [lots more badly wrapped text snipped... ] That's a fair point. However, one issue that hasn't been brought up is that it might be confusing to a user why random.random() returns values in a half-open interval while random.uniform() claims a closed interval. Even for reasonably sophisticated floating point users, it's not necessarily obvious that that is the reasoning behind the different claims. True. I guess the original post in this thread is good evidence of that. Though I'm not sure I'm capable of coming up with extra wording for the docs that won't just cause more confusion, so I'll leave that to someone else. I seem to recall that when this originally came up in the tracker (issue 4979) the fun part of the analysis was proving that random.uniform(a, b) can never produce values *outside* the interval [a, b]. :-) -- Mark Dickinson -- http://mail.python.org/mailman/listinfo/python-list
Re: random number including 1 - i.e. [0,1]
On 2009-06-10 15:54, Mark Dickinson wrote: Robert Kernrobert.k...@gmail.com wrote: On 2009-06-10 14:46, Mark Dickinson wrote: On Jun 10, 8:15 pm, Robert Kernrobert.k...@gmail.com wrote: On 2009-06-10 13:53, Terry Reedy wrote: A full technical discussion does not below in the docs, in my opinion. A wike article would be fine. True. However, a brief note that Due to floating point arithmetic, for some values of a and b, b may or may not be one of the possible generated results. might be worthwhile. The actual details of *why* this is the case can be discussed elsewhere. I find it difficult to see how such a disclaimer would have any practical value [lots more badly wrapped text snipped... ] That's a fair point. However, one issue that hasn't been brought up is that it might be confusing to a user why random.random() returns values in a half-open interval while random.uniform() claims a closed interval. Even for reasonably sophisticated floating point users, it's not necessarily obvious that that is the reasoning behind the different claims. True. I guess the original post in this thread is good evidence of that. Though I'm not sure I'm capable of coming up with extra wording for the docs that won't just cause more confusion, so I'll leave that to someone else. I did make a concrete suggestion. I seem to recall that when this originally came up in the tracker (issue 4979) the fun part of the analysis was proving that random.uniform(a, b) can never produce values *outside* the interval [a, b]. :-) I was a bit worried about that part myself for a little bit. :-) -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco -- http://mail.python.org/mailman/listinfo/python-list
Re: random number including 1 - i.e. [0,1]
On Jun 9, 2:33 pm, Esmail ebo...@hotmail.com wrote: Hi, 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 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. Well, I guess someone should actually describe a solution to this rather than debate the necessity, if only for academic interest. So, in order to do this for real: Generate a random integer the range [0,2**53+1), probably the easiest thing is to get a 64 bit integer and scale it using integer division (which will also help to minimize selection bias). random.randrange probably does something like this already. If the number is exactly 2**53, return 1.0. Else stuff the bits of the number into the mantissa of a double, along with -1 as the exponent, and return that. Implementation left as exercise, mostly because it really won't make a difference. Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
Re: random number including 1 - i.e. [0,1]
Robert Kern robert.k...@gmail.com wrote: On 2009-06-10 15:54, Mark Dickinson wrote: [...] I'm not sure I'm capable of coming up with extra wording for the docs that won't just cause more confusion, so I'll leave that to someone else. I did make a concrete suggestion. Yes, you did. Thank you. Submitted as http://bugs.python.org/issue6261 I seem to recall that when this originally came up in the tracker (issue 4979) the fun part of the analysis was proving that random.uniform(a, b) can never produce values *outside* the interval [a, b]. :-) I was a bit worried about that part myself for a little bit. :-) I think the key was to show that multiplication by (1-2**-53) (the largest possible output of random.random()) always makes any float smaller in magnitude[*], so assuming that a = b the value of the Python expression random.random()*(b-a) can't be larger than the exact real value of (b-a), which in turn means that a + random.random()*(b-a) can't exceed b. [*] Well, almost. This isn't true for subnormals. But if the result of the subtraction b-a is subnormal then that subtraction was also necessarily exact, so everything works in this case, too. And of course I'm wrong. I shouldn't have said *never*, above: from random import uniform uniform(-1e308, 1e308) inf :-( Somehow this doesn't seem worth either fixing or documenting, though. -- Mark Dickinson -- http://mail.python.org/mailman/listinfo/python-list
Re: random number including 1 - i.e. [0,1]
On 2009-06-10 16:47, Mark Dickinson wrote: And of course I'm wrong. I shouldn't have said *never*, above: from random import uniform uniform(-1e308, 1e308) inf :-( Somehow this doesn't seem worth either fixing or documenting, though. Agreed. -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco -- http://mail.python.org/mailman/listinfo/python-list
Re: random number including 1 - i.e. [0,1]
On Wed, 10 Jun 2009 15:32:05 -0500, Robert Kern wrote: That's a fair point. However, one issue that hasn't been brought up is that it might be confusing to a user why random.random() returns values in a half-open interval while random.uniform() claims a closed interval. Even for reasonably sophisticated floating point users, it's not necessarily obvious that that is the reasoning behind the different claims. Agreed -- the reasoning that a half-open interval [0, 1) for z (random()) leads to a closed interval [a, b] for a+(b-a)*z (uniform()) is *not* obvious even for people who are aware that floats do funny things. I know I got caught out by it. However, rather than a documentation patch, I'd prefer to see uniform() fixed to return a value in the half-open interval. Something like: def uniform(self, a, b): Get a random number in the range [a, b). r = a + (b-a) * self.random() while r == b: # Guard against (rare) rounding to b. r = a + (b-a) * self.random() return r should do the trick. I think. Earlier, Mark Dickinson wrote: Can you think of a single practical situation where it would matter that, for some values of a and b, uniform(a, b) can never produce the value b? I would argue that it is a good thing if uniform never returns b. alist[ int(uniform(0, len(alist))) ] can apparently fail for some lists, but not others. Admittedly, I don't have a good reason for using the above rather than sample(), or for truncating the result of uniform() rather than using randrange(). Hopefully if I don't mention it, nobody will notice it... *wink* -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: random number including 1 - i.e. [0,1]
En Tue, 09 Jun 2009 18:33:39 -0300, Esmail ebo...@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.0001 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. ab n0 = n.an.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. # assume random.random returned this py z1 True py a+(b-a)*z b # the expression used for uniform(a,b) False py a+(b-a)*z 11.0 The docs are already updated to reflect this: http://svn.python.org/view/python/trunk/Doc/library/random.rst?r1=68724r2=68723pathrev=68724 -- Gabriel Genellina -- http://mail.python.org/mailman/listinfo/python-list
Re: random number including 1 - i.e. [0,1]
On Jun 9, 4:33 pm, Esmail ebo...@hotmail.com wrote: Hi, 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 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. Thanks, Esmail 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 That's wrong. Where did you get it? help(random.uniform) Help on method uniform in module random: uniform(self, a, b) method of random.Random instance Get a random number in the range [a, b). this seems to imply an inclusive range, ie. [a,b] but this seems to contradict it: In [3]: random.uniform? Type: instancemethod Base Class: type 'instancemethod' String Form: bound method Random.uniform of random.Random object at 0x8c50754 Namespace: Interactive File: /usr/lib/python2.6/random.py Definition: random.uniform(self, a, b) Docstring: Get a random number in the range [a, b). -- http://mail.python.org/mailman/listinfo/python-list
Re: random number including 1 - i.e. [0,1]
On 2009-06-09 18:05, Mensanator wrote: On Jun 9, 4:33 pm, Esmailebo...@hotmail.com wrote: Hi, 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 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. Thanks, Esmail 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 That's wrong. Where did you get it? http://docs.python.org/library/random -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco -- http://mail.python.org/mailman/listinfo/python-list
Re: random number including 1 - i.e. [0,1]
On Jun 9, 2009, at 7:05 PM, Mensanator wrote: On Jun 9, 4:33 pm, Esmail wrote: Hi, 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 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. I'm curious what algorithm calls for random numbers on a closed interval. 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 That's wrong. Where did you get it? http://docs.python.org/library/random.html -Miles -- http://mail.python.org/mailman/listinfo/python-list
Re: random number including 1 - i.e. [0,1]
Gabriel Genellina wrote: En Tue, 09 Jun 2009 18:33:39 -0300, Esmail ebo...@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.0001 Ok, that's what I thought ... 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. ab n0 = n.an.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. # assume random.random returned this py z1 True py a+(b-a)*z b # the expression used for uniform(a,b) False py a+(b-a)*z 11.0 The docs are already updated to reflect this: http://svn.python.org/view/python/trunk/Doc/library/random.rst?r1=68724r2=68723pathrev=68724 Thanks for the information Gabriel, Esmail -- http://mail.python.org/mailman/listinfo/python-list
Re: random number including 1 - i.e. [0,1]
Robert Kern wrote: On 2009-06-09 18:05, Mensanator wrote: On Jun 9, 4:33 pm, Esmailebo...@hotmail.com wrote: That's wrong. Where did you get it? http://docs.python.org/library/random What he said :-) (thanks Robert) -- http://mail.python.org/mailman/listinfo/python-list
Re: random number including 1 - i.e. [0,1]
Miles Kaufmann wrote: I'm curious what algorithm calls for random numbers on a closed interval. I'm implementing a Particle Swarm Optimizer. Depending on what paper you read you'll see mention of required random values between 0 and 1 which is somewhat ambiguous. I came across one paper that specified the range [0,1], so inclusive 1, which was the reason for my question. (I'm still looking for other papers to see if I can get more information exactly on the range) I think in the end it probably doesn't matter if it's [0, 1) or [0, 1] as the max values for each will probably be very close. Esmail -- http://mail.python.org/mailman/listinfo/python-list
Re: random number including 1 - i.e. [0,1]
On Jun 9, 6:12 pm, Robert Kern robert.k...@gmail.com wrote: On 2009-06-09 18:05, Mensanator wrote: On Jun 9, 4:33 pm, Esmailebo...@hotmail.com wrote: Hi, 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 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. Thanks, Esmail 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 That's wrong. Where did you get it? http://docs.python.org/library/random Ok, but the 2.6.1 docs say random.uniform(a, b) Return a random floating point number N such that a = N b for a = b and b = N a for b a. Is that a new feature of 2.6.2? -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco- Hide quoted text - - Show quoted text - -- http://mail.python.org/mailman/listinfo/python-list
Re: random number including 1 - i.e. [0,1]
On Jun 9, 4:33 pm, Esmail ebo...@hotmail.com wrote: Hi, 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? Are you trying to generate a number in the range [0,n] by multiplying a random function that returns [0,1] * n? If so, then you want to do this using: int(random.random()*(n+1)) This will give equal chance of getting any number from 0 to n. If you had a function that returned a random in the range [0,1], then multiplying by n and then truncating would give only the barest sliver of a chance of giving the value n. You could try rounding, but then you get this skew: 0 for values [0, 0.5) (width of 0.5) 1 for value [0.5, 1.5) (width of 1) ... n for value [n-0.5, n] (width of ~0.50001) Still not a uniform die roll. You have only about 1/2 the probability of getting 0 or n as any other value. If you want to perform a fair roll of a 6-sided die, you would start with int(random.random() * 6). This gives a random number in the range [0,5], with each value of the same probability. How to get our die roll that goes from 1 to 6? Add 1. Thus: die_roll = lambda : int(random.random() * 6) + 1 Or for a n-sided die: die_roll = lambda n : int(random.random() * n) + 1 This is just guessing on my part, but otherwise, I don't know why you would care if random.random() returned values in the range [0,1) or [0,1]. -- Paul -- http://mail.python.org/mailman/listinfo/python-list
Re: random number including 1 - i.e. [0,1]
On Jun 9, 6:05 pm, Gabriel Genellina gagsl-...@yahoo.com.ar wrote: En Tue, 09 Jun 2009 18:33:39 -0300, Esmail ebo...@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.0001 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. ab n0 = n.an.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. # assume random.random returned this py z1 True That means the interval is still [0,1). To put it another way: z=0. z==1 False 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. 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: random number including 1 - i.e. [0,1]
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. 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
Re: random number including 1 - i.e. [0,1]
On Jun 9, 8:39 pm, Paul McGuire pt...@austin.rr.com wrote: Are you trying to generate a number in the range [0,n] by multiplying a random function that returns [0,1] * n? If so, then you want to do this using: int(random.random()*(n+1)) This will give equal chance of getting any number from 0 to n. Better still is simply random.randint(0, n) For other discrete random choices, you may find randrange() or choice () useful. John -- http://mail.python.org/mailman/listinfo/python-list
Re: random number including 1 - i.e. [0,1]
On Tue, 09 Jun 2009 18:28:23 -0700, John Yeung wrote: The docs are now... sort of correct. 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 But you haven't shown what value z has, so there's no way of interpreting that example. I'd say that uniform(1, 2) should NOT return 2, at least for systems which round correctly. Given a random z such that: 0 = z 1 and two floats a, b such that: a b (b is strictly the larger of the two) then: 0 = z 1 Multiply all sides by (b-a): 0 = (b-a)*z (b-a) Add a to all sides: a = a + (b-a)*z b Hence uniform(a, b) should always return a result less than b, and greater or equal to a. However, there is one proviso: floats are not reals. The above holds true for real numbers, but floats are subject to weird rounding effects. That means that there may be weird edge cases where Bad Things happen and things cancel catastrophically or round incorrectly. A realistic edge case is that a + (b-a) doesn't always give b: a = -1e90 b = 1.0 a b True a + (b-a) == b False a + (b-a) 0.0 However, even in this case, it merely narrows the range of possible results, it doesn't widen it. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: random number including 1 - i.e. [0,1]
On Jun 10, 11:32 am, John Yeung gallium.arsen...@gmail.com wrote: On Jun 9, 8:39 pm, Paul McGuire pt...@austin.rr.com wrote: Are you trying to generate a number in the range [0,n] by multiplying a random function that returns [0,1] * n? If so, then you want to do this using: int(random.random()*(n+1)) This will give equal chance of getting any number from 0 to n. Better still is simply random.randint(0, n) There's a big difference between randint - which generates _integers_ in the range 0 n - and the OPs request for generating random floating point values between inclusive of 0 n. -- http://mail.python.org/mailman/listinfo/python-list
Re: random number including 1 - i.e. [0,1]
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
Re: random number including 1 - i.e. [0,1]
On Jun 9, 4:33 pm, Esmail ebo...@hotmail.com wrote: Hi, 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? You could do random.uniform(0, 1.0002). Due to floating- point rounding, there are TWO original values that would return 1.0: 0.99978 or 0.99989; this may give you more 1.0's than you expected, and that's not even considering that Python's PRNG could be non-uniformly-distributed over the 53-bit fractions. If you're nit-picky enough to care about the less-than-winning-the- lottery chance of getting the maximum random value in the first place, this might be a problem. -- http://mail.python.org/mailman/listinfo/python-list
Re: random number including 1 - i.e. [0,1]
Here is part of the specification of an algorithm I'm implementing that shows the reason for my original query: vid = w * vid + c1 * rand( ) * ( pid – xid ) + c2 * Rand( ) * (pgd –xid ) (1a) xid = xid + vid (1b) where c1 and c2 are two positive constants, rand() and Rand() are two random functions in the range [0,1], ^ and w is the inertia weight. -- http://mail.python.org/mailman/listinfo/python-list
Re: random number including 1 - i.e. [0,1]
On Tue, 09 Jun 2009 21:04:49 -0700, Mensanator wrote: 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. Funny, saying The docs are now wrong sure sounds like you're disputing that they're correct to me! I'm simply puzzled why this issue was swept under the rug by pretending it's supposed to work that way. I'm completely confused. What is this issue, and why are we pretending that it's supposed to work that way? Yes, I've read the thread. I still have no idea what you are complaining about. 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. Speak for yourself. What about the change that you think we, the users, want to see? Otherwise, it creates endless confusion. Not as confused as this discussion. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: random number including 1 - i.e. [0,1]
On Jun 9, 11:24 pm, Steven D'Aprano ste...@remove.this.cybersource.com.au wrote: On Tue, 09 Jun 2009 18:28:23 -0700, John Yeung wrote: The docs are now... sort of correct. 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 But you haven't shown what value z has, so there's no way of interpreting that example. I'm pretty aggressive about snipping. I left off the quote of z from Gabriel. He chose z to be the largest value that random.random() can return; namely, the largest float smaller than 1. I've just carried over that value into my example. The point of my example is, with z 1, uniform(0, 1) is always less than 1, but with z 1, uniform(1, 2) can be 2, according to Gabriel's description of uniform(). Therefore, to me the most up-to-date docs (which say that uniform(a, b) returns a float in the closed interval [a, b]) is closer to correct than before, but still fails to point out the full subtlety of the behavior. John -- http://mail.python.org/mailman/listinfo/python-list
Re: random number including 1 - i.e. [0,1]
On Jun 10, 12:01 am, alex23 wuwe...@gmail.com wrote: On Jun 10, 11:32 am, John Yeung gallium.arsen...@gmail.com wrote: On Jun 9, 8:39 pm, Paul McGuire pt...@austin.rr.com wrote: Are you trying to generate a number in the range [0,n] by multiplying a random function that returns [0,1] * n? If so, then you want to do this using: int(random.random()*(n+1)) This will give equal chance of getting any number from 0 to n. Better still is simply random.randint(0, n) There's a big difference between randint - which generates _integers_ in the range 0 n - and the OPs request for generating random floating point values between inclusive of 0 n. Alex, did you bother to read what I quoted? Paul McGuire suggested an alternative in case the OP was choosing integers in a roundabout way. I was merely pointing out that Paul's solution can be more simply achieved using a library function. John -- http://mail.python.org/mailman/listinfo/python-list
Re: random number including 1 - i.e. [0,1]
On Tue, 09 Jun 2009 22:21:26 -0700, John Yeung wrote: On Jun 9, 11:24 pm, Steven D'Aprano ste...@remove.this.cybersource.com.au wrote: On Tue, 09 Jun 2009 18:28:23 -0700, John Yeung wrote: The docs are now... sort of correct. 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 But you haven't shown what value z has, so there's no way of interpreting that example. I'm pretty aggressive about snipping. I left off the quote of z from Gabriel. He chose z to be the largest value that random.random() can return; namely, the largest float smaller than 1. I've just carried over that value into my example. The point of my example is, with z 1, uniform(0, 1) is always less than 1, but with z 1, uniform(1, 2) can be 2, according to Gabriel's description of uniform(). Ah, that explains it. And you're right: import random class MyRandom(random.Random): ... def random(self): ... return 1.0 - 2**-53 ... r = MyRandom() r.uniform(1, 2) 2 False However: r.uniform(1, 10) 10 True Therefore, to me the most up-to-date docs (which say that uniform(a, b) returns a float in the closed interval [a, b]) is closer to correct than before, but still fails to point out the full subtlety of the behavior. Which is? -- Steven -- http://mail.python.org/mailman/listinfo/python-list
