Science and Technology news... :: View topic

Einstein · Guest

This is just to stir debate and talk, not to say 'eureka I solved it'
and post nonsense :P

The counting argument is used to justify the fact that it is
impossible to obtain recursive lossless compression. The counting
argument is simple in nature. Every possible outcome of 4 bits cannot
become every possible outcome of 3 bits, nor any other standard can be
applied. It is also known as the pigeonhole principle.

An example of this at work.
If you have 12 programs and this is the 'actual code' of those twelve
programs...

000
001
010
100
011
101
110
111
00
01
10
11

Then you have issues if you are trying to compress downward these
programs. Under some systems some of our programs can compress, but do
to mathematical or statistical luck. Most however will usually be
uncompressible, or you need to incorporate loss into the system to be
able to continue.

There has been many efforts to bypass the counting argument. These all
require systems which add bits to something one could call 'a command
section' or 'identifying bits'. Ultimately each has failed.

However if there were a way, then these following to me would seem to
be the only ways possible to 'defeat' the counting system with one
'still out there' requirement.

1) Segments
You take a long section of code. You subdivide it into subsections.
Each section can be compressed or not compressed separately. Your
issue is effectively identifying the sections and what is happening
inside of them. Using the pigeonhole example, we have 16 pigeon holes.
If we make it 4 sets of four we can then possibly close several holes
in some sets and have say 12 holes in a 2,3,4,3 pattern but still have
a maximum possible 16 holes which may or may not have a pigeon inside
them. Now to those who study math effectively they may realize 16
holes is 65,536 outcomes. But if we could do this somehow properly
counting, this is 810,000 (19.627~ bits) outcomes possible... provided
we leave at least 1 hole active per subgroup.

The problem is of course how do we keep track? In the above example I
added 3 bits (and change) to the size, but to count this I would need
to either know how many holes were closed, how many holes are present
per a section, or some other accounting of the whole. The lowest I can
devise costs 8 bits. There are two ways to accomplish the 8 bits that
I can find, and many ways that cost more.

2) Changing the 'make up' of the code
If you somehow could 'sort' the code via an algorithm and get a
certain percentage of 1>s on one side, and 0>s on another, you could
in theory compress. This was the main method of my earlier research,
and I though I had a magic bullet in it. I was wrong I fully admit it.
But it is an interesting line of thought.

You can effectively change the statistics of a section of code. It can
happen as my own research indicates. With hard-coded methods you can
get a deviation from norm as high as a 20%-22%-28%-30% (say this
example 11, 01, 10, 00) ratio of something 2 bits or higher instead of
a near typical 25%-25%-25%-25% (in approximation) ratio. However as
Huffman and Shannon correctly show, you need something a bit more to
be able to recursively compress. Not only that but code that is
subject to compression via standard methods can get compression from
those methods, but may result in a change that is not compressible via
our selected method. Therefore suddenly we need a small command
section, albeit a few bits. Then you need to add in what the changes
resulted in, which is more likely to compress (11 or 00?) and then you
again are past the amount which would lead to compression except in a
very low number of the outcomes (and on a scale mattering on the total
bits in the string being compressed) possible.

Now it seems certain lossless repeatable compression is not highly
probable, or even probably remotely possible to happen. However if it
were possible, then one of these two means (am I missing one or more
possible ways?) would seem to be the means to achieve this. However I
would note, even if it is achievable, there would be entropy
eventually, we cannot reach 1 bit from every possible formula in the
universe after all... which is the final argument of the counting
argument :P

So thoughts?

Jim Leonard · Guest

On Jul 4, 5:37 pm, Einstein <michae...@gmail.com> wrote:
[quote]This is just to stir debate and talk, not to say 'eureka I solved it'
and post nonsense :P
[/quote]
Not to sound too insulting, but there really is no debate. The
counting theorem is pretty basic and straightforward; following the
"pigeonhole principle"-style description, you simply can>t fit 16
pigeons in 15 holes. You can slice and dice bitwise representations
of data all you like, but in the end, you will always find that the
amount of "housekeeping" data will equal or exceed the size of your
source.

There are two types of quackery floating around the perpetual
compression community: Those who believe you can represent all data
using less bits if only you could find:

1. The right scheme for doing so
or
2. The "pattern" of the data that would allow you to build a formula/
generator/emitter to represent it

Take the following bit sequence as an example:

000001010011100101110111

