code in the ruins

I'm not a math geek, but occasionally something piques my interest. Today I was trying to work out a good way to do something randomly about once every nine or ten times. I decided to check the last digit of the return value of Javascript's Math.random() function, which returns a number between 0 and 1. Like this:

0.1809368982206232

I knew it would never be zero, since the trailing zero would be removed; so I figured I could pick any other digit and I'd be right about once every nine times.

Turns out it doesn't work like that. The frequency distribution of the last digit is uneven.

<script type="text/javascript">
for (var num=1; num<=9; num++) {
var match = 0;
var re = new RegExp(num+'$');
for (var i=0; i<10000; i++) {
if (re.test(Math.random())) { match++; }
}
document.write("<p>" + num + ": " +
(match/i*100+'').substring(0,5) + "%</p>");
}
</script>

This script calls Math.random() 10,000 times for each digit from 1 to 9. It prints the last digit match rate as a percentage. Its output looks like this:

1: 8.790%
2: 10.4%
3: 12.19%
4: 13.17%
5: 13%
6: 12.95%
7: 11.51%
8: 9.35%
9: 8.58%

You'd expect something around 11.11% (one of nine) for each digit; but you can see that the frequency increases until 4, and then decreases again. In fact, this looks a heck of a lot like a bell curve, ergo, a Gaussian distribution.

I found that if I check the first digit after the decimal point, I get what I'm expecting: a list of roughly equal values somewhere around 11.11% for each digit. So although the output of Math.random() is uniformly distributed, the last digits are normally distributed.

I can't grok this much further than that; perhaps it's got something to do with the way the numbers are generated, or maybe that's just The Way Things Are^TM. If anyone can explain to me why this happens, leave a note. Maybe I'll go poke around in the Gecko source code or something.

I've gotten a great response from my initial release of the Batch image uploader. So let me first say thanks to everyone who left their comments and suggestions.

Today I'm releasing the next version of the plugin - Batch image uploader 0.2. The killer feature this time around is the ability to use different "backends" to resize the images. (This was initially suggested by Alexander Radsby.) There are three supported backends right now: GD, mogrify, and imagick.

GD is PHP's default image processing library. It's fast, but the quality of the images is not so good. This is what version 0.1 of the plugin used, and it's still an option in version 0.2.

mogrify has nothing to do with me, other than being the program from which I chose my Internet identity many years ago. It's actually one of the programs in the ImageMagick distribution of command-line image processing tools. This backend offers far better image quality, but is most likely slower, than GD. To use this, you have to have ImageMagick installed, and you have to tell my plugin where to find the mogrify binary. On UNIX systems, this is nearly always /usr/bin/mogrify, so that's the default.

Finally, imagick is the imagick PECL extension for PHP. It has the same image quality as the mogrify program, but is likely to be a great deal faster. This is because it uses ImageMagick libraries instead of invoking a program, so there is none of the overhead involved with starting another shell process.

You can force the plugin to use any one of these backends, but I recommend using the 'Auto' option. This will automatically select the best available backend, in this order: imagick, mogrify, GD. You can figure out which one it's using if you enable the debugging info.

With ImageMagick support comes support for dozens of image formats. The GD backend still only supports PNG, JPG, or GIF images.

The download and other current information is at the Batch image uploader page.