Re: [boost] [random] Quantization effects in generating floating point values

Subject: Re: [boost] [random] Quantization effects in generating floating point values
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2015-03-05 11:28:21

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