People who fall into quackery type #1 see the repeated zeros and ones
and think that there should be SOME way to represent data using less
bits. They waste days, months, years of effort trying to come up with
a way to do so, but ultimately fail. Or maybe they think that large
streams of data could go into some central database somewhere, and
only the index is needed to retrieve the data? That isn>t compression
-- you still need the original data somewhere. So you>ve saved
nothing, and in fact expanded the data (by the index you need to
maintain).

People who fall into quackery type #2 might recognize a pattern in the
bitstream:

000
001
010
011
100
101
110
111

It is a series of gradually increasing binary integers. So they see
this, or some other example, and conclude that it must be possible to
analyze any set of data and break it down into one or more algorithms/
formulas/procedures/generators/emitters (I am using every bit of woo-
woo terminology here so that other quacks can see themselves in this
example) that would be smaller than the data they represent.

#1 is analogous to order-0/statistical compression methods (Huffman,
etc.) but cannot reduce *all* data.
#2 is analogous to content mixing, PPM, PAQ, etc. but those also
cannot reduce *all* data.

Why not *all* data? Counting theorem. Please read up:
http://en.wikipedia.org/wiki/Pigeonhole_principle

biject · Guest

On Jul 5, 2:48 am, Jim Leonard <MobyGa...@gmail.com> wrote:
[quote]On Jul 4, 5:37 pm, Einstein <michae...@gmail.com> wrote:

[/quote]
.....

[quote]2. The "pattern" of the data that would allow you to build a formula/
generator/emitter to represent it

Take the following bit sequence as an example:

000001010011100101110111
[/quote]

I think your misong somthing. Like take the string of bits above
one can compress it. Actually you can take any similar string and
you could compress it smaller too.

But what they fail to see that its a trade off. If you have a
method
that makes above string smaller then the unfortunate side affect is
that it also makes some other string longer. Compreeeion is at
best a trade off you substitue smaller strings for longer strings.
You just hope the method you pick works for useful strings. Cause
in the spave of all strings doing noting is about the best you can do.
and there will be many useful compressors. Because the defination
of useful is a moveing target. What useful in one application is not
even a valid file in another.
David A. Scott
--
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"

[quote]
People who fall into quackery type #1 see the repeated zeros and ones
and think that there should be SOME way to represent data using less
bits. They waste days, months, years of effort trying to come up with
a way to do so, but ultimately fail. Or maybe they think that large
streams of data could go into some central database somewhere, and
only the index is needed to retrieve the data? That isn>t compression
-- you still need the original data somewhere. So you>ve saved
nothing, and in fact expanded the data (by the index you need to
maintain).

People who fall into quackery type #2 might recognize a pattern in the
bitstream:

000
001
010
011
100
101
110
111

It is a series of gradually increasing binary integers. So they see
this, or some other example, and conclude that it must be possible to
analyze any set of data and break it down into one or more algorithms/
formulas/procedures/generators/emitters (I am using every bit of woo-
woo terminology here so that other quacks can see themselves in this
example) that would be smaller than the data they represent.

#1 is analogous to order-0/statistical compression methods (Huffman,
etc.) but cannot reduce *all* data.
#2 is analogous to content mixing, PPM, PAQ, etc. but those also
cannot reduce *all* data.

Why not *all* data? Counting theorem. Please read up:http://en.wikipedia.org/wiki/Pigeonhole_principle[/quote]

Guest

On Jul 5, 8:48 am, Jim Leonard <MobyGa...@gmail.com> wrote:
[quote]On Jul 4, 5:37 pm, Einstein <michae...@gmail.com> wrote:

This is just to stir debate and talk, not to say 'eureka I solved it'
and post nonsense :P

Not to sound too insulting, but there really is no debate. The
counting theorem is pretty basic and straightforward; following the
"pigeonhole principle"-style description, you simply can>t fit 16
pigeons in 15 holes. You can slice and dice bitwise representations
of data all you like, but in the end, you will always find that the
amount of "housekeeping" data will equal or exceed the size of your
source.

#1 is analogous to order-0/statistical compression methods (Huffman,
etc.) but cannot reduce *all* data.
#2 is analogous to content mixing, PPM, PAQ, etc. but those also
cannot reduce *all* data.

