Compression - Unilimited Data Compression

Author

Unilimited Data Compression

rachid baih

2005-11-08, 9:55 pm

A new method of compression (unilimited & High-Performance Data
Compression )

http://www.newalgo.tk

If you need more details don't hesitate to contact me :

sta_staf@hotmail.com

jackokring@gmail.com

2005-11-09, 3:55 am

basically no source compression has major problems with all cases. best
bet is absorbtion of source into an high entrpy finitly generated
carrier.

Willem

2005-11-09, 3:55 am

rachid wrote:
) A new method of compression (unilimited & High-Performance Data
) Compression )
)
)
) http://www.newalgo.tk
)
) If you need more details don't hesitate to contact me :

This method has been discussed several times before, nothing new about it.
It doesn't work. I refer you to the Counting Theorem.

SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

Jim Leonard

2005-11-09, 6:55 pm

Willem wrote:
> This method has been discussed several times before, nothing new about it.
> It doesn't work. I refer you to the Counting Theorem.

For giggles last night, I decided to spend 30 minutes writing a "factor
it down" general-purpose compressor that worked by trying to find the
best x^y combo that came closest to a particular chunk of the file (I
used 256-bit numbers), recorded that, then took the difference and did
that, etc. until you were left with a small prime number. Discounting
the fact that it was horribly slow, I realized while tweaking it that I
was essentially duplicating a range coder and deleted the code shortly
afterwards :-)

But yes, counting theorum applied because there were very few cases
(exactly one, actually) where I was lucky enough to hit on an x^y that
exactly matched my target and resulted in actual space savings over an
arithmatic coder.

michael

2005-11-09, 6:55 pm

Jim Leonard wrote:
> Willem wrote:
>
> For giggles last night, I decided to spend 30 minutes writing a "factor
> it down" general-purpose compressor that worked by trying to find the
> best x^y combo that came closest to a particular chunk of the file (I
> used 256-bit numbers), recorded that, then took the difference and did
> that, etc. until you were left with a small prime number. Discounting
> the fact that it was horribly slow, I realized while tweaking it that I
> was essentially duplicating a range coder and deleted the code shortly
> afterwards :-)
>
> But yes, counting theorum applied because there were very few cases
> (exactly one, actually) where I was lucky enough to hit on an x^y that
> exactly matched my target and resulted in actual space savings over an
> arithmatic coder.

And I spent about 30 minutes trying to figure out what "unilimited"
means. (^:

- Michael

and_polar

2005-11-11, 2:25 pm

The method has no value before you provide quick technique of factoring extra larger integers. The impossibility of factoring large integers is the base of security of RSA encryption. Theoretically you can represent a whole message as A1^B1*A2^B2*...*AN^BN, but for comparison brute force attack on factoring 1024 bit integer requires time similar to existance of Universe.

Dag-Erling Smørgrav

2005-12-09, 9:55 pm

"rachid baih" <sta_staf@hotmail.com> writes:
> http://www.newalgo.tk

Your conjecture is trivial to prove. 2^n has no other prime factors
than 2; therefore 2^n cannot be divisible by 9x, which has 3 amongst
its prime factors.

It is equally trivial to prove that "unlimited data compression" is
impossible. Finding such proof in the comp.compression FAQ is left as
an exercise for the reader.

DES
--
Dag-Erling Smørgrav - des@des.no

Sponsored Links