classification
Title: random.uniform can return its upper limit
Type: behavior Stage:
Components: Library (Lib) Versions: Python 3.0, Python 3.1, Python 2.7, Python 2.6
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: georg.brandl, ggenellina, hailperin, mark.dickinson
Priority: normal Keywords: patch

Created on 2009-01-18 00:03 by hailperin, last changed 2009-01-18 13:24 by georg.brandl. This issue is now closed.

Files
File name Uploaded Description Edit
random.diff ggenellina, 2009-01-18 10:55
Messages (4)
msg80062 - (view) Author: Max Hailperin (hailperin) Date: 2009-01-18 00:03
The documentation for random.uniform says that random.uniform(a,b) 
should return a number strictly less than b, assuming a<b.  (The result 
should be strictly less than a if a>b.)  Thus both of the following 
expressions should always evaluate to False:

a<b and b in [random.uniform(a,b) for i in range(20)]
a<b and b in [random.uniform(b,a) for i in range(20)]

Yet both of them evaluate to True (except, presumably, one time in a 
million) after doing the following assignments:

a = 1.0
b = 1.0 + 2.0**-52

Other values of a and b also exist for which random.uniform will 
sometimes return its upper limit.  (For example, the -52 can be 
increased to -51, -50, etc., with correspondingly less frequent 
violations of the spec.)

Because this is a case where the code is violating an explicit 
specification in the documentation, I'm reporting it as a behavior bug.  
But perhaps the behavior is as intended and the documentation is at 
fault.  For that reason, I'm also emailing docs@python.org.
 
The documentation would in any case need a little touching up, in that 
it has a self-contradictory specification for the case where a=b.  There 
is no value N for which a<=N<b, given a=b.  That minor touch-up could be 
combined with allowing the behavior described in this bug report, if 
that behavior is in fact desired.
msg80083 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2009-01-18 09:47
The distinction between < and <= is fairly meaningless when applied to a 
computed floating-point result.  I think the docs should be fixed to 
replace the < with <=.  In any case, the b <= N < a bit has the 
inequalities the wrong way around: presumably it was intended to read b < 
N <= a.  The docs for random.triangular should also be fixed in the same 
way.

(N.B. What *is* always true is that the result of random.random() is never 
1.0.  And that's a useful property---without it, random.uniform(a, b) can 
even return values *outside* the closed interval [a, b].)

To me, it doesn't seem worth slowing down random.uniform itself with extra 
checks: it's the sort of function that often gets called millions of times 
within a simulation, or numerical algorithm (e.g. Monte-Carlo 
integration), and it's trivial for the user to add his or her own check if 
necessary.

I also think it's a nice property that random.uniform currently degrades 
gracefully when a == b, producing the expected point distribution at a.  I 
wouldn't want to change that.

So:  +1 for amending the docs.  -1 for changing random.uniform.
msg80090 - (view) Author: Gabriel Genellina (ggenellina) Date: 2009-01-18 10:55
Doc update
msg80095 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2009-01-18 13:24
Thanks, applied in r68724.
History
Date User Action Args
2009-01-18 13:24:18georg.brandlsetstatus: open -> closed
resolution: fixed
messages: + msg80095
nosy: + georg.brandl
2009-01-18 10:55:41ggenellinasetfiles: + random.diff
keywords: + patch
messages: + msg80090
nosy: + ggenellina
2009-01-18 09:47:12mark.dickinsonsetnosy: + mark.dickinson
messages: + msg80083
versions: + Python 2.6, Python 3.1, Python 2.7
2009-01-18 00:03:17hailperincreate