
Boost : 
From: John Maddock (john_at_[hidden])
Date: 20060318 05:41:24
> This seems to be dependant on the type of generator you use. Try using
> lagged_fibonacci. The casting and dividing involved in uniform_real
> appears to loose a lot of accuracy, but lagged_fibonacci generates
> doubles between 0 and 1, so there's no cast and it's dividing by 1.
Good idea.
> 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. In the current Boost
implementation if you use a generator that produces int's, then you only get
sizeof(int)*CHAR_BIT random bits in the result (which may or may not get
distributed throughout the double). One solution seems to be to pack a
couple of random int's into one double, but it's a hack I'd rather not get
into just now.
I'll try again with a lagged_fibonacci and see how it looks...
Thanks all,
John.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk