My favorites | Sign in
v8
Project Home Downloads Wiki Issues Source Code Search
New issue   Search
for
  Advanced search   Search tips   Subscriptions
Issue 558: Math.random yields <= 30 bits
5 people starred this issue and may be notified of changes. Back to list
Status:  Fixed
Owner:  whesse@chromium.org
Closed:  Apr 2010


Sign in to add a comment
 
Reported by rice@google.com, Dec 23, 2009
Calling Math.random() * 4294967296 (= 2^32) always yields a number
divisible by 4, indicating that there are really only 30 bits in the
mantissa of Math.random() that are ever non-zero.  It would be nice to have
at least 32 bits worth of randomness so that generation of random 32-bit
integers would require only a single call to Math.random().

This issue was identified by a GWT user at the URL below.  While we can
work around this issue in GWT if need be, it would be nice to have an
improved source of randomness in Chrome/V8.

A simple histgram check in Chrome, Safari, and Firefox indicates that the 4
LSBs of (Math.random() * 4294967296) are pretty evenly distributed in
Safari and Firefox, but only take on the values 0, 4, 8, and 12 in Chrome.
 I'm running Chrome 4.0.249.30 on Mac OS X 10.5.8.

GWT issue: https://code.google.com/p/google-web-toolkit/issues/detail?id=4372

Jan 22, 2010
#1 lrn%chro...@gtempaccount.com
The analysis is correct. There is currently only 30 bits of entrophy in Math.random(), 
so when multiplying by 2^32, the lower two bits will always be zero.


Status: Accepted
Labels: Type-FeatureRequest Priority-Low
Jan 31, 2010
#2 Alexandr...@gmail.com
I have an inkling of what may be going on here:
The Smi (small integer) class which is what Math.random returns only holds 31 bits of 
information. It also happens to be signed while Math.random only returns positive 
numbers. So that's 30 bits only. Now, I'm still trying to figure out how that 
translates to the 2 LSBs always being 0s.
Feb 1, 2010
#3 rice@google.com
Well, we start with a 30-bit quantity, divide by 0x40000000 to obtain a float between 0 and 1, then multiply by 
0x100000000 (=2^32), so we get the original 30 bits shifted left two places.

Apr 6, 2010
Project Member #4 whesse@chromium.org
Changelist http://codereview.chromium.org/1599019 fixes this issue.  It is under 
review.
Owner: whe...@chromium.org
Apr 7, 2010
#5 rice@google.com
Thanks for addressing this issue.


Apr 12, 2010
Project Member #6 whesse@chromium.org
(No comment was entered for this change.)
Status: Fixed
Sign in to add a comment

Powered by Google Project Hosting