Not 2 camps, but 3. Third camp is those who believe that this is not a hoax, but that kieren_j is delusional. Well, actually mistaken would be a better word.

Mike Roberts
aka milo
mlbobs@telocity.com

I'm waiting for the program. And I bet I can come up with data that it can't compress, or compress without losing data.

From what I can see, it doesn't make sense mathematically to be able to compress COMPLETELY ramdom data. It's like this:

Combinations for 2 bits:
00 01 10 11
No more, no less. 4 patterns. NEED TWO binary digits to represent.

3 bits:
000 001 010 011 100 101 110 111
No more, no less. 8 patterns. NEED THREE binary digits to represent ALL combinations.

4 bits:
0000 0001 0010 0011 0100 0101 0110 0111 1000 1001 1010 1011 1100 1101 1110 1111
No more, no less!!! 16 patterns to account for! REQUIRES FOUR binary digits to represent! The combinations you must account for increases as the digits increase. At best, you'd be remapping the patterns, not compressing them.

Personally, I won't believe it until I have a demo. POST THE @*$$%^# DEMO!

OH, and don't forget to tell us where we can get it.

Edited by - CobraA1 on 4/17/00 11:41:42 AM

Joviex, look at CobraA1''s post. With a n bit pattern you can''t compress each of the 2^n variations that can be stored in n bits. You could interpret the n bit pattern as an unsigned integer which can have values from 0 to 2^n - 1. Now find a operation which can map each of the possible values to a smaller array of unsigned integers, and you must have an invers operation which maps the number from the smaller array back to the original number so that you get back exactly the same number, and you should be able to do this with every unsigned integer from 0 to 2^n - 1. That''s impossible, and it''s the same thing as being able to compress each n bit pattern to a smaller one - with a deterministic decompression algorithm.
So I think most of us who don''t believe kieren don''t say that random data isn''t compressable just because somebody has told it us.

m0rpheus, do you believe anything you hear? You should proof everything yourself before believing it, and these compression ratios are impossible.

Visit our homepage: www.rarebyte.de.st

GA

milo2120, to which camp do you count me??

Visit our homepage: www.rarebyte.de.st

GA

Edited by - ga on 4/17/00 1:51:21 PM

And then there''s 4th camp. Who just follow the thread, and don''t actually care if this whole thing is true or not. I''m waiting for kieren to prove himself, but if he won''t, then that''s it.. I won''t be left disappointed. But it''s interesting to see anyways if he''s coming up with something or not.

See, we really don''t all know whether or not he''s really made something. If he hasn''t, then all that stuff about proven theories still stands. But if he has, then first of all, are the theories wrong, and second, how did he come up with it? Just makes you think...

Hey, did I make the 10th page?


ColdfireV

I've been following this thread off and on for a while and figured I'd add my $0.02

I have to agree with the proofs given that it is impossible to develop a compression algorithm that can compress *any* data. This is the same as saying that random data connot be compressed, but I would argue that it may be possible to develop a way of compressing alredy compressed data. Compression relies on some type of regularity in the data which can be eliminated to save space. In most cases, this regularity is in the form or repeated bits or bit sequences. On the filp side, however, these algorithms will fail on data which does not have such patterns and will necessarily make the file *larger* (since lossless compression is a 1 to 1 mapping)

Now consider this: what if there where a method that could take advantage of the "randomness" of the data. In this case, I don't mean randomness as in true randomness (ie, allowing every combination) but in the sense that there are no traditional paterns. In this case, it might be possible to exploit this property to compress the data.

I was working on a program that counts the number of ones in each byte of a file to see if the distribution for .zip files is biased toward the middle values of 3-5 ones more than completely random data should be, but after some initial testing its clear that the reading is not working properly... the output only counts a small fraction of the actual size of the .zip file. I think that something like this may be happening to kieren in his programs and this could be causing the confusion. If this is not the case and he actually has some compression method, then wonderful.

Here is my code, if anyone could point out what I'm doing wrong and how I can read and index the entire file, please let me know

#include #include int main (){    int bitcount;    char nextbyte;    int bits[9] = {0,0,0,0,0,0,0,0,0};    cout << "filename: " << endl;    ifstream file("E:/Downloads/New/dx7adxf.exe");    if (file.bad())    {	cout << "Could not open file." << endl;	return(1);    }    while (!file.eof())    {	file.read(&nextbyte, 1);	bitcount = 0;	while (nextbyte > 0)	{	    if ((nextbyte % 2) == 1)	    {		bitcount++;	    }	    nextbyte /= 2;	}	bits[bitcount]++;    }    cout << "0-bits: " << bits[0] << endl;    cout << "1-bits: " << bits[1] << endl;    cout << "2-bits: " << bits[2] << endl;    cout << "3-bits: " << bits[3] << endl;    cout << "4-bits: " << bits[4] << endl;    cout << "5-bits: " << bits[5] << endl;    cout << "6-bits: " << bits[6] << endl;    cout << "7-bits: " << bits[7] << endl;    cout << "8-bits: " << bits[8] << endl;    return(0);}  

Edited by - chippydip on 4/17/00 3:13:50 PM

kieren_j, replacing the most common byte with a zero-bit and all other data with set bit followed by the original byte isn''t going to compress data, at least not MP3''s, WAVs, MPEGs. It works on pictures and sometimes with texts also, believe me, I''ve tried it.

Re-arranging bytes to make files more vulnerable for compression might work though. The only problem is, that there are infinite ways to re-arrange data, so how do you know what''s the best way to do it?

Oh yeah, I''ve already heard of a super-compression algorithm a year ago. It rearranged data and used some kind of key to get the original data back. But I''ve never heard of it since then...

But I hope your new compression-program is really going to work. By the way, what kind of demo are you going to post? The decompression-program with a compressed .MP3 or something else? Well, either way, I''m looking forward to see it.

-my 2 cents-

It''s nearly done now.

Which one, the Huffman or the original one you were doing?


Lack

Christianity, Creation, metric, Dvorak, and BeOS for all!