Data Compression Essay, Research Paper

?Data Compression? just sounds complicated. Don?t be

afraid, compression is our good friend for many reasons. It saves hard drive

space. It makes data files to handle. It also cuts those immense file download

times from the Internet. Wouldn?t it be nice if we could compress all files

down to just a few bytes?

There is a limit to how much you can compress

a file. How random the file is, is the determining factor to how far it can

be compressed. If the file is completely random and no pattern can be found,

then the shortest representation of the file is the file it self. The actual

proof that proves this is at the end of my paper. The key to compressing a

file is to find some sort of exploitable pattern. Most of this paper will

be explaining those patterns that are commonly used.

Null suppression is

the most primitive form of data compression that I could find. Basically,

it says that if you have different fields that data is in (possibly a spread

sheet), and any of them have only zeros in them, then the program just eliminates

the data and goes straight from the empty data set to the next.

Only one

step up from null suppression is Run Length Encoding. Run length encoding

simply tells you how many of what you have in a row. It would change a set

of binary data like {0011100001} into what the computer reads as (2)zeros,

(3)ones, (4)zeros, 1. As you can see, it works on the same basic idea of finding

a series of 0?s (null suppression) and 1?s in this case too and abbreviating

them.

Once the whole idea of data compression caught on, more people started

working on programs for it. From these people we got some new premises to

work with. Substitutional encoding is a big one. It was invented jointly

by two people: Abraham Lempel and Jakob Ziv. Most compression algorithms (big

word meaning roughly ?program?) using substitutional encoding start with ?LZ?

for Lempel-Ziv.

LZ-77 is a really neat compression in which the program

starts off just copying the source file over to the new target file, but when

it recognizes a phrase of data that it has previously written, it replaces

the second set of data in the target file with directions on how to get to

the first occurrence of it and copy it in the directions? place. This is more

commonly called a sliding-window compression because the focus of the program

is always sliding all around the file.

LZ-78 is the compression that most

people have in their homes. Some of the more common ones are ZIP, LHA, ARJ,

ZOO, and GZIP. The main idea behind LZ-78 is a ?dictionary?. Yet it works

quite a bit like the LZ-77. For every phrase it comes across, it indexes the

string by a number and writes it in a ?dictionary?. When the program comes

across the same string, it uses the associated number in the ?dictionary? instead

of the string. The ?dictionary? is then written along side the compressed

file to be used in decoding.

There is a combined version of LZ-77 an

LZ-78. It is called LZFG. It only writes to the dictionary when it finds

the repeated phrase, not on every phrase. Then instead of LZFG replacing the

second set of data with directions on how to get to the first occurrence of

it, the program puts in the number reference for the dictionary?s translation.

Not only is it faster, but it compresses better because of the fact that it

doesn?t have as big of a dictionary attached.

Statistical encoding is another

one of the new compression concepts. It is an offshoot of the LZ family of

compressors; It uses basically the same style as LZFG, but instead of assigning

the numbers in order that the strings come out of the source file, statistical

compressors do some research. It calculates the number of times each string

is used and then ranks the string with the most number of uses at the top of

the hash table. The string with the least is ranked at the bottom. (A hash

table is where the rank is figured) The higher up a string is on this list,

the smaller of a reference number it gets to minimize the total bit usage.

This gives this compression just a slight edge on the others, but every little

bit helps. (ha ha -bit- )

Beware! There are a few compression programs

out there that claim wonderful compression ratios; ratios that beat the compression

limit for that file?s randomness. These programs aren?t really compression

programs. They are OWS and WIC. Never compress anything with these. What

they do is split up the file that you desired to compress and hide most of

it on another part of your hard drive. OWS puts it in a specific spot on the

physical hard drive disk. WIC puts the extra information in a hidden file

called winfile.dll. The real problems with these programs are that if you

don?t have the winfile.dll or the information on the certain spot on your drive,

then the program won?t put your file back together.

My original intent

with this project was to invent a new compression algorithm. I started with

the idea that if you took the file in its pure binary form and laid it out

in a matrix, there were certain rows and columns that you could add up to get

an output that would be able to recreate the original matrix. I was close

too. I had four different outputs that actually would be what would make up

the compressed file that combined together to create one output for each bit.

From this single output I could determine if the bit was 1 or 0. It worked

perfectly for matrixes of 1×1, 2×2, and 3×3. Except that with this small of

a matrix, I wasn?t compressing it at all. It was more of a coding system that

took up more space than did the original file. I even found a way to shrink

the size of the four outputs but it was not enough to even break even on bit

count. When I got to the 4×4?s I found an overlap. An overlap is a term I

made up for this algorithm. It means that I got the same single output for

a 1

as I did a 0. When that happens, I can?t figure out which it is: a 1

or 0. When you can?t recreate the original file, data compression has failed.

It becomes lossy. I needed a fifth original output. If you want more information

on how I thought the algorithm would have worked, please refer to my Inventor?s

Log that I included. It?s way too much to re-type here and it would serve

no real purpose in this paper.

If you were paying attention earlier, you

would be saying, ?Why don?t you find a pattern? Otherwise you can?t compress

it. You are treating it like a random file.? I didn?t find out that it was

impossible to compress random data until about the time my algorithm was failing.

Because

of my setbacks I started looking for an entirely new way to compress data,

using a pattern of some sort. I got to thinking about all of the existing

algorithms. I wanted to combine a hash table, statistical coder, and a run

length coder. The only hard part that I would see in that would be trying

to get the patent holders of each of those algorithms to allow me to combine

them and actually modify them slightly.

In its current algorithm, the statistical

coder only accepts alpha-numeric phrases. I would like to modify it to not

read the characters that the binary code spells out, but the binary code it

self. I don?t know what form the output is aside from compressed, but for

my purposes it wouldn?t matter what the form the output is. I would program

into the program all of the 32 combinations of 5 bits (2^5). Each of the combinations

would be labeled in the program 1 through 32. I would then make a hash table

of all of the 5 bit combinations. This would give me an output which I would

run through a run length coder. Since the entire algorithm is reliant on binary

code and not on characters, it can be recursable, or it can compress further

an already compressed file. LZ?s can?t do that because once they convert a

string into it?s dictionary/sliding window form, it ceases to be one of the

characters that it compresses.

Now that you are aquatinted with our friend,

Data Compression, I hope he will be able to serve you better. Now you can

download programs faster, save space, and who knows? Maybe you will invent

the next new compression algorithm. Until then, keep your mice happy and your

monitors warm.

Proof that random data is not compressible:

Let?s suppose

the file to be compressed is 8 bits long (x works, but this is easier) and

is random

There are exactly 2^8 different possible 8 bit data strings. (2^x)

To

compress the file it must shrink it by at least one bit (2^x)-1

So there are

at most 2^7 different compressed files 2^(x-1)

Thus at least two source files

compress down to the same file.

Therefore\ The compression cannot be lossless.

Bibliography

Aronson, Jules Data Compression- a comparison of Methods

Washington D.C.: Institute for Computer Science and Technology

http://simr02.si.ehu.es/DOCS/mice/compression-faq/part1/faq-doc-x.html

x=Intro,8,9, and 10

http://www.epl.co.uk/genit18.htm

http://www.sees.bangor.ac.uk/~gerry/sp_summary.html

http://Literacy.com//mkp/pages/3468/index.html