Re: [boost] uniform_real rather alarmingly non-random?

From: Matthias Troyer (troyer_at_[hidden])
Date: 2006-03-18 09:17:51

>> Interestingly, minstd_rand also seems to work better. Purely
>> speculatively, I think this might be because of the ranges of values
>> it generates - with mt19937 the random number is divided by
>> 0xffffffff,
>> while for minstd_rand it is divided by 0x7ffffffd. Although, I
>> wouldn't
>> be surprised if it performs badly by some other measure.
>>
>> Come to think of it, uniform_real is meant to be generating a
>> half-open
>> range - so maybe it should be diving by (max() - min() + 1) for
>> integers. Looking at the concept documentation: 'For integer
>> generators (i.e. integer T), the generated values x fulfill min() <=
>> x <= max(),
>> for non-integer generators (i.e. non-integer T), the generated values
>> x fulfill min() <= x < max().'
>>
>> Or are you only meant to use floaing point generators when generating
>> a floating point distribution?
>
> No, but.... I've had a private mail from Jens to indicate that this  
> is by
> design, or at least it's a QOI issue not a bug.

It is actually very important that uniform_real creates numbers in a  
half-open interval, and all random number libraries are actually  
implemented that way. To give just one example, the exponential  
distribution need to evaluate an expression like

std::log(1.-u)

where u is a uniform random number in the interval [0,1.). If instead  
u were from the interval [0,1], it could take on the value 1.,  
leading to a zero argument to the log, and thus a problem. The half- 
open interval is thus the right thing to do.

Matthias