I admit

[collec...@googlemail.com]

I admit, I only come here for the laughs. The random compression
people are too funny to be missed. :)

I did at first come here for honest questions on compression (as I'd
like to develop my own!), but I don't think I'll be beating the state
of the art compression. I'll be lucky to get to gzip's level! You
never know, I might beat it, but that's not what I'm trying to do.

I'm just coding some compression, because I like coding and I want to
implement a small tiny compressor that's easy to understand, licence
free, very fast, gives acceptably (to me) good compression ratio,
maintainable, and uses a small amount of code. I found it hard to find
any source code that satisfies all of those demands.

But I'm doing some real work (not hobbyist stuff like compression), so
for now I just come here for the laughs. Once I complete my current
paid project, I'll have the time to dabble to do compression. No
records beaten, or even guesses if I'll do better or worse than zlib
(the easiest compressor to add to your apps days) but hopefully I
should make a result that my effort was worth it, that I'll be happy
with my result.

[collec...@googlemail.com]

Sorry, that's not true.

I may beat many personal records. :) The goal is to improve on myself.

But to be tighter than PAQ, or faster than lzop... why bother trying?

[Jim Leonard]

On Aug 12, 4:29 pm, collectio...@googlemail.com wrote:
> I may beat many personal records. :) The goal is to improve on myself.
>
> But to be tighter than PAQ, or faster than lzop... why bother trying?

Both can be slightly improved on, actually. PAQ could be made
stronger with better filters for file types that don't have any (yet),
and lzop is fast but there are even faster methods available, for
example decompression. I myself wrote a decompressor that trades 5%
compression efficiency for 50% faster decompression than lzop on my
specific target platform.

So there are still goals you can meet, especially if no common method
has been created to address your specific computing platform,
language, source material, etc.

[collec...@googlemail.com]

That's good to know there are still goals to meet :)

I think however, my personal goals, are not the extreme goals that are
generally recordable. I might not want the fastest or the tighest
compressor... but just the perfect "best of both" that at least for
me, is the best match of both :)

Other people however may consider the most optimal compressor for a
particular application, to perform faster than mine, or tighter than
mine even if slower.

Would be sucky though if my code was both slower and compressed worse
than zlib :)

[Jim Leonard]

On Aug 12, 5:21 pm, collectio...@googlemail.com wrote:
> Other people however may consider the most optimal compressor for a
> particular application, to perform faster than mine, or tighter than
> mine even if slower.
>
> Would be sucky though if my code was both slower and compressed worse
> than zlib :)

I've found Chuck Bloom's LZP a fascinating diversion; check it out.
It's LZ77 without the match offsets, only the length, and it
outperforms zlib/zip's compression ratio if you give it a decent
statistical coder and a little bit of memory for higher-order contexts.