
Boost : 
From: Matthias Troyer (troyer_at_[hidden])
Date: 20060318 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
>> halfopen
>> 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 noninteger generators (i.e. noninteger 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
halfopen 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk