Holy pigeon crap, Batman!

This thread needs less theorizing and assumptions, and more coding. For Pete''s sake, write some code and see for yourself! Massage those 256 pigeons any way you want, you still only have 254 holes! And adding extra pigeons doesn''t help either.

And the reason .9999 repeating = 1 is because once you start using the word "repeating", you''re introducing an infinity into the equation. And including infinity as part of a simple equation results in abnormal behavior.

aig

I''ll do that during tomorrow''s ''boring period''. On paper. Code, maybe later. That''s kieren''s job for now, wherever the heck he went.


Lack

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

I shouldn''t even respond at this point, but...

Lack: You asked why not use the extension? Ummm, because that''s more information that is still part of the compressed file. Assume I can have two different extensions, and that each corresponds to one decompression method. You''re right, I can now fit twice as many files into the same "number" of compressed files. But, that data is still being stored, we''ve just moved it to the operating system instead of the user. And the OS has limits that prevent this from ever working (like if you had a file with no extension, but whose name was already the maximum name length.) These are minor technical details, but it doesn''t change the fact that no matter how clever you program is (looking at file extensions, etc...) when I give you a certain file, you must give me back a decompressed file. You can move information around (store it in the filename), but you can not simply get rid of those N bits of data.

-Brian

This is amazing!!
this must be about the largest thread i''ve EVER seen..
Too bad it is all about a logic mistake though.

any way, i didn''t get any further than page 6 till now, so i''ve gotta keep reading(and laughing ;-)

I was only half serious, but:

Isn''t that how today''s system works? WinZip simply clips a filename to add its extension.

Seriously, though, I do see what you mean. So you can''t compress EVERY file, okay. But you can get pretty good at the rest of them.


Lack

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

*nods in agreement with Brian's last post*

And to quote from the compression faq (yet again. You DID read it, didn't you?):
--------------------------------------------------
This assumes of course that the information available to the decompressor is
only the bit sequence of the compressed data. If external information such as a
file name, a number of iterations, or a bit length is necessary to decompress
the data, the bits necessary to provide the extra information must be included
in the bit count of the compressed data. Otherwise, it would be sufficient to
consider any input data as a number, use this as the file name, iteration count
or bit length, and pretend that the compressed size is zero. For an example of
storing information in the file name, see the program lmfjyh in the 1993
International Obfuscated C Code Contest, available on all comp.sources.misc
archives (Volume 39, Issue 104).
--------------------------------------------------

Deathy

Edited by - deathlok on 4/19/00 5:45:17 PM

Right, I''ve basically finished the demo.
It includes -only- the bit-huffman alogrithm. Just to show how it''s done.
As soon as I can find my XOOM password, i''ll post a link.

Right, I''ve basically finished the demo.
It includes -only- the bit-huffman alogrithm. Just to show how it''s done.
As soon as I can find my XOOM password, i''ll post a link.

And why all this talk of random data? I''m not compressing random data. The point of the alogrithm is that it finds non-random components in the data! No common files use truly random data! ZIP files (as somebody said) use 9- or 12-bit patterns, and TXT files use (mostly) 7-bits!
[:]

So suddenly your entire compression algorithm is irrelevant, but you are posting a demo of Huffman? I could have posted that the day this thread started! Bring on the real stuff!

Pythius

Edited by - Pythius on 4/19/00 5:47:02 PM