* Store the first 16 or 32 matches for the last 16 words in the
input that are compressible by lz77 (shortening blocks that have
occured before to the location and length of such comparison). If a
hit occurs, simply compare it to the first matches and scan from the
last match on if full.
* Store the last 16 or 32 non-matches. Scan these for the current
input first, and if found, check it for a match to current and remove
the entry.
Again, I don't think these would help much. In fact, on poorly
compressible files, it may take longer. I am looking for other
techniques to speed up this technique. I assume I must minimize the
hits. Any help would be appreciated.
I'm sorry, but this is related to Apple II, how?
And, even if it were, it should be discussed in the
CSA2.programmer group.
Bill Garber from GS-Electronics
http://www.garberstreet.com
"If you wish to forget anything on the spot,
make a note that this thing is to be remembered."
(Edgar Allen Poe)
> I am working on file compression. I mentioned in a previous thread
> that I did better than others. I was wrong.
Oh, I'm so surprised!
> The experiment was
> blotted by a bug. Now I'm getting results about as good as PKWare's
> deflate/maximum technique. I still have ideas. Again, it may be due
> to an error. Again, as mentioned previously, it is very slow. I have
> in mind some techniques to speed up the compression. They wouldn't be
> that good:
Then why re-invent the wheel?
> Again, I don't think these would help much. In fact, on poorly
> compressible files, it may take longer. I am looking for other
> techniques to speed up this technique. I assume I must minimize the
> hits. Any help would be appreciated.
Give it up, and use somebody else's wheel!
You don't go around making your own tires, do you?
OUCH! You really know how to hurt a guy. ;-)
> Then why re-invent the wheel?
Seriously, can we stop responding to this twat? If it looks like a
duck, and quacks like a duck, it's a duck! Trolls are no different.
You should all know better!
Matt