Hi, Bob.

BL>  PE> Now what you see here is that the compressed sizes are
BL>  PE> different!!!

BL>   Isn't that normal? If you zip a file ten times you get ten subtly
BL> different zipped-sizes, all with the same CRC. It's a bloody nuisance,

Are you sure about that? Ten different times with the same h/w & s/w
congig?

BL> and I've often wondered why that would be... there's got to be
BL> something random involved in the zip.

See my message to Paul. If the compression algorithm can use more memory
to keep a larger table, it can compress more effectively. Here's an
example, loosely based on Richard Brent's compression algorithm...

the cat was there, on the mat he was.

might encode as...

the cat was (12,3)re, on (22,4)m(22,3)he(25,4).

where the oredered pairs in parentheses represent the distance back in
the file where the same string can be found, and the length of that
string. Let's assume those pairs can be efficiently encoded (you'd
probably use Huffman encoding here) in 1 byte each (both numbers in 1
byte). The original phrase of 37 bytes encodes as 27 bytes.

Now, assume you only have enough memory to keep 20 bytes of "history".
You'd get...

the cat was (12,3)re, on(10,4) mat he was.

The compressed phrase is now 32 bytes.

Hopefully I haven't made any arithmetic errors there, in calculating the
offsets backwards into the file. If I have, you should get the idea
anyway.

Oh, I've just noticed that I could have replaced the
"he" string
near the end with a pair too, can't be bothered recalculating.

Regards, fIM.

 * * Share and enjoy, share and enjoy!
@EOT:

---