Hi, after reading that awesome-o-matic comic, I donated $25. The proper e-mail to use for paypal if you cannot get through Sean's pages, is:

sean@seantevis.com

Make the "purpose": Sean Tevis for Kansas

The last update I can get out of his page is that he's at 476 contributors as of 13:45 PDT

Regarding Pi,

It's possible to encode the digits of pi into the binary of the 1024 bits allowed (I'm using the license given to assume a base 2 kilobyte :).

Each digit can be encoded as 4 bits (giving 16 representable values). If given the values of the digits in advance, then you can store 2048 significant digits of pi (4 bits per digit, 1024bytes -> 8192 bits / 4 -> 2048 digits).

Better yet, you could encode using 3 bits (or 8 values) across each 8-bit byte. Then, using the left over 2 bits, indicate if the digit in the following combined 2x3 bit chunks is greater than 7 (0-7 == 8 values). (i.e. 00 111 000 -> digit 1 == 8 digit 2 == 0 and 01 111 000 -> digit 1 == 8 digit 2 == 9)

Then, as the digits are statistically random, you should more often get those first 2 bits set to 0 about one in 4 times (8 values out of 10 will be representable in 3 bits or about 80% of the time. Two chances, works out to chances works out to 64% of the time).

This then allows one to use compression on the bit stream of the digits, as you've introduced a regular occurrence of 0's and reduced the real-noise nature of the stream (i.e. you've moved some bits around so that the zero'd bits tend to regularly end up in the same places). By then moving all of those 2 bit blocks into one place in the bit stream, then running compression (like gzip) on the entire bit stream, you can squeeze in more digits out. Unfortunately, this will work best the longer run of digits you want, with 1024 bytes worth, you don't get any benefit.

Just sayin...