Arc Forumnew | comments | leaders | submitlogin
1 point by palsecam 5602 days ago | link | parent

From what I've seen, the numbers should be fairly random. It is often humans that misunderstand randomness, and not computers, as said in the linked article in CatDancer's post.

However, randomness is a complex issue in computing, and it's good to keep it in mind. See for example:

* "How I Hacked Hacker News" (http://news.ycombinator.com/item?id=639976) that exploited a vulnerability in 'rand-string.

* A famous "bug" with rand(0,1) in PHP on Windows: http://cod.ifies.com/2008/05/php-rand01-on-windows-openssl-r....

* The Unix `rand' command:

   $ man 3 rand  # here on a linux system
   [...]
   NOTES
   The versions of rand() and srand() in the Linux C Library use 
   the same random number generator as random(3) and srandom(3),
   so the lower-order bits should be as random as the higher-order 
   bits.
   However, on older rand() implementations, and on current 
   implementations on different systems, the lower-order bits are
   much less random than the higher-order bits.

It means, on old systems, the situation is something like:

- rand() outputs a 4 bits integer, so the value goes from 0 to 15,

- if you do 'rand() % 10', there is a 2/16 probability you get a number in [0, 5], and only 1/16 you get a number in [6, 9].



1 point by shader 5602 days ago | link

Mind if I ask where the other 13/16 went? Since rand() % 10 can only output 0-10 there are only 10 possibilities, all of which are covered in your two ranges.

Either people frequently have problems with statistics as well, or random numbers are really complicated ;)

-----

1 point by palsecam 5602 days ago | link

Well, I'm totally not an expert in "randomness assisted by computer", I just know it's something, like cryptography, where you should be careful before implementing your own solution. And I am bad in maths, and statistics/probas are so tricky (at least for me), you are right.

However, a code demonstration (in Perl, sorry, for perf/convenience):

   # We fake a bad `rand()' function by only taking 
   # values between 0 and 15.
   $cnt{rand(15) % 10} += 1 for (0..1_000_000);
   print $_, "\t", $cnt{$_}, "\n" for (sort keys %cnt);
outputs:

   0       133556
   1       133050
   2       133423
   3       132772
   4       133342
   5       66815
   6       67065
   7       66582
   8       66858
   9       66538
Are you OK with this demonstration or shall I try to find a more formal explanation/example?

-----

3 points by absz 5601 days ago | link

What you said is correct; the only problem is that with the numbers you quoted, the total probability of rolling a number in the range [0,10) is 2/16 + 1/16 = 3/16 < 1 :) The numbers you meant to quote, as borne out by your data above, are a 10/16 = 5/8 chance to get a number in the range [0,5), and a 6/16 = 3/8 chance to get a number in the range [6,10). (Equivalently, a 12/16 = 3/4 chance to get a number in the range [0,5] and a 4/16 = 1/4 chance to get a number in the range [6,9], but since that doesn't partition the [0,10) range evenly, it's less instructive.)

-----

1 point by palsecam 5601 days ago | link

Thanks for the rectification :-)

-----

2 points by palsecam 5602 days ago | link

The same thing in Arc:

   (let num->occ (table [for i 0 9 (= _.i 0)])
      (repeat 1000000  ; 1 million iterations
         (++ (num->occ (mod (rand 15) 10))))
      (each k (sort < (keys num->occ))
         (prn k "\t" (num->occ k))))
(~ same output than the Perl version)

Just for information:

   $ time perl < test-rand15.pl
   0m1.545s
   $ time mzscheme -m -f as.scm < test-rand15.arc
   0m17.374s
   $ time java -jar rainbow.jar < test-rand15.arc2 
   0m32.104s

-----