Quote:
|
Originally Posted by ThomasTuttle
So, here's how it works?
First, you have two constant bytes. Like the "GZ" from gzip, or the "BZ" from bzip2.
Then you have a bunch of 7-, 8-, or 9-byte strings. It works like this, I assume:
ASCII 00###### -> Compressed 1###### (8 bits to 7 bits, 25% of the time)
ASCII 01###### -> Compressed 00###### (8 bits to 8 bits, 25% of the time)
ASCII 1####### -> Compressed 01####### (8 bits to 9 bits, 50% of the time)
Given a random input file, each byte from 0-255 will appear the same number of time. Thus, the average size of a compressed byte is:
(7 * 25%) + (8 * 25%) + (9 * 50%) = 1.75 + 2 + 4.5 = 8.25.
Thus, the file expands by 1/64.
So, unless your input files contain mostly bytes that translate to your 7-bit strings, you should be seeing the file *increase* in size by 1/64 each time, not *decrease* in size.
If your program makes the files smaller when they shouldn't be, chances are it's either cheating, using very compressible input files, or losing data--have you written and tested the decompressor yet? ;-)
If I'm wrong, please correct me--I'm interested in seeing how it actually works if this isn't how it works.
See ya,
Tom
|
Yes this would have been a problem, but I had solved it already and it involves a little bit more then that. Trust me I will have the program ready for someone to test out, or more then one if everyone wishes so.
This is how the testing is going to be done, Im first going to send the decompressor to the tester. Next they send me all the files they want me to test (please try to stay under 10 megs, right now it is capable of up to 100 megs because i havent put in the memory swapping yet, but since its just a test I dont see the need for any bigger. But if you wish to try bigger ones...). Next I will compress the files they sent me and Ill send them back to the tester for them to decompressed and varifyed to see if they work. This way I cant make a program to work for only that file so it should be pretty good proff.