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: Add triangular distribution to random
Type: Stage:
Components: Library (Lib) Versions: Python 2.6
process
Status: closed Resolution: accepted
Dependencies: Superseder:
Assigned To: rhettinger Nosy List: collinwinter, mark.dickinson, miathan6, paulhankin, rhettinger
Priority: normal Keywords: patch

Created on 2007-03-15 13:09 by miathan6, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
triangular.patch miathan6, 2007-03-15 13:09 Add Triangular distribution to random module
Messages (8)
msg52238 - (view) Author: Wladmir van der Laan (miathan6) Date: 2007-03-15 13:09
This patch adds the so called Triangular distribution for random values. It is often used in simulations when an upper and lower bound is known, and a most likely value but not the exact distribution. This distribution interpolates these values linearly.

http://en.wikipedia.org/wiki/Triangular_distribution
msg52239 - (view) Author: Collin Winter (collinwinter) * (Python committer) Date: 2007-03-16 02:22
Could you work up some tests (Lib/test/test_random.py) and docs (Doc/lib/librandom.tex) for this? An explanation of why you think this should be included in the standard library would be helpful, too.

Also, it seems you made this patch against Python 2.3. While this particular patch still applied (relatively) cleanly to Python 2.6a0 source, Python 2.3 is no longer supported and most patches made against it have a high probability of inapplicability. See http://www.python.org/dev/faq/ for information on how to obtain a read-only checkout of the latest source code.
msg52240 - (view) Author: Wladmir van der Laan (miathan6) Date: 2007-03-16 08:57
Yes, I will add some tests and docs, although usage is quite straightforward. That's the main reason also for adding this distribution, it has three parameters which are intuitive (left, center and right) the distribution is just a linear interpolation (P(left)=0 and P(center)=1 and P(right)=0 ).

I am writing an event simulation and I added it because I was missing some kind of assymetric distribution for timings; in an uniform distribution t-x and t+y would be just as likely as t, in a gaussian distribution you can only set sigma but not the upper and lower bound.

With all the other distributions in there I thought it might come in handy for other people too. I also believe it has its uses in sound generation/processing.

Sorry for providing a patch against 2.3 and not 2.5 or higher, I cooked it up at work and it seems I have this ancient version here.
msg52241 - (view) Author: Paul Hankin (paulhankin) Date: 2007-03-17 16:12
Some minor quibbles: the distributions in random name their parameters after the most common use in math text books. Is n't that 'a, b, c' here rather than 'left, right, center' (note, different order too)? Admittedly your parameter names are clearer.

There's not total consistency in random, but it looks like 'triangularvariate' would be the right name for the function - although my knowledge of stats is sketchy, so perhaps there's a distinction I'm not aware of.

Indentation and spacing around operators needs fixing also.
msg52242 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2007-03-17 16:54
Looks correct to me, and seems to work well with correct parameters.

The arguments to the square roots are never negative; this means that we get silent failure (that is, some distribution that isn't the triangular distribution) if the input parameters don't satisfy left <= center <= right.  Maybe the inputs should be checked, and a
ValueError raised on bad input?

If the test "x < (center-left)/(right-left)" is replaced by "x*(right-left) < (center - left)" then the code does the right thing in the limit-case when left == center == right (that is, it gives a delta distribution at center);  currently it'll raise a ZeroDivisionError in this case.  It's not clear to me which behaviour should be preferred.


msg52243 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2007-04-03 01:43
Will get this fixe-up and applied to Py2.6.  That is due out any time soon, so I'll keep it on my todo list for a bit.
msg52244 - (view) Author: Wladmir van der Laan (miathan6) Date: 2007-05-02 09:28
I found one catch that we might want to avoid. If you input integers into this function instead of floats, it breaks. It might be a good idea to wrap the parameters in float(arg).
msg64356 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2008-03-23 13:32
Applied in r61796
History
Date User Action Args
2022-04-11 14:56:23adminsetgithub: 44724
2008-03-23 13:32:58rhettingersetstatus: open -> closed
resolution: accepted
messages: + msg64356
2007-03-15 13:09:50miathan6create