You're right, it would be impossible to compress ALL randomly occouring data, and it would probably be possible to compress a specific random block of data if you knew what to look for. I've never admitted that compressing random data with a general algorithm was possible, even though i still dabble with the idea of compressing certain types of random data with a general algorithm. The reason? It's just something to burn time. In the months i've spent researching the impossible i've learnt things i woulden't have otherwise. 4d math is a good example.
The mistake both you and Mike make is that while writing a program for the general case of compressing random data is impossible, it is very different than writing a program to compress one specific file of 'random' data.
First off, if you have the ability to compress randomly occurring data (that is, each bit has an approximately 50/50 chance of occurring), i seriously doubt you'd send $100 to some guy you don't know in the hope that he'll send you $5000 back. Why, he'd just reverse engineer the decompressor, patent it, get rich, and buy an island inhabited with young bikini clad virgins before the your check had even cleared.
Secondly, i've been thinking about this problem for about 3 years now.:) I've tried so many methods and ways of interpreting and looking at random data, i'd have enough to write a book if i'd bothered to keep accurate logs. If i had $1 for every time i said "I'VE GOT IT!" i'd probably have $5000 already. Well, maybe that's a tad off the mark, but anyway, you get my point. Right, onto my conclusion...
Imagine that you have three sets of numbers, X, Y and Z. X constitutes all currently compressible data (say, a bit of text). Y all seemingly random data (say, a text file compressed with zip, or Pi/2 rounded off to 4000 digits). And finally Z, all purely random-occurring evenly distributed data. Let A(n), B(n) and C(n) be functions that spit out the n'th number contained within the respective sets, in ascending order.
Now, for all possible combinations of bits within a 128KB file (2^1048576) how many numbers fall into each of X, Y and Z?
If an infinitely fast computer could calculate all numbers contained within the set Z, and X+Y was a few times greater than Z, then storing the value of 'n' might just compress...
awww shit, no it won't... cos the decompressor would be huge. Ah well, that's another $1 into the bogus ideas piggie bank.
Slashdot Mirror
You're right, it would be impossible to compress ALL randomly occouring data, and it would probably be possible to compress a specific random block of data if you knew what to look for. I've never admitted that compressing random data with a general algorithm was possible, even though i still dabble with the idea of compressing certain types of random data with a general algorithm. The reason? It's just something to burn time. In the months i've spent researching the impossible i've learnt things i woulden't have otherwise. 4d math is a good example.
The mistake both you and Mike make is that while writing a program for the general case of compressing random data is impossible, it is very different than writing a program to compress one specific file of 'random' data.
'If' is a very usefull concept.
First off, if you have the ability to compress randomly occurring data (that is, each bit has an approximately 50/50 chance of occurring), i seriously doubt you'd send $100 to some guy you don't know in the hope that he'll send you $5000 back. Why, he'd just reverse engineer the decompressor, patent it, get rich, and buy an island inhabited with young bikini clad virgins before the your check had even cleared.
Secondly, i've been thinking about this problem for about 3 years now.
Imagine that you have three sets of numbers, X, Y and Z. X constitutes all currently compressible data (say, a bit of text). Y all seemingly random data (say, a text file compressed with zip, or Pi/2 rounded off to 4000 digits). And finally Z, all purely random-occurring evenly distributed data. Let A(n), B(n) and C(n) be functions that spit out the n'th number contained within the respective sets, in ascending order.
Now, for all possible combinations of bits within a 128KB file (2^1048576) how many numbers fall into each of X, Y and Z?
If an infinitely fast computer could calculate all numbers contained within the set Z, and X+Y was a few times greater than Z, then storing the value of 'n' might just compress...
awww shit, no it won't... cos the decompressor would be huge. Ah well, that's another $1 into the bogus ideas piggie bank.