Home > Archive > Compression > April 2005 > Compression with better compatibility ratio (was: Re: ANN(again): slightly newer tool
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Compression with better compatibility ratio (was: Re: ANN(again): slightly newer tool
|
|
| Otto Wyss 2005-04-06, 12:40 pm |
| cr88192 <cr88192@NOSPAM.hotmail.com> wrote:
> basically, same site as last tools, and same thing.
> ok, I have made some adjustments to the tools (fixing some bugs, ...), and I
> have also made some minor adjustments to the format (should not effect
> archives made by the last one, but I haven't really checked).
>
Of course you are free to do what you want but IMO it doesn't make much
sense to create yet_another_compression unless it has something which
others don't already have. Luckally there is something no current
compression can do.
Whenever you compress a source file in two just minimal different
version, the two compressed files are completely different. Just assume
once the two version differ only in the first letter, all the rest is
equal. But since then the lookup table differ from the beginning, each
entry is off by one position, the compressed files are completely
different.
IMO it shouldn't be much difficult to create an algo which has a much
better compatibility ratio between versions of source against compressed
files as all the current algos have.
O. Wyss
--
Development of frame buffer drivers: http://linux-fbdev.sf.net
Sample code snippets for wxWidgets: http://wxcode.sf.net
How to build well-designed applications: http://wyoguide.sf.net
Desktop with a consistent look and feel: http://wyodesktop.sf.net
| |
| cr88192 2005-04-06, 12:40 pm |
|
"Otto Wyss" <otto.wyss@orpatec.ch> wrote in message
news:1gueozz.16bkiqs1xtv2m8N%otto.wyss@orpatec.ch...
> cr88192 <cr88192@NOSPAM.hotmail.com> wrote:
>
> Of course you are free to do what you want but IMO it doesn't make much
> sense to create yet_another_compression unless it has something which
> others don't already have. Luckally there is something no current
> compression can do.
>
> Whenever you compress a source file in two just minimal different
> version, the two compressed files are completely different. Just assume
> once the two version differ only in the first letter, all the rest is
> equal. But since then the lookup table differ from the beginning, each
> entry is off by one position, the compressed files are completely
> different.
>
> IMO it shouldn't be much difficult to create an algo which has a much
> better compatibility ratio between versions of source against compressed
> files as all the current algos have.
>
well, I never claimed to have any good reason for doing this.
now I am more just feeling the pull to go off and write a "cleaner"
geometry/physics api than my last one, which had become an unmanagable
mess...
> O. Wyss
>
> --
> Development of frame buffer drivers: http://linux-fbdev.sf.net
> Sample code snippets for wxWidgets: http://wxcode.sf.net
> How to build well-designed applications: http://wyoguide.sf.net
> Desktop with a consistent look and feel: http://wyodesktop.sf.net
|
|
|
|
|