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.triangular yields unexpected distribution when args mixed
Type: behavior Stage: resolved
Components: Library (Lib) Versions: Python 3.6, Python 2.7
process
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: Nosy List: eddieprebs, rhettinger
Priority: normal Keywords:

Created on 2018-01-31 21:39 by eddieprebs, last changed 2022-04-11 14:58 by admin. This issue is now closed.

Messages (2)
msg311377 - (view) Author: Edward Preble (eddieprebs) Date: 2018-01-31 21:39
The random.triangular function produces an unexpected distribution result (instead of an error or warning message) when the order of the 3 arguments are mixed up.

Python notebook with demo of issue here:
https://github.com/epreble/random_triangular_distribution_issue

Cases 1-4 are OK
1. random.triangular(low, high, mode) (Docs specified usage)
2. random.triangular(high, low, mode)
3. random.triangular(low, high)
4. random.triangular(high, low)

Incorrect argument input (e.g. numpy style) yields distributions that are NOT 3-value-triangular and the output is also from different ranges than expected:

Incorrect arguments (first one is numpy.random.triangular style)
6. random.triangular(low, mode, high) 
or:
7. random.triangular(high, mode, low)

Raising errors was discouraged in prior discussion (https://bugs.python.org/issue13355) due to back compatibility concerns. However, I would argue that output of an incorrect distribution without a warning is a problem that -should- be broken, even in old code.

A possible solution, that might not break the old code (I haven't looked at all the edge cases):

If 3 arguments provided, need to be sure the mode is arg3:
If arg1 < arg2 < arg3, this is definitely wrong since the mode is definitely in the middle (wrong position).
If arg1 > arg2 > arg3, this is definitely wrong since the mode is definitely in the middle (wrong position).

Those tests would not break the old use cases, since the signs of the tests switch between arg1/arg2/arg3:
  low, high, mode (would be arg1 < arg2 > arg3)
  high, low, mode (would be arg1 > arg2 < arg3)

Not positive how all the <=, >= combos work out with these tests.
msg311391 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2018-01-31 23:51
Sorry, while appreciate the sentiment and how well you articulated it, I'm going to decline this one for the reasons listed in the original discussion at https://bugs.python.org/issue13355 and because it is important to keep this code fast and light (so that large numbers of random variates can be created).  Also, for your own code, it is trivially easy to wrap the existing function with your own error checking.  Lastly, the ship for 2.7 sailed many years ago.  

Note, almost note of the random functions can defend themselves are incorrect argument order.  And who knows, there may be legitimate use cases for having the midpoint not between the low and high.
History
Date User Action Args
2022-04-11 14:58:57adminsetgithub: 76917
2018-01-31 23:51:24rhettingersetstatus: open -> closed

nosy: + rhettinger
messages: + msg311391

resolution: rejected
stage: resolved
2018-01-31 21:39:14eddieprebscreate