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
>> while for minstd_rand it is divided by 0x7ffffffd. Although, I
>> be surprised if it performs badly by some other measure.
>> Come to think of it, uniform_real is meant to be generating a
>> 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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk