B writes:
> PPS. This isn't as off-topic is it seems. Being able to analyze the
> results of a predictive test is important to validating algorithms. In
> fact, last night after reading about Gavin's 26,000,000 coin tosses, I
> spent a fair amount of time in Knuth V.2 reading about how to evaluate
> random number generators. That's important, since Gavin didn't actually
> toss a coin 26,000,000 times; he just ran a linear congruential generator
> 26,000,000 times.

Which is why I qualified my original results with the phrase "or maybe
there's something wrong with my coin".

> The validity of Gavin's simulation depends on the behavior of
> the algorithm.

Which from BASIC/V is probably the old MPE/V compiler library RAND function,
which has proved to be reasonable for this sort of use in the past.  After
having gotten an empirical result that was so out of line with all of the
predictions up to that point, I did try using the random number generator
differently to see if I was just getting unlucky.

> I'm way too pushed at the moment to program any of these tests, but Gavin
> might want to take a stab :-).

There's probably already an implementation somewhere, as people who ask on
sci.crypt about their "wonderful new source of random numbers" for
cryptographic purposes are always told to "go read Knuth" to learn how to
test the quality of their "random" numbers.

Of course for the problem in question, flipping millions of coins turns out
to be a waste of time when the precise answer can more easily be found by
examining each of the possible outcomes with something like:

#include <stdio.h>

int main() {

  int i=0, m=0, f, j;

  printf("Starting scan...\n");

  while (i < (1<<20)) {
    f = 0;
    for (j=0; j<15; j++) {
    if ((i & (63<<j)) == 63<<j) f = 1;
    }
    m += f;
    i++;
  }

  printf("Evaluated: %d.\n", i);
  printf("Matched:   %d.\n", m);

  return 0;
}

G.