Boost logo

Boost :

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


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, gregod at, cpdaniel at, john at