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.

classification
Title: random.cunifvariate() incorrect?
Type: Stage:
Components: Library (Lib) Versions: Python 2.3
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: rhettinger Nosy List: abcdefghijklmno, loewis, rhettinger, tim.peters
Priority: normal Keywords:

Created on 2002-01-21 21:19 by abcdefghijklmno, last changed 2022-04-10 16:04 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
cuni.diff rhettinger, 2002-05-14 21:53 Doc and module patch
rand.diff rhettinger, 2002-05-21 14:05 Patch to random.py and librandom.tex
Messages (6)
msg8926 - (view) Author: Maciej Kalisiak (abcdefghijklmno) Date: 2002-01-21 21:19
random.cunifvariate() currently is defined as:
  return (mean + arc * (self.random() - 0.5)) % _pi

First of all, this returns values in the range [0, pi)
due to the modulus, which really makes it a
semi-circular distribution, not circular (but I'm not a
mathie, so perhaps I'm wrong).

I think the normalizing step ("% _pi", or whatever this
gets changed to) should probably be mentioned in the
documentation for this function; it caught me by
surprise, and I expect it will catch some others too.  

With this defintion, the function returns a random
value in the range [mean-arc/2, mean+arc/2).  The docs
say that arc, like mean, can only be in the range
[0,pi].  This would imply that one cannot get values in
the other half of the circle, i.e. [pi, 2*pi).  Since
there doesn't seem to be anything stopping the caller
from using an arc in [0,2*pi], perhaps the
documentation should be updated?
msg8927 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2002-05-14 21:53
Logged In: YES 
user_id=80475

Martin, please approve the patch and I'll load it for Py2.3.

The docs don't match the function and the actual behavior 
is weird.  Thinking in degrees, calling with a mean of 175 
and an arc of 20 returns {x | 0<x<5 or 165<x<180} with an 
expected mean of 130 instead of the specified mean of 175.

Google reports no non-Python examples of cunifvariate so 
there is no standard to match against.

The patch removes the Pi normalization in the 
implementation and removes the superfluous domain 
restriction in the docs.
msg8928 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2002-05-15 11:00
Logged In: YES 
user_id=21627

I'm not qualified to comment on the correctness of this
change, so unassigning it. Maybe Tim knows what a
cunifvariate is?
msg8929 - (view) Author: Tim Peters (tim.peters) * (Python committer) Date: 2002-05-21 03:11
Logged In: YES 
user_id=31435

I recommend to deprecate this function instead of "fixing" 
it.  If we deprecate it in 2.3, we can lose it entirely for 
2.4.  The function appears useless to me with or without 
the suggested fixes, and anyone who *did* want 
something "like this" would just call random.uniform() 
passing appropriate bounds anyway.  Indeed, Raymond's patch 
amounts to making cunifvariate a synonym for calling 
random.uniform(mean-arc/2, mean+arc/2).  We don't need a 
separate function for something so trivial.

BTW, I've never seen the word "cunifvariate" outside of 
Python's random module.
msg8930 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2002-05-21 03:27
Logged In: YES 
user_id=80475

So be it.  

If there are no objections received before Thursday May 
24th, I'll deprecate it.
msg8931 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2002-05-23 19:46
Logged In: YES 
user_id=80475

Added normalization comment to docs put in a 
deprecation warning.  Committed as random.py 1.33 and 
librandom.tex 1.29.
History
Date User Action Args
2022-04-10 16:04:54adminsetgithub: 35962
2002-01-21 21:19:58abcdefghijklmnocreate