This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author mark.dickinson
Recipients hailperin, mark.dickinson
Date 2009-01-18.09:47:10
SpamBayes Score 1.7924551e-13
Marked as misclassified No
Message-id <1232272034.73.0.199286768553.issue4979@psf.upfronthosting.co.za>
In-reply-to
Content
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.
History
Date User Action Args
2009-01-18 09:47:14mark.dickinsonsetrecipients: + mark.dickinson, hailperin
2009-01-18 09:47:14mark.dickinsonsetmessageid: <1232272034.73.0.199286768553.issue4979@psf.upfronthosting.co.za>
2009-01-18 09:47:11mark.dickinsonlinkissue4979 messages
2009-01-18 09:47:10mark.dickinsoncreate