Why not *all* data? Counting theorem. Please read up:http://en.wikipedia.org/wiki/Pigeonhole_principle
[/quote]
I notice that when anyone tries to diss "The Counting Theorem" the
word ***ALL*** somehow drops out of their vocabarly. Einstein himself
is a prime example when he claimed that could lossless compress and
decompress any 16 bit combination. When pressed to test it his idea
he came back with the claim that spreadsheets like Excel could not
handle 65536 test cases at the same time.

Later he admitted to his error, but again he seems to be falling in
the same trap again.

"The Counting Theorem" was never, is never, will be never about the
compression of a particular string of bits, it is about the
compression of all possible combination of a string length. And it
always wins in the end because it is right.

Guest

On Jul 4, 11:37 pm, Einstein <michae...@gmail.com> wrote:
[quote]Cut
[/quote]
Hi Michael,

Your perseverance has to be admired!

[quote]You take a long section of code. You subdivide it into subsections. Each section can be compressed or not compressed separately.
The thing here already is that if the long section of code is random[/quote]
data, then chances are the subsections are made up of nothing more
than random data also. A quick check is to add up all the 1>s and add
up all the 0>s, if they>re about the same, then you>re going to find
it a struggle to compress. Changing to use 8 bits or something won>t
help either as the very basic number (i.e. single bit binary) says
that the balance is equal - unless you know something about the
underlying data (i.e. a bmp compresses to a jpg because of the pixel
properties).

[quote]But it is an interesting line of thought.
Yes, it is quite an interesting idea, although if the data is random[/quote]
(which if it wasn>t, you could compress normally), then it>s
impossible to sort the data with any sort of gain.

[quote]With hard-coded methods you can get a deviation from norm as high as a 20%-22%-28%-30% (say this example 11, 01, 10, 00) ratio of something 2 bits or higher instead of a near typical 25%-25%-25%-25% (in approximation) ratio.
Would you mind explaining how? I>m curious to how you manage this AND[/quote]
keep the cost down to the point where you may actually gain from it.

[quote]So thoughts?
You seem very intent on developing new algorithms! :) Personally I[/quote]
think you>re going about it the wrong way. I don>t believe shifting/
sorting the data in such a way that will let you compress it will
actually help as in the majority of cases the cost of the operations
will outweigh the gain. If I were you I would work on algorithms that
can discover patterns within a data set, clearly the closer the
pattern description matches the underlying data the better the
compression. Essentially what you>d be looking to do is to create some
algorithms that could look at a data set and find the patterns and
compress accordingly. For example, if the data set was a raw image,
then it should be able to eventually work out that certain bytes share
values that are very close together (i.e. one pixel next to another
pixel) and get around the same compression as a jpeg (on lossless
settings). Another example is an exe - on the surface it appears
random data, although it isn>t, there are patterns in there (perhaps
difficult to find, but they exist), after all it is made up of a
limited number of opcodes working on data. Where you will find
problems here is creating an algorithm that is capable of analysing
the data at a rate that is usable - no point having a compressor that
needs a few hours to save a few bytes! Obviously you>ll never be able
to compress random data, as the whole point in random data is that it
doesn>t have any underlying pattern, but in the real world, you>ll
never need to compress random data. All useful data has some sort of
structure however remote it is. Even once you>ve compressed the data
using the pattern method - the compressed data will still have an
underlying pattern in it (i.e. the output the from the previous
pattern).

Just noticed, Jim Leonard has sort of touched upon this in his second
point. Although as he said you>ll never compress all data, which is of
course very true.

Hope this gave you a few things to think about.
Andreas.

Providence · Guest

well.. you could utilize the fact that truly random data just doesn>t
exist.

if you encoded the laws of physics, the designs of computer systems,
and human genomes you could definitely put a lower and upper bounds on
any data produced by a computer, and compress that way.

in a more diffuse way, what i aimed at was looking at the fact that
information quantizes at all.

take the string 100000000

in binary, it represents a high and eight lows.

in base ten, it>s a hundred million.

in base twenty trillion and three, it quantizes the exact same, but
each of the digits has much more information inside it.

so, take a non-quantized unary ideal, ("one" in base 499534 for
example), cycle through all the different quantized representations
(499533 different examples) and you>ll see that base 2 is actually the
worst case scenario.

you may find, for instance that in base 3240 the result of that unary
ideal is 57577757757775775. take out the 'entropy' which is actually
super, super easy to perceive in this method. it>d be
02022202202220220 with another information structure containing '5'.
each digit is now base 3 instead of base 3240, which is pretty vast.

