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