🚀 go-pugleaf

>>>>> On 24 Mar 91 15:21:06 GMT, shaw@pegasus.com (Sandy Shaw) said:

Sandy> I am trying to get the maximum compression possible of the following
Sandy> 32 byte hex file(in ASC): 

Sandy> f3e9 ec5c 8bec ecdb ece9 ec12 ec3f ecec
Sandy> 0cbb 8bec 5cdb ecdb 5c9c bbec 8bdb 9cec

Sandy> The best results I get are using the compact utility(adaptive Huffman). This
Sandy> gives 21.88% compression or 7 bytes saved. Does anyone out there have a 
Sandy> scheme that can improve on this? 

Yes:

        I can compress this file down to 1 byte (one bit really) with the following
algorithm:

        If file data is equal to "f3e9 .... 9cec" then output 0
        else output 1 followed by file data.

The expansion function is obvious.

Another algorithm that I could use for the above data is:

        if next byte is 'ec' then output 1 else output (0 followed by byte).
        
This results in 32 control bits + 20 bytes of data. This is 24 bytes
-- a saving of 8 bytes. 

I suspect that this is not the sort of answer that you wanted. You
need to be more precise about the other data you want to compress. For
example, compression of the following data:

1 78 123 511 985 ...
or
3 45 67 999 ...

can be done in a number of ways. The information that the format of
the data is a sequence of non-decreasing integers seperated by
whitespace allows you to use a better compression algorithm. In many
applications for compression, a great deal is known about the data
before you start. This information should be used in designing the
algorithm. The various programs like compress, pack, arc, etc all make
assumptions about the data they are working on. When the assumptions
are incorrect, they act as expansion programs!

Philip
--
Philip Gladstone         Dev Lab Europe, Data General, Cambridge, UK

    Listen three eyes, don't you try and outweird me, I get
    stranger things than you free with my breakfast cereal.