You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee=Noneclosed_at=<Date2018-01-31.23:51:24.835>created_at=<Date2018-01-31.21:39:14.146>labels= ['type-bug', 'library']
title='random.triangular yields unexpected distribution when args mixed'updated_at=<Date2018-01-31.23:51:24.814>user='https://github.com/epreble'
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.
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.
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.
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: