Question

Can anyone please explain arithmetic encoding for data compression with implementation details ? I have surfed through internet and found mark nelson’s post but the implementation’s technique is indeed unclear to me after trying for many hours.

Mark nelson’s explanation on arithmetic coding can be located at

http://marknelson.us/1991/02/01/arithmetic-coding-statistical-modeling-data-compression/

Answer 1

The main idea with arithmetic compression is its the capability to code a probability using the exact amount of data length required.

This amount of data is known, proven by Shannon, and can be calculated simply by using the following formula : -log2(p)

For example, if p=50%, then you need 1 bit.
And if p=25%, you need 2 bits.

That’s simple enough for probabilities which are power of 2 (and in this special case, huffman coding could be enough). But what if the probability is 63% ? Then you need -log2(0.63) = 0.67 bits. Sounds tricky…

This property is especially important if your probability is high. If you can predict something with a 95% accuracy, then you only need 0.074 bits to represent a good guess. Which means you are going to compress a lot.

Now, how to do that ?

Well, it’s simpler than it sounds. You will divide your range depending on probabilities. For example, if you have a range of 100, 2 possible events, and a probability of 95% for the 1st one, then the first 95 values will say “Event 1”, and the last 5 remaining values will say “Event 2”.

OK, but on computers, we are accustomed to use powers of 2. For example, with 16 bits, you have a range of 65536 possible values. Just do the same : take the 1st 95% of the range (which is 62259) to say “Event 1”, and the rest to say “Event 2”. You obviously have a problem of “rounding” (precision), but as long as you have enough values to distribute, it does not matter too much. Furthermore, you are not constrained to 2 events, you could have a myriad of events. All that matters is that values are allocated depending on the probabilities of each event.

OK, but now i have 62259 possible values to say “Event 1”, and 3277 to say “Event 2”. Which one should i choose ?
Well, any of them will do. Wether it is 1, 30, 5500 or 62256, it still means “Event 1”.

In fact, deciding which value to select will not depend on the current guess, but on the next ones.

Suppose i’m having “Event 1”. So now i have to choose any value between 0 and 62256. On next guess, i have the same distribution (95% Event 1, 5% Event 2). I will simply allocate the distribution map with these probabilities. Except that this time, it is distributed over 62256 values. And we continue like this, reducing the range of values with each guess.

So in fact, we are defining “ranges”, which narrow with each guess. At some point, however, there is a problem of accuracy, because very little values remain.

The idea, is to simply “inflate” the range again. For example, each time the range goes below 32768 (2^15), you output the highest bit, and multiply the rest by 2 (effectively shifting the values by one bit left). By continuously doing like this, you are outputting bits one by one, as they are being settled by the series of guesses.

Now the relation with compression becomes obvious : when the range are narrowed swiftly (ex : 5%), you output a lot of bits to get the range back above the limit. On the other hand, when the probability is very high, the range narrow very slowly. You can even have a lot of guesses before outputting your first bits. That’s how it is possible to compress an event to “a fraction of a bit”.

I’ve intentionally used the terms “probability”, “guess”, “events” to keep this article generic. But for data compression, you just to replace them with the way you want to model your data. For example, the next event can be the next byte; in this case, you have 256 of them.