compression heuristic algorithm

compression heuristic algorithm

[Paul Gimpelj]

hi,

I am looking for an algorithm.

Can anyone help.

Hypothesis:  There is a shift register system that will produce a repeatable
and predictable sequence of values. This sequence can be totally defined
with a starting value and the input parameters to the shift register system.

In other words 700mb of file can be compacted to one byte and a matrix of
parameters to input into the shift register system.
And the file will be compacted by 99.9% or greater. So 10 cds can be
distributed in 1.44 floppy format.

The pratical aspect is to have an heuristic to determine the matrix of
parameters, Time to compute is relatively unimportant since the file is to
be archived.

Thanks,

regards,
Paul ( operations research graduate)

Re: compression heuristic algorithm, and more interesting trivia

[Charlie Gordon]

A more lucrative variation on the same algorithm :
Find a heuristic and starting matrix whereby each draw of a casino roulette
can be accurately predicted (to better than 1 percent)
Or a patriotic variation : find practical algorithm to predict the votes of
pseudo random population of 50 states, do away with election costs and
uncertainty.

Surely you're joking !

No, in fact I already have an implementation : matrix is just 10000 by 10000
64 bit integers for a single 700 MB file !
just doubling matrix sizes allows for 4 fold increase on file size ability !
3D version of said double matrix compresses google database down to 1 byte !
Maybe I should patent it a make lots of dollars...

Chqrlie.



"Paul Gimpelj" <pgimpelj@sympatico.ca> wrote in message
news:004001c45af4$9b7da7c0$c901010a@zoom...
> hi,
>
> I am looking for an algorithm.
>
> Can anyone help.
>
> Hypothesis:  There is a shift register system that will produce a
repeatable
> and predictable sequence of values. This sequence can be totally defined
> with a starting value and the input parameters to the shift register
system.
>
> In other words 700mb of file can be compacted to one byte and a matrix of
> parameters to input into the shift register system.
> And the file will be compacted by 99.9% or greater. So 10 cds can be
> distributed in 1.44 floppy format.
>
> The pratical aspect is to have an heuristic to determine the matrix of
> parameters, Time to compute is relatively unimportant since the file is to
> be archived.
>
> Thanks,
>
> regards,
> Paul ( operations research graduate)
>
> -
> To unsubscribe from this list: send the line "unsubscribe
linux-c-programming" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: compression heuristic algorithm, and more interesting trivia

[Paul Gimpelj]

thats still 200mb , which is (1 -200/700)  > 1%,
nice but not compact enough.

thanks
----- Original Message -----
From: "Charlie Gordon" <gmane@chqrlie.org>
To: <linux-c-programming@vger.kernel.org>
Sent: Friday, June 25, 2004 5:39 PM
Subject: Re: compression heuristic algorithm, and more interesting trivia


> A more lucrative variation on the same algorithm :
> Find a heuristic and starting matrix whereby each draw of a casino
roulette
> can be accurately predicted (to better than 1 percent)
> Or a patriotic variation : find practical algorithm to predict the votes
of
> pseudo random population of 50 states, do away with election costs and
> uncertainty.
>
> Surely you're joking !
>
> No, in fact I already have an implementation : matrix is just 10000 by
10000
> 64 bit integers for a single 700 MB file !
> just doubling matrix sizes allows for 4 fold increase on file size ability
!
> 3D version of said double matrix compresses google database down to 1 byte
!
> Maybe I should patent it a make lots of dollars...
>
> Chqrlie.
>
>
>
> "Paul Gimpelj" <pgimpelj@sympatico.ca> wrote in message
> news:004001c45af4$9b7da7c0$c901010a@zoom...
> > hi,
> >
> > I am looking for an algorithm.
> >
> > Can anyone help.
> >
> > Hypothesis:  There is a shift register system that will produce a
> repeatable
> > and predictable sequence of values. This sequence can be totally defined
> > with a starting value and the input parameters to the shift register
> system.
> >
> > In other words 700mb of file can be compacted to one byte and a matrix
of
> > parameters to input into the shift register system.
> > And the file will be compacted by 99.9% or greater. So 10 cds can be
> > distributed in 1.44 floppy format.
> >
> > The pratical aspect is to have an heuristic to determine the matrix of
> > parameters, Time to compute is relatively unimportant since the file is
to
> > be archived.
> >
> > Thanks,
> >
> > regards,
> > Paul ( operations research graduate)
> >
> > -
> > To unsubscribe from this list: send the line "unsubscribe
> linux-c-programming" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >
>
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe
linux-c-programming" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: compression heuristic algorithm

[John Richard Moser]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Try using a PRNG "wheel" algorithm with each "wheel" generating X values
each with N possible branch possibilities to alter position p to another
calculated position on the wheel, with value Z to select which wheel to
use; and use a bitlanguage to specify the changes and steps.

This actually works; the problem is that it works for finite numbers X,
N, and p; and infinite number Z.  There comes a point when Z must be
made of coumpounding values that substitute for Z such that V(A,Z1,Z2)
== V(A,Z).

Also, even though you can do it, there's no known algorithm to reverse a
stream of numbers into a set of parameters; for every input stream of
every length there is one or more output streams to define it, and so
there's no way to correlate input stream directly to one output stream.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFA3KnzhDd4aOud5P8RAmZVAJ45w7tFgP8iLn/tMDlMZBlhSeo9uACeIGvE
mevAv0usOk1OIc6ZLvTBGqI=
=jPHA
-----END PGP SIGNATURE-----

Re: compression heuristic algorithm

[Paul Gimpelj]

Thanks John.

You are saying for more complex streams there is more than one solution,
If I understand you. I will do some research into the prng wheel.


I'm interested in this.
Theory states it is possible. And presently for simple shift registers the
seeds can be reversed from the past history sequence, which allows
predicting 100% of the future generated  sequence values.

Then there is the idea of close enough, which may not be adequate for
program executables but may be fine for audio video.
What would it be worth, I wonder, if a dvd could be compressed by 80 to 90%?

Thanks again,


----- Original Message -----
From: "John Richard Moser" <nigelenki@comcast.net>
To: "Paul Gimpelj" <pgimpelj@sympatico.ca>;
<linux-c-programming@vger.kernel.org>
Sent: Friday, June 25, 2004 6:40 PM
Subject: Re: compression heuristic algorithm


> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> Try using a PRNG "wheel" algorithm with each "wheel" generating X values
> each with N possible branch possibilities to alter position p to another
> calculated position on the wheel, with value Z to select which wheel to
> use; and use a bitlanguage to specify the changes and steps.
>
> This actually works; the problem is that it works for finite numbers X,
> N, and p; and infinite number Z.  There comes a point when Z must be
> made of coumpounding values that substitute for Z such that V(A,Z1,Z2)
> == V(A,Z).
>
> Also, even though you can do it, there's no known algorithm to reverse a
> stream of numbers into a set of parameters; for every input stream of
> every length there is one or more output streams to define it, and so
> there's no way to correlate input stream directly to one output stream.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.4 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>
> iD8DBQFA3KnzhDd4aOud5P8RAmZVAJ45w7tFgP8iLn/tMDlMZBlhSeo9uACeIGvE
> mevAv0usOk1OIc6ZLvTBGqI=
> =jPHA
> -----END PGP SIGNATURE-----