Re: The core of the method examined
- From: Thomas Richter <thor@xxxxxxxxxxxxxxxxx>
- Date: Sat, 30 Aug 2008 15:13:56 +0200
Einstein wrote:
On Aug 29, 11:31 am, Thomas Richter <t...@xxxxxxxxxxxxxxxxx> wrote:
Sir your complex return statements belie your lack of understanding of
the context
Yes I use a huffman, rather repeatedly.
I use two versions, one to help make the data run effectively in my
system, and another to 'compress'
Now the math behind the huffman is known to me.
I KNOW IT SIR.
Apparently, you don't understand the consequences. From your description:
> First we COUNT all outcomes of 11, 10, 01, and 00.
> The most occurring becomes 11, the next is 10, then 01, and finally 00
Is this a typo? You give the most occuring sequence "11", which, according to your next step:
> we Huffman Next
>
> 11 = 111
> 10 = 110
> 01 = 10
> 00 = 0
becomes "111", so it gets longer. Sounds more like an ultimate expander to me. The above is supposed to be a replacement rule, right? You replace 11 by 111, etc. If not, you should make yourself clearer.
Ok, so probably that is a typo - you meant "00". Now, giving a source with the probabilities I wrote down above, your input mapping will be the identity map. And the output will have a 50/50 ratio of 0 against 1.
A = percentage of 1's
B = percentage of 2's
( ( A*A) + (A * B) + (B * A) + (B*B)) / 2 = File size % now after
Huffman
You mean, A = probability of 0, and B = probability of 1. Is that an IID input? My input isn't IID, but first order Markov. The probability that a 0 follows a zero is higher than that that a one follows a zero in my input.
How do you arrive at the above? The file size of the huffman output is not given by that, but rather by the average output size, multiply the probablity of the input (which cannot be derived from the probability of a zero or one alone) times the encoded size.
It's so simple, yet you make paragraphs out of it.
So simple, and so wrong. Unless you do something different from what you told.
I do use a Huffman in the capacity of compressing at the end. I make a
big deal out of it, since I know it is not necessarily the best
compression system out there.
However ANY BINARY COMPRESSION SYSTEM CAN BE USED THERE. ANY!!!! OMFG
LETS STRESS THAT WORD ANY AGAIN!!!!
No matter. The replacement rule (00->..., 10->...) *is* a huffman code, and namely for a specific source. And for that specific source, your rule gains *no* bias of zeros or ones.
The Huffman in the beginning is designed SOLELY to make our table, aka
our filing system, aka the fucking key to this, work. It has no
importance beyond that, no cares, no worries, no effects. It is
designed in this case to do something NEW.
Replace "NEW" by "FOOLISH", and I'm with you.
So long.
.
- References:
- The core of the method examined
- From: Einstein
- Re: The core of the method examined
- From: biject
- Re: The core of the method examined
- From: biject
- Re: The core of the method examined
- From: mdsherry
- Re: The core of the method examined
- From: Einstein
- Re: The core of the method examined
- From: Einstein
- The core of the method examined
- Prev by Date: Re: Still no word on what counting arg says about 2^n->2^n mutual information
- Next by Date: Re: The core of the method examined
- Previous by thread: Re: The core of the method examined
- Next by thread: Re: Pete's Really Intensive Compression Kaper
- Index(es):