Re^5: Dynamically Updating Frequency Analysis

Does this make sense?

Yes, (sort of :), but I still think that you are on a hiding to nothing with it. The problem is that each time you change things, everything changes and must be recalculated.

But worse, you may well find yourself in an infinite loop. That is, you make a change, that pushes one thing out in favour of another; but when you recalculate the numbers flip the other way and favour bringing back the one you just kicked out in place of the one you just added.

That would be relatively easy to detect if the periodicity is 2 or 3; but with 32 slots to fill, the periodicity could theoretically 31!

You mention a time limit; but what would you set it to? Too short and you'll leave most of your 32 slots unfilled a lot of the time; too long and your burning cpu for no benefit.

The beauty of LZW is that it processes the input as a stream; never going back to try and apply the latest changes to the earlier part of the data. Whilst that has the disadvantage that the early part of the stream may not be as compressed as it might be; it has the major advantage of being a time-efficient, deterministic process.

Going back to a recent discussion regarding P v NP; it is 'good enough' when seeking perfection might never complete.

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

Comment on Re^5: Dynamically Updating Frequency Analysis

Replies are listed 'Best First'.

Re^6: Dynamically Updating Frequency Analysis
by Limbic~Region (Chancellor) on May 09, 2013 at 18:13 UTC

BrowserUk

Once the data structure has been built, I am going to use it a number of times to determine the best compression I can using some boundaries. The first time will set the high water mark. Pick the item that gives the maximum compression and remove it from the list - which in return removes some other items completely while reducing others. Pick the next highest on the list and repeat. Stop when 32 items have been chosen. Now, start over (tree is completely re-ininitialized to its original form). This time, use an alternate picking strategy - perhaps you alternate from the top of the list on odd number turns and the second highest on even numbered turns. If after selecting 32 items you have reached a higher compression than the previous highest, it becomes your new water mark.

As far as how long (assuming a time based approach rather than a fixed number of iterations) - I see that as being a command line option. Just as gzip has a -1 through -9 to trade time for compression, this may be a way to let the user choose.

I really like the adaptive version of LZW. If you fill up your dictionary and the portion of the file you are compressing currently isn't benefiting much from it - dump the dictionary and start over.

Cheers - L~R

[reply]


Clear questions and runnable code get the best and fastest answer
	PerlMonks