Reduce RandDouble to one call to ldexp, add one bit of precision

Reduce RandDouble to one call to ldexp, add one bit of precision

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=2712

[Mark Mentovai, 2008-09-30 04:53:31]

I realized that we don't need to call ldexp in chunks, we can just call it once
with all of the bits we need.

I also remembered that the mantissa of an IEEE 754 double is actually 53 bits:
52 bits are stored and the high bit is implicitly 1 and not stored.  You can
play around with this and see that this is correct: with kBits > 53, the maximum
possible value for random_bits will yield result == 1.0 (bad, trips the DCHECK)
due to rounding.

[Dean McNamee, 2008-09-30 12:25:20]

Super nice cleanup, thanks.  This really made me realize how  bad my math is,
but from what I can tell it looks good.  I ran some experiments to double check.

Before you commit, can you add something roughly like:


TEST(RandUtilTest, RandDouble) {
  // Force 64-bit precision, making sure we're not in a 80-bit FPU register.
  volatile double val = base::RandDouble();
  EXPECT_GT(1.0, val);
  EXPECT_LE(0.0, val);
}

http://codereview.chromium.org/5801/diff/202/4
File base/rand_util.cc (right):

http://codereview.chromium.org/5801/diff/202/4#newcode34
Line 34: double random_bits = base::RandUInt64() & ((GG_UINT64_C(1) << kBits) -
1);
This doesn't compile on windows without a static_cast.
1>..\rand_util.cc(34) : warning C4244: 'initializing' : conversion from 'uint64'
 to 'double', possible loss of data

http://codereview.chromium.org/5801/diff/202/4#newcode35
Line 35: double result = ldexp(random_bits, -1 * kBits);
irb(main):001:0> x = (2**64 - 1) & ((1 << 53) - 1)
=> 9007199254740991
irb(main):002:0>  x * (2 ** (-53))
=> 1.0
irb(main):003:0>  x * (2 ** (-53)) < 1.0
=> true
irb(main):004:0> 


Hmm, so this is just rounding?  I verified that it seems correct now, by making
RandUInt64 return kuint64max, so that we would get the largest possible double. 
This seems to hold that val < 1.0.  To make sure it wasn't using 80-bit FPU I
bounced it through a volatile which should force 64-bit, and it still looks
good.

[Dean McNamee, 2008-09-30 14:20:29]

LGTM