extending this concept, *if* we could create custom molecules of the
exact quantization dimensions that relates to the found best scope, we
could avoid entropy entirely taking advantage of the lowest possible
information encoding energy state in the quantum domain. basically,
massaging the system so that entropy has no basis as a concept, as
there>s just nothing left to optimize in the quantization of
information.

otherwise, you can simply count the probability of each possible scope
range occuring, and add them together as these are all the
probabilities for any given unary ideal.
seriously.. do it. you>ll find that because binary is the worst-case
scenario, the likelyhood that the final representation will end up as
binary is less likely than any other result. then, it>s just the
overflow proportion (say like 3^3 = 9 compared to 2^4 = 16) from the
compacted range + unary ideal + etc. that relates to whether or not
the full string is actually better to write as binary or as the
compacted range + unary ideal + etc.

as this problem is pretty much totally NP-Complete (save the highest
value digit comparisons, so you can have early outs from the scoping
algorithm), which means that in effect you have to examine each and
every scenario as the digital representation is so varied between even
individual scoped representation, the amount of sheer computing power,
even with GPU acceleration through CUDA and such, is inadequate. i
suspect that in about 10-20 years there will be enough compute
resources to apply this methodology.

chris.

jules Gilbert · Guest

On Jul 6, 2:44 pm, Marco Al <m.f...@student.utwente.nl> wrote:
[quote]Einstein wrote:
There has been many efforts to bypass the counting argument. These all
require systems which add bits to something one could call 'a command
section' or 'identifying bits'.

No, they all require a fundamental lack of cohesive thinking. Unless you
believe basic math is internally inconsistent the only way to disbelieve
the counting argument is to be stupid or naive. Seeing as that you have
been here a while we can forget you are naive ... so either you are
stupid or you don>t really disbelieve the counting argument.

My guess is the second.

So thoughts?

Welcome to my kill file.

Marco
[/quote]
First, the counting argument is valid -- as far as it goes.

I am trying to finish a system that clearly compress>s, and when you
know how, the CA isn>t the slightest problem. Because the data
doesn>t go into the output file; If it did, well that would pretty
clearly stop all RAD compression research, wouldn>t it.

And a lot of people, people who are tourists really, who haven>t
thought about these issues just make this assumption -- it doesn>t
help.

I do have a system I like very much, I>ve been running a simulator,
(maybe exerciser is a better word choice,) because it actually builds
and process>s RAD data, trying the cartesian space defined for a 4-
tuple.

This morning I found one set of parameters that accept 9-bit data
input vector, produce a 4-bit output vector plus an additional vector
wherein most cells of the 2nd-vector cell values are no more than 3-
bits. A few are 5-bits.

(In the above description, the two output vectors are reassembled, but
this isn>t the data -- the data itself isn>t transferred, people who
keep complaining don>t have any idea what we>re doing. (Or at least
what I>m doing.)

In most disciplines a body of code exists to facilitate
experimentation. It would be very nice if our community had a set of
tools to enable a researcher to experiment with different emitter
methods, where an 'emitter' is a C-program (probably,) for converting
an input vector according to some particular set of rules.

I will have more to say about this subsequently.

Guest

On Jul 6, 8:35 pm, jules Gilbert <jules.sto...@gmail.com> wrote:

[quote]Cut
When will your compressor (and of course the fully working[/quote]
decompressor) be ready then?

[quote]people who keep complaining don>t have any idea what we>re doing. (Or at least what I>m doing.)
More to the point, do you know what you>re doing?[/quote]

[quote]emitter methods, where an 'emitter' is a C-program (probably,) for converting an input vector according to some particular set of rules.
I think you>ll find the correct terminology for an "emitter" is[/quote]
actually a compressor.

Andreas.

jules Gilbert · Guest

On Jul 6, 4:02 pm, MailTo.Andreas.Han...@googlemail.com wrote:
[quote]On Jul 6, 8:35 pm, jules Gilbert <jules.sto...@gmail.com> wrote:

Cut

When will your compressor (and of course the fully working
decompressor) be ready then?

people who keep complaining don>t have any idea what we>re doing. (Or at least what I>m doing.)

More to the point, do you know what you>re doing?

emitter methods, where an 'emitter' is a C-program (probably,) for converting an input vector according to some particular set of rules.

I think you>ll find the correct terminology for an "emitter" is
actually a compressor.

Andreas.
[/quote]
No, I am now emitting a vector produced by a process that I have been
experimenting with, using a broad state space (I think I>ve mentioned
this.) And the results for *some* settings is quite good, and I am
processing very large amounts of input with each setting.

I am confident that I am actually compressing, ie., the output vector
is smaller. By 'smaller' I mean that I look at the left-most bit in
the cell buffer and it>s further to the right than the input cells.

I have a friend who knows what I am doing, and he has a major
reservation (I found this out just recently,) he complains that the
input buffers I am supplying to the process are produced from a random-
number generator and is concerned that my method has 'found' some
aspect of such input to 'key' on, and that with true RAD (say, from
nature or from a file,) I would not realize any compression.

When I first setup the program I wrote it so I could supply an actual
file and I tested this method with MN>s 1M file, but I needed more
data than this provided and really, the method requires many GB>s to
test throughly -- I have several terabytes online but even I don>t
have sufficient RAD-data ready to go.

No, I need to use PRNG input but what gets produced had better work
with conventional RAD as well as with MN>s file, too.

The simulator has identified a few local minima, so I expect to put a
round-trip system together this week that accepts/process>s actual RAD
files.

The program won>t be optimal by any means, I will have to use
(something like this probably,) 15-bit input, 5-bit output, all within
a 16-bit field -- because as I said, the output contains spikes,
though for the RAD data I have tested with (remember, it>s from a
PRNG,) almost all the output spikes are at most 9-bits (most of the
data output is actually 5-bits.)

In 1MB of RAD input I had one 15-bit spike, so I am allowing a 16-bit
range and hope that this solves my problem. (I do test such
exceptions.)

I have a lot of other problems to solve too, but the core process is
working -- I>ve known how to do this for several months. (Now what do
I do with it? Commercially.)

The problem now is how do I (how does anyone!,) extract value without
getting new technology ripped off by companies such as MS, who,
according to a US court, used Stack Electronics patented technology
without bothering to license it. Of course now the situation is much
worse because just the US (for example,) has (probably,) more than 10k
enterprenuers who would be happy to use my program materials but not
so happy to pay the licensing fee.

For the past ten years or so I have accepted that no matter what I
came up with, most likely only a small fraction of the program>s true
value would be realized by myself and my friends.

However the next step is to put together a compressor/decompressor.
With respect to the above, I don>t expect to do 3:1 or even 2:1. I
think 20% or 25% is realistic -- at least until I have brought in
others I can trust to do certain 'things' right.

And this isn>t going to deliver a 300 byte output file either. I
can>t discuss what this program doesn>t do, but it does require at
least a file of 5k or 10k or so to work at all -- yes, a later version
might manage this but not now.

--jg

jules Gilbert · Guest

On Jul 6, 7:28 pm, jules Gilbert <jules.sto...@gmail.com> wrote:
[quote]On Jul 6, 4:02 pm, MailTo.Andreas.Han...@googlemail.com wrote:

On Jul 6, 8:35 pm, jules Gilbert <jules.sto...@gmail.com> wrote:

Cut

When will your compressor (and of course the fully working
decompressor) be ready then?

people who keep complaining don>t have any idea what we>re doing. (Or at least what I>m doing.)

More to the point, do you know what you>re doing?

emitter methods, where an 'emitter' is a C-program (probably,) for converting an input vector according to some particular set of rules.

I think you>ll find the correct terminology for an "emitter" is
actually a compressor.

Andreas.

No, I am now emitting a vector produced by a process that I have been
experimenting with, using a broad state space (I think I>ve mentioned
this.) And the results for *some* settings is quite good, and I am
processing very large amounts of input with each setting.

I am confident that I am actually compressing, ie., the output vector
is smaller. By 'smaller' I mean that I look at the left-most bit in
the cell buffer and it>s further to the right than the input cells.

I have a friend who knows what I am doing, and he has a major
reservation (I found this out just recently,) he complains that the
input buffers I am supplying to the process are produced from a random-
number generator and is concerned that my method has 'found' some
aspect of such input to 'key' on, and that with true RAD (say, from
nature or from a file,) I would not realize any compression.

When I first setup the program I wrote it so I could supply an actual
file and I tested this method with MN>s 1M file, but I needed more
data than this provided and really, the method requires many GB>s to
test throughly -- I have several terabytes online but even I don>t
have sufficient RAD-data ready to go.

No, I need to use PRNG input but what gets produced had better work
with conventional RAD as well as with MN>s file, too.

The simulator has identified a few local minima, so I expect to put a
round-trip system together this week that accepts/process>s actual RAD
files.

The program won>t be optimal by any means, I will have to use
(something like this probably,) 15-bit input, 5-bit output, all within
a 16-bit field -- because as I said, the output contains spikes,
though for the RAD data I have tested with (remember, it>s from a
PRNG,) almost all the output spikes are at most 9-bits (most of the
data output is actually 5-bits.)

In 1MB of RAD input I had one 15-bit spike, so I am allowing a 16-bit
range and hope that this solves my problem. (I do test such
exceptions.)

I have a lot of other problems to solve too, but the core process is
working -- I>ve known how to do this for several months. (Now what do
I do with it? Commercially.)

The problem now is how do I (how does anyone!,) extract value without
getting new technology ripped off by companies such as MS, who,
according to a US court, used Stack Electronics patented technology
without bothering to license it. Of course now the situation is much
worse because just the US (for example,) has (probably,) more than 10k
enterprenuers who would be happy to use my program materials but not
so happy to pay the licensing fee.

For the past ten years or so I have accepted that no matter what I
came up with, most likely only a small fraction of the program>s true
value would be realized by myself and my friends.

However the next step is to put together a compressor/decompressor.
With respect to the above, I don>t expect to do 3:1 or even 2:1. I
think 20% or 25% is realistic -- at least until I have brought in
others I can trust to do certain 'things' right.

And this isn>t going to deliver a 300 byte output file either. I
can>t discuss what this program doesn>t do, but it does require at
least a file of 5k or 10k or so to work at all -- yes, a later version
might manage this but not now.

--jg
[/quote]
Oh!, I left out a key thought I wanted to include -- here it is.

All ye who believe the counting argument. Your boat is about to be
overturned.

Not that I have some counter-example. I don>t. As I keep telling you
folks and get ignored, you are right when you say that say, 8-bits can
only contain 256 states.

But I have found a way to take a byte and, while storing only 256
states, cause those 256 states to represent much more information.
Well beyond the capacity of a single 8-bit byte.

So that>s it. And I know that few, if anyone, believes me. That>s
okay. I ran the program again this afternoon and the system works.

Marco Al · Guest

Einstein wrote:

[quote]There has been many efforts to bypass the counting argument. These all
require systems which add bits to something one could call 'a command
section' or 'identifying bits'.
[/quote]
No, they all require a fundamental lack of cohesive thinking. Unless you
believe basic math is internally inconsistent the only way to disbelieve
the counting argument is to be stupid or naive. Seeing as that you have
been here a while we can forget you are naive ... so either you are
stupid or you don>t really disbelieve the counting argument.

My guess is the second.

[quote]So thoughts?
[/quote]
Welcome to my kill file.

Marco

biject · Guest

On Jul 6, 5:36 pm, jules Gilbert <jules.sto...@gmail.com> wrote:
[quote]On Jul 6, 7:28 pm, jules Gilbert <jules.sto...@gmail.com> wrote:
....[/quote]

[quote]
But I have found a way to take a byte and, while storing only 256
states, cause those 256 states to represent much more information.
Well beyond the capacity of a single 8-bit byte.

[/quote]
....

Actually I showed how even a single byte could represent many
thousands of possible encrypted compressed messages. Even
if that one byte is all zeros.

For a simple proof take tried and ture BICOM with a one byte
file as input to the decompressor. Pick you favorite keys at least
300 of them. Notice they will most likely each decompress that single
byte to a unique message. Once you get nore than 250 uniuqe
messages you do not need to test any more the point is proved.
go ahead notice that it works both ways. Once you decrypt decompress
with a key notice that same key compresses and encrypts back to
that single byte of all zeroes. Many mistakenly beiived this violates
the counting theorm and are to lazy to test this simple example.

David A. Scott
--
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"

jules Gilbert · Guest

On Jul 6, 7:54 pm, "Pete Fraser" <pfra...@covad.net> wrote:
[quote]"jules Gilbert" <jules.sto...@gmail.com> wrote in message

news:7a45830c-82a1-42da-8512-af84896350ce@d77g2000hsb.googlegroups.com...

When I first setup the program I wrote it so I could supply an actual
file and I tested this method with MN>s 1M file, but I needed more
data than this provided and really, the method requires many GB>s to
test throughly

You>re being too tough on yourself Jules.

We understand that you need vast amounts of random data to
_truly_ test your compressor.

We>re an easy-going bunch here though - we>d be seriously
impressed by a demo of your software compressing (and
restoring) MN>s file.

And you think we>re tough on you. We>re pussycats, really.

Pete
[/quote]
Pete:

Right now -- not pending some future work, but now -- I have something
that, I think, does meet all the criteria we have discussed (even over
and over again,) for years. And I very much desire to put these
issues (regarding repeated compression of previoiusly compressed
files,) to rest.

I *now* produce a vector that is readily reversible and the simplest
analysis suggests (notice that word,) the contents can be represented
using fewer bits. In fact I have been asking people for help writing
an emitter for some time and not getting a positive response.

My problem isn>t the doing any more, now I have to make something that
I can safely show (albeit under very carefully controlled
circumstances,) and also I don>t want to lose the technology. I am
not confident that I will one day sell it for a billion dollars but
losing it (someone else learning how it works,) guarantee>s that I
won>t make money.

I expect to have at least a rough version of a stand-alone compressor/
decompressor finished this week, something that can do what my friends
and I call "round-trip".

By the way, I don>t think that I made a mistake to use PRNG as input;
But I do have a colleague who is very cautious and doesn>t think that
it>s possible to do (period!,) but I do, -- and he warned me recently
that I may be deceiving myself, that perhaps my method has "locked" on
to some underlying system of patterns present in the particular PRNG
that I am using.

I surely hope not -- but in view of his remark, today I tried another
RNG and obtained effectively identical results. (That actually
doesn>t meet his objections but does make such a possibility less
likely.)

I have an FTP site, Peter. If you will contact me privately I will
give you the login/pswd and some data -- you tell me if it>s
compressible below 1MB. (But give me this week to try myself.)

All my testing used 1MB of data. Most of the 'machines' failed to
produce output data that contained qualities that I deemed appropriate
to be a candidate for re-compression.

I really do need this week to see what I can put together.

As for being pussycat>s -- well, to resolve this we>d have to discuss
individuals, probably not a good idea.

If I come up with something wonderful I probably will go down to see
Mark.

Pete Fraser · Guest

"jules Gilbert" <jules.stocks@gmail.com> wrote in message
news:7a45830c-82a1-42da-8512-af84896350ce@d77g2000hsb.googlegroups.com...

[quote]When I first setup the program I wrote it so I could supply an actual
file and I tested this method with MN>s 1M file, but I needed more
data than this provided and really, the method requires many GB>s to
test throughly
[/quote]
You>re being too tough on yourself Jules.

We understand that you need vast amounts of random data to
_truly_ test your compressor.

We>re an easy-going bunch here though - we>d be seriously
impressed by a demo of your software compressing (and
restoring) MN>s file.

And you think we>re tough on you. We>re pussycats, really.

Pete

Mark Nelson · Guest

On Jul 6, 1:44 pm, Marco Al <m.f...@student.utwente.nl> wrote:
[quote]Einstein wrote:
Unless you
believe basic math is internally inconsistent
[/quote]
I certainly believe that basic math is internally inconsistent.

I would suggest that you should too.

No doubt there is some NG *.math.* where people are continually
posting proofs of Hilbert>s second problem, much like our infinite
compression remoras. But despite that, it is pretty well accepted that
this has been proven impossible, at least for the arithmetic most of
us are familiar with. (Not an expert in this area, but I guess you
could compose a weaker arithmetic that was consistent and complete.
I>m sure someone has proven this.)

"Alice laughed: "There>s no use trying," she said; "one can>t believe
impossible things."

"I daresay you haven>t had much practice," said the Queen. "When I was
younger, I always did it for half an hour a day. Why, sometimes I>ve
believed as many as six impossible things before breakfast."

Alice in Wonderland.

- Mark Nelson - http://marknelson.us


www.GetXFactor.com Leading Technology, Science, Agriculture News and information	Part of the Identityscape.com network... getxfactor.com jmoodmusic.com smartbusinesschoices.com mintdepot.com lowfaresalways.com evangelicalview.com shoppingpodder.com soproudlywehail.com webnews.ws currenthumor.com

Science and Technology news... Forum Index -> Compression Forum	Goto page 1, 2 Next
Page 1 of 2