AMDG On 03/05/2015 06:39 AM, John Maddock wrote:
First off, I notice there are no examples for generating floating point values in Boost.Random, so maybe what follows is based on a misunderstanding, or maybe not...
Lets say I generate values in [0,1] like so:
boost::random::mt19937 engine; boost::random::uniform_01<boost::random::mt19937, FPT> d(engine);
FPT d = d(); //etc
Where FPT is some floating point type.
<aside> You're using the old interface to uniform_01 here, which is deprecated because it is inconsistent with the rest of the distributions. </aside>
Now my concern is that we're taking a 32-bit random integer and "stretching" it to a floating point type with rather more bits (53 for a double, maybe 113 for a long double, even more in the multi-precision world). So quantization effects will mean that there are many values which can never be generated.
It's true that I could use independent_bits_engine to gang together multiple random values and then pass that to uniform_01, however that supposes we have an unsigned integer type available with enough bits. cpp_int from boost.multiprecision would do it, and this does work, but the conversions involved aren't particularly cheap. It occurs to me that an equivalent to independent_bit_engine but for floating point types could be much more efficient - especially in the binary floating point case.
It's called generate_canonical.
So I guess my questions are:
Am I worrying unnecessarily? and
I don't think so. I haven't worried about it much because, as Thijs points out, using a 64-bit engine works well enough for float and double, which accounts for most use cases. For multiprecision, it could be an issue.
What is best practice in this area anyway?
I really don't know. In Christ, Steven Watanabe