Boost C++ Libraries: Ticket #6059: uniform_real_distribution fails when _min = _max

Steven Watanabe — Tue, 25 Oct 2011 21:08:12 GMT

min == max is illegal, because the range [min, max) is empty. Thus there are no legal values for the distribution to produce.

dario.izzo@… — Wed, 26 Oct 2011 16:36:36 GMT

OK, then if this is a design choice, it would be nice to have a warning or an exception be thrown rather then an infinite loop produced (also because the behavior has changed since boost 1.46 (and my code was counting on the previous behavior :)

NOTE: I can actually see many reasons to allow min==max and return min, but I guess this choice has already been made ....

Thanks for taking the time to answer so promptly

Sat, 01 Sep 2012 16:55:29 GMT

@steve_watanabe if min == max is illegal then shouldn't the ASSERT in the constructor be _min < _max instead of "<=" as it is now? This is rather diceiving as I expected it to throw some error in the condition of _min == _max (which in my case only occurred to due a bug in my code that calculated the range). Had the assert in uniform_real_distribution been correct I would have been able to find the error quicker.

status changed; resolution set

Steven Watanabe — Sat, 16 Feb 2013 21:14:25 GMT

status new → closed
resolution → fixed

(In [82937]) Fix assertion for uniform_real. Fixes #6053. Fixes #6059.

harris.pc@… — Thu, 06 Jun 2013 11:05:28 GMT

Why has this bug been fixed, but in boost 1.53.0, the assert remains the same as it was before (incorrect!)

See uniform_real_distribution.hpp

harris.pc@… — Thu, 06 Jun 2013 11:08:02 GMT

Ah, the patch came after 1.53.0, I think.

pontus — Wed, 13 Nov 2013 17:49:16 GMT

Still not fixed in 1.55.0

digigram@… — Wed, 04 Dec 2013 19:22:44 GMT

this is a regression from 1.47 where min=max was allowed and returned the expected value. The regression breaks existing software. The logical return would simply be the max or min value when there is no range and so the proposed >= should be right.

More fundamental, if the numerator<=divisor and both are greater than 0 than result should always be between min and max (including max) and the for loop really does not make any sense unless max is not allowed to be part of the range, but I would not know why it shouldn't be. In matter of fact, I would say max should be part of the range simply because the max of a dice is 6 and the min is 1 and six can be thrown.

So I propose to remove the for loop altogether, and the if assertion as well.

dario.izzo@… — Fri, 06 Dec 2013 10:19:52 GMT

I would also love to see this fixed allowing max==min (in which case min is returned). I had to patch all my code manually to allow this behaviour explicitly .... any hope to see this implemented?