Repository navigation
Measuring entropy #22
Replies: 2 comments
|
The entropy measure is pretty meaningless if we don't do the entropy coding afterwards. That's why I'm not considering adding an order-1 entropy calculator - most of the code would be the same as if I just wrote a simple ok-ish arithmetic coder. |
|
I'm not sure I get what you mean. This is my understanding: an entropy measure function gives a very similar result to an arithmetic encoder. An arithmetic encoder actually does the encoding while the measure function is just simulation the encoding (with -log2(p)*x). So they are the same when it's all about measuring entropy. If you actually want to do the compression (not just measure entropy) then you do need an arithmetic encoder. Is this what you meant? However since you have only a transform at this moment and no modelling, you yourself alone cannot really judge if the transform is good or not. |
Uh oh!
There was an error while loading. Please reload this page.
The current "MeasureEntropy" implementation works like this: for all "input" bytes, read them, look up that byte in a dictionary, increase occurrence. Then sum these occurrences (totalFrequency) and calculate the total entropy along the dictionary entries.
Probably it can be made faster: create an uint "counter" array of 256, use a for loop to read all bytes from input, increase counter in array. You don't need to sum the occurrences (totalFrequency) - it equals to the length of the input.
Then calculate entropy along each "counter" array element where the counter is nonzero.
However...
There is one problem with measuring the entropy per input byte: it's an order-0 model. No compression software is an order-0 model, so making any decisions based on the order-0 entropy is not "solid" or "realistic" enough.
All reactions