Re: Repeatable compression is possible and easy to do, here's how...

On Oct 21, 4:19 pm, jg <jules.sto...@xxxxxxxxx> wrote:
Assume two bit data.

Call this data 'client'.

Establish three streams of pseudo-random data, each two bits wide.

z1 = client ^ a;

z2 = b ^ c;

z = z1 - z2;

Strip the sign-bit, now the 'z' variable is two bits too.

And!, drumroll -- it has a distribution, as z will contain more values
near zero. Thus, a stream of z values is 'easily' compressed.

Not by a lot, that's true. But you can do this again and again. I
have. It works.

And by the way, that "counting argument" that you fools seem to be in
love with disallows not only repeatable compression but regular
compression too. I've said this before yet everyone seems willing to
ignore basic natural science. If you want to disprove repeatable
compression you need to come up with a theory that (at a minimum!,)
*allows* conventional compression. So far, I have yet to see even an
attempt at this.

Notice I am giving this away...

Because the decompressor isn't so trivial. It involves some algebra,
some cleverness, and some C-code. Which means my method is perfectly
safe here.

--jg

Actually instead of all the hand waving. If your method worked. You
don't need
to show all the equations. For a given two bit slice show us the table
of
values for a b c client. that is 256 values. For each of these show
the resulting
two bit z output. It would then be childs play to construct a table
given
a b c z to give the output client. Each table would contain exactly
256 cases.
You could make the table shorter if you realize that b and c used in
only
one spot replace b^c with z then the tables would be only 64 seperate
cases.
That is do this if you want anyone to actually take it seriously.
But if you don't
want people to see what you think you have then don't bother.

The problem with your idea is just what are these so called
three streams of pseudo-random data streams. The reason its
a problem. Is that for any so called client I could cherry pick
3 pseudo-random looking streams that would make a cleint
say binary value of pi map to all zeros and that would be very
compressable. However it would map most other client streams
to something incompressable buy standard means. If your compression
requires hand picked pusedo random streams to work then what use
is it if you need to know which hand picked streams where used for
which compression. Just a thought.

David A. Scott

P.S.
Here is another way to look at the problem since a b c are
independent of client (meaning a b c not picked after client picked)
you could look at the four entries of table where only client takes on
4
seperate values see if the z out is the four separte values if not
then you method is not reversible.
Assuming it reversible. I do belive you can run it over
and over again until you find a set of a b c that would allow
a shorter compression. But that fact alone requires knowledge
of which has to be stored either in the compressed file of elsewhere.
If not stored in file then most would save its not real compression.

--
My Crypto code
http://bijective.dogma.net/crypto/scott19u.zip
http://www.jim.com/jamesd/Kong/scott19u.zip old version
My Compression code http://bijective.dogma.net/
**TO EMAIL ME drop the roman "five" **
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.
As a famous person once said "any cryptograhic
system is only as strong as its weakest link"

.

Relevant Pages