compression - insights into infinite

so there are very real limits on the amount of information that can be
compressed. these don't seem to have to do with any dimensionless
numbers like an electron mass/etc. so are going to be the same no
matter what the physics of any given universe is like.

which leads to the pondering if nothing can be compressed
infinitely, where did all the relational information come from
originally?

like, as humans, our conciousness, though using physics and electrons
and atoms and cells, is actually using a vast relational composition
to define and understand our environments.

it would follow that each of these relationships is already
'preprogrammed' and present in the very first single instant of
reality.

the result of looking at the relationships on the information level
moves beyond any questions we still may have over the 'mechanicals' of
our universe ie. whether time-forwards and time-backwards symmetry
is equivalent for quarks.


so each of our relationships that we can fathom-create, must be
originally present in the geometries of the fundamental structures of
(any/this) universe.


what do you guys think? are we limited to the original geometries or
is our conciousness then definitely outside of the universe to be able
to be 'creative' in our manifestations of extremely precisely tuned
groupings of information (ie. a picture of an egyptian god holding a
rose in one hand and an anhk in another).

and more, if we were to put on a single sheet (no matter how large or
in what language) paper all the laws of reality wouldn't the previous
boundaries *have* to expand as there is then an observer, in time,
gazing at the 2d form of all information?


**
precisely, the fact that we can hold a concept of 'nothing', should
mean that any information should always be able to resonate/move since
we could, potentially, add a '1' as 'yes truth' or '0' as 'not
entirely', as the observer, creating that relationship towards that
original source of information.



thoughts/comments?



chris.

Chris you are one the right track, everything already exist,
everything we see we created ourself. Because everything in this and
all other endless universes is build from many live forms and
continous changing, I see it more as continous reorganizing everything
what already exist. The planets and live forms we go to create in the
far far future is already existing as seeds in us today.

thanks for the comments.
i'm trying to work with the concepts to see whether logically it is
possible to put more information into the 'already exists', than may
have been there if there wasn't a conciousness directing the
relationships together.

with your concepts, it would be like the over-concious has this
relationship between mass of electrons, mass of neutrinos in it's
'mind'. this is static throughout time, and results in the interplay
and interactions, always in a quantized fashion, creating forces,
matter, etc.

my thought is that we as concious entities have similar abilities,
that while necessarily resulting in a deux ex machina type event where
if you were to modify/add to the 'already exists' information pool,
that the resultant would need to create the conciousness that
initiates it, but depending on the sensory elements that are
translating all these ratios and silhouettes, it could be possible to
'key' into the specific information detail level that corresponds to
this, in your terms, 7 cycle.

basically, if we could dampen the other elements that we're constantly
assembling, and inject say a simple geometric form as a pattern while
we're looking at something 'random' like parchment paper, that would
necessarily be of the proper information density to align to our
current perceptual 7-cycle, which would make it so that as long as the
alignment is maintained, we could inject seeds of other forms, low
density information from our perspective like emotions, into that same
plane and see the results after a billion years of evolution into
something that has as much detail as we can observe visually,
extrapolated and added to the basic information.

this may be a bit of a heavy thought, but i've personally witnessed
the practical applications of the technique within an objective, ie.
other material persons witnessing the same results, paradigm.

i'm just trying to figure out the proper conceptual diagram to bring
some light onto a really crucial element of being, that we're capable
of utilizing from these 'bodies' at this time.

I am not sure you'll understand this, but here goes. *I do not claim
that I can compress everything down to one bit, but I have a method,
wherein, without making use of any external parameters or hidden
dataset, I certainly can compress, and assuming the original input
file is large enough, many, many times, even thousands! of times.
>
How small? *Given the current machine architectures all of use, wrt
the current hardware and software, I suppose that my method might be
used to drop a file down to one byte.


one byte. four bits.

that's sixteen possible combinations, you couldn't even get a single
english letter to fit in that space, without other context surrounding
it.

the other context is the algorithm that is determining what to do with
the sixteen possible combinations, but it can't go any further than
the first step without another context layer

case1:
something depending on context


case16:
something depending on context

but the context is just that single step as you can see. if you needed
more detail than any of the sixteen original combinations, which are
*fixed* by nature, you need more context thus the algorithm grows in
size.

the total size of any binary file is the bits + whatever bits the
algorithm needs to function.

good example:

you could only describe one of say, sixteen mp3 samples of a person
saying 'a', 'b', 'c', each mp3 is a 400mb, super high detailed file.

you'd transmit a byte, and on the receiving end play the mp3, which is
part of the algorithm.

all 16 mp3s are part of the algorithm. that's 6400mb in size.


it would only go up to 'p' and no further, ever.


there's absolutely no way you could get the voice to say 'q', from
that single byte of information.


pushing the file limit minimum upwards doesn't avoid this problem, it
is inherent to quantized information.

jules Gilbert wrote:
>
I am not sure you'll understand this, but here goes. I do not claim
that I can compress everything down to one bit, but I have a method,
wherein, without making use of any external parameters or hidden
dataset, I certainly can compress, and assuming the original input
file is large enough, many, many times, even thousands! of times.

, so here is my repetitive compression algorithm. Unlike yours, this
isn't snake oil, you can test and run it:

Use a LZ-algorithm, and a text file as input. the first compression,
compress the first K of data, and append the rest of the file unaltered.
Write a header to the target data that indicates that you have
compressed the first K. the second run, detect the header, leave the
first block of data (which is LZ compressed already) unaltered, and
compress the second block of data, altering the header accordingly, and
append the rest of the text unaltered.

This gives you, for typical text input, a repetitive compressor, and you
can compress as many times as there are blocks in the original file.

Is that useful? Probably not.

How small? Given the current machine architectures all of use, wrt
the current hardware and software, I suppose that my method might be
used to drop a file down to one byte.

LL! Jules, your engagement in probability theory and measuring spaces
all aside, but before you understand *that* stuff, please try to use
your fingers and your brain to *count* correctly.

While all people seem able to understand that you need one digit to
select one out of ten objects, for some reason beside me some people
believe this simple and elementary logic breaks down for inapplicable
reasons for "imaginary" numbers, such that those beyond ten. Be ensured
by a trained mathematician that the mathematics for those numbers, say
ten million, is exactly the same!

That said, one byte is able to select exactly one out of 256 different
input objects, in the same way that one digit is able to select one out
of ten objects, so you can "compress" exactly 256 different inputs.

Well, that's not exactly interesting, is it?

And yes, I am referring to lossless compression and decompression.
byte. And I've been a programmer since 1965, my first machine was
an IBM 1620-II running Fortran 2-D. (I learned and coded in SPS-II,
it's assembly language.)

That's astonishing, given that you're "logically challenged".

So yes, each time, producing a smaller and smaller file. Do you
understand! Why are you so dense? What in the world is wrong with
you??

Ehem. Jules, what in the world is wrong with you? You only need to apply
elementary logic to see that you're claiming utter nonsense, or at
least an utterly useless algorithm.

I may someday show what I have, not publicly (a few of my friends
already know the method I am referring to.) But if I were to give a
public demonstration I might not be able to keep people such as
yourself from watching my program demonstration. Can I make this any
clearer?

No, and as we all know, there will never be such a demonstration. It is
as much unlikely as a demonstration that the circumference of a circle
fits four times into its diameter.

Two problems remain;
>
1) Connecting these buffers to a suitable compressor.
>
2) Selling the program in a world where our courts do not well
protect the small inventor.

For that, you need something useful to sell, but we both know that you
don't have that, and at least I know that you never will with that
approach. Thank you, Jules.

You promised several times to leave this group. Why don't you?
Please get away, and stay away - it's a permanent annoyance. People that
are resistant to elementary logic shouldn't work in a field that is
mostly mathematical.

So long,
Thomas

jules Gilbert schrieb:

Peter, if I thought you'd actually answer technical questions
intelligently, I'd ask -- and right now I have some questions!! So
where are the folks with the doctorates in math?

Their are all here, and they keep telling you that elementary logic is
enough to tell your two new schemes don't work if they compress
everything down to a byte. Well, the decompression at least won't work.
*Compressing* to zero bytes is actually the easy part. (-:

Because I was up
until 6AM or so Saturday morning trying to resolve a couple of topics
within my biz plan.

Before you setup a biz plan (unless it's the biz plan of a con-man) you
should get your decompressor working; and before that, you might want to
get your math straight. Just answer the following simple question:

How many different files of two bytes length are there?

That's your homework. Don't be shy if you cannot solve it, the math
cracks are all here.

So long,
Thomas

jules Gilbert schrieb:

>
I understand your logic Thomas, and would agree with your conclusion,
but for one small fact
>
[Insert long and spirited defense here Sigh. Just like you folks,
I am getting pretty tired of this.]
>
Briefly, one sentence, I can reduce randomness, even in a very small
amount of data, as I said, a buffer, measured before and after, shows
up as less random after the process -- and no additional information
must be conveyed to the receiver.

Look, this argument is *not* about randomness. If you state that you can
compress *all* data, then this "all" implies random, non-random,
pseudo-random, and data. It doesn't
matter. As soon as there are more possible input sequences as they are
output sequences, your technology isn't reversible, plain and simple.

The 'measurement' is, as I have said, the "stats" routine in the C/
Math library, basic?, yes. Useful?, incredibly. Wrong?, not very
likely. I'd suggest that maybe I'm measuring something erroneously or
perhaps coming to the wrong conclusion from well constructed
measurements, but since I think I've done everything correctly my next
step is to work with someone who can help me to build a nice
compressor/decompressor package.

For that, it needs an algorithm. The feature of an algorithm is that it
generates for one possible input one predictable, reproducible output.
Unfortunately, you must generate (to decompress again) different outputs
for the same input. That's not an algorithm.

What might work is to publish some of this data, say in an FTP site
and let people examine it.

Well, all fine with me. Again, I throw in the following input for you to
compress:

All 256 one-byte sequences. All 65536 two-byte sequences.

Those include random, pseudo-random, not-at-all-random and whattheheck
other sequences of 16 bits. Posting the output of those would be
enlightening, probably more for you than for us, but nevertheless, do
that, and put the said output on a web-space, or an ftp server, or mail,
and measure their length. I *D NT CARE* about your top-secret
compressor or decompressor.

My early work with this method is best described this way:
>
a) An INPUT cell, let's stay with bytes for this example.
>
b) UTPUT cell, residue, part A. The problem with this was that some
cells, say 5% (wrt a 1-byte organization,) were in excess of 8-bits.
Not very convenient for a compressor, of course. The other cells
were, typically, reduced by at least 1-bit.
>
Now, having done additional work, I have much smaller residue's and no
bytes in excess of 8-bits. In fact all output cells contain,
typically, less than four bits. Frequent output values are 4 and 5,
for example. Plus a sign bit, but the sign bits compress quite
handily. (They are best converted into sequences of primes.)

Jules, you still don't understand. All this doesn't matter at all,
unless you're willing to admit that said algorithm won't compress all
input. In fact, like all other compression algorithms, it will fail most
of the time. However, the failure cases for most other algorithms are
interesting (because they include text, graphics or other sources humans
care about), so what are the interesting cases of your algorithm?

Another value, needed to reconstruct the original value, isn't sent.
It's inferred on the receiver side. Remember my two-bit compressor
that worked by inferring the sign bit? This reconstruction *may* be
imperfect, but I have a simple inductive proof that, worst case, the
information that must be sent is always less than 8-bits. (I don't
mean that the compressor may be lossy, I am concerned to produce a
space reduction all the time -- that's what I mean here.)

If the overall amount is less than 8 bit while the input is 8 bit, your
proof is flawed. As simple as it is.

Again, and this is a very very simple exercise, feed all 256 possible
byte inputs into your compressor, in initial state, and post or collect
the outputs.

Two things can happen:

a) Either, in that said output, sequences longer than 8 bit appear, in
which case the algorithm might work, but your proof is flawed.

or

b) all sequences that are generated this way are less than 8 bit long,
in which case there are fewer than 256 of them, in which case at least
two input sequences must map to the same output, in which case you don't
have a decompressor.

My proof depends on something I can do in a CAS but don't have the
math to work out by hand (ie., to understand.) Still, I can build a
symbolic system that I'm sure wouldn't work if the mathematics I am
depending on were deficient.

Math depends on the elementary laws of logic, so does the internal
wirings of a computer. For that simple reason, you never will have the
"math" to represent 256 inputs by less than 8 bit.

The savings (the information that need not be sent,) varies with the
organization, but I think I can demonstrate at least a single bit per
byte savings.

Then, I beg you, demonstrate. You'll see that either a) or b) is the
outcome. You may post here. on an ftp side, I don't care, but *do*.

Words are cheap.

But before I commit to doing this, can I see a show of hands of people
who would look at the data, please.

So then, post, or mail. My email is valid. I do not want to see your
algorithm, I don't care. All I need to see is the output of all one-byte
sequences, and, if you like to, the output of all two-byte sequences. A
text file, one line containing the bits of the output is enough, use the
symbols 0 and 1. No binary encoding required, text files preferred.

That is, the files you post, should contain exactly 256 rows, or exactly
65536 rows. Each row defines the output of the corresponding byte input,
given by its line number, starting with line #0 (i.e. the input pattern
of line zero is 00000000 for the byte-file).

But please go over it first - if I find a duplicate output line, you
cannot decompress anymore. And, as said, the output may be either a) or b).

So long,
Thomas

jules Gilbert wrote:
Hi Jules,

Dear Thomas:
>
Pretty much I agreed with the elements underlying of your points and I
would be admonished except for one small minor insignificant detail,
probably of too little importance to note, but I will anyway.
>
And you guessed it:
>
I do the experiment, and wind up with smaller data.
>
Now, true -- I am leaving out a certain critical fact. But it's not
that my
method only works on machines having wireless, or that, say, you don't
mind me using hidden files -- it's not a fact associated with a fraud.
>
(It's the critical fact -- it's how it works. That's what I haven't
said.)
>
Thomas, you mentioned the idea of an algorithm. Yes. Good. That's
what I have, and my algorithm avoids the problems you present.
>
I notice that you liked my idea of loading data to an FTP site, except
that you want to supply the data, whereas my idea is to supply the
data
myself.

Sorry, this is not an option. How do you want to know that your later
customers only supply data your algorithm can handle? Didn't you say
you can compress *all* data? Doesn't *all* imply that *I* can select the
data?

But nevermind, here's my extended deal:

I still supply you my data, but instead, you do the following:

a) your compressor can handle my data as input. If so, the output
consists of a single 1-bit, plus the output of your compressor.

b) your compressor cannot handle my data as input. If so, the output
consists of a single 0-bit, plus the original file.

Thus, we're creating only an overhead of a single bit, given that you
claim that you can compress so much out of your input, this sounds like
a fair deal, doesn't it?

course, the target to meet has to be a bit different, (ha,
literally!) since you now make some files longer, unavoidably, so I
making the rules even better, just for you:

So for the eight-bit input, we do the following: I add up all the
bit-lengths of all output strings (say, 256 if the input is all 8-bit
combinations) where the indicator bit counts to the length, of course,
since I need it to decode, and if the sum is smaller than the summed up
bit-length of the input strings, you also win. However, we must somehow
ensure that your strings are decodable without sending me the decoder.
, so just make this sure in addition, I will test whether the
following holds:

\sum_{all my inputs} (1/2) ^ {total length of output for my input} <= 1

(Note that for my original input, we have 8 bit input, so the length are
all eight, so we have 256 * (1/2)^8 = 256 * (1/256) = 1, so the
inequality is satisfied. Note that the "one additional bit" also counts
in the length. That is actually better for you since it makes the sum
smaller, and it must be smaller or equal to one to make me accept your
code, or the part of the code you want to sent me.

This is the Kraft inequality. While it doesn't tell me whether your code
is decodable, it says that at least if we exchange some of your
codewords of some of the same size, we can make it decodable, so your
code, if initially broken, can be fixed without making it larger (and
the above bit-count remains of course identical, since the code size is
not changed).

Does this sound like a deal?

I have problems reading/processing a file of all bit combinations
because
it would provide an examiner with enough information to figure out
what I
am doing -- and I have not given up the idea of making a few shekels.

, then mark some of the combinations (random if you like) as
"non-compressible", and encode them instead with a zero-bit, plus all
the following input. Just hide enough, given that you create such an
enormous compression gain, this should still be easy, right?

I am pretty sure that as things are going, that one day you will learn
what
I am doing and you will see that my claims are not impossible at
all.

I can't wait

Greetings,
Thomas

PS: The first condition for Jules means that his entropy is smaller than
the entropy of the input (which is maximal by using a uniform
probability over all 8-bit symbols), which is exactly what Jules claims
("compress everything"). The second condition does not yet ensure that
the output is decodable, but at least it can be modified to something
decodable. This is the "if and only if" condition in Kraft's inequality.

jules Gilbert schrieb:

>Remember, at no point do you have to make your compressor available,
>which protects your technology.
>
I assume you know that never, never, never!, not under any conditions
whatsoever will I supply anyone but a bona fide customer a copy of
either the decompressor or compressor.
>
Thomas, don't be foolish! asking for me to do such a thing.

a) that wasn't my post,
b) that is neither my deal.

I'm providing now two challenges for you where you don't have to provide
encoder nor decoder. Read my other posts.

So long,
Thomas

jules Gilbert schrieb:

Really, this is between Thomas and myself -- I have not heard from him
(so far,) and he may not want to play using the rules that I am
forcing -- ie,, that I be allowed to use files such as MN's 1M file or
other 'famous' files, compressed using tools we all agree to be first-
rate compressors'.

Nope, that's not an acceptable rule, because it doesn't provide a proof
whether your compressor is working. Heck, if *I* can select the
algorithm, and *I* can also select the input files, then *of course* I
can arrange that to compress those inputs. Actually, for N input files,
I can compress to log_2 N bits.

, so well. What about this "third challenge" for you. You post N input
files, select them as you want, along with their output. And I come up
with a compressor that can compress them better.

I even stated my magic compression algorithm above - try to beat this
algorithm with your examples, and I'm also satisfied: that is, try to
compress N streams to less than N * log_2 N bits in total, plus satisfy
Kraft inequality, and I'm also fine.

That's now my third deal I'm giving. Still a chance?

But note, it's now very hard to beat me, much harder as in my second offer!

So long,
Thomas

jules Gilbert schrieb:
>
, now I see your response. (This post.)
>
I am only willing to demonstrate my process using inputs that are not
purely synthetic and (even worse,) designed not to test my program but
to discover the principles of operation. Acceptable files include the
files that all of us know about, such as MN's 1M file, and other
"famous" files first compressed using compressors that we all agree
are of premium quality.

Then I don't care. I can easily compress ten example streams (much
better than you, I only need four bits for that), and forget about the
rest (thus expanding on average again).

But as I stated above, I do not *need* all input, I even leave it to you
to *select* which of the 256 inputs you want - how much better can it
be? Please read again carefully. I designed the test in a way you do not
need to supply all output, only the one you want (but it gets then
harder for you, shouldn't be a problem for a super-compressor, right?).

But I am not going to let you folks slowly analyze, (as best you can,)
my program. I am trying to cause some events offline from this group.

With such input's, I am willing to process said input-file and show
the input and outputs side-by-side. This is all I am willing to do,
and I already know what the result will be.

And I know, too. Mathematics tells.

When I supply my program to customers I don't expect it to be used in
the manner you describe Thomas, so why should I sit still for this
now? (I shouldn't.)

You should to prove your claims. If your claims are "all input can be
compressed", then, why the heck, shouldn't I run it on "all input"?

, Jules, are you again making fake claims?

By the way, I did this a while back, but with a more primitive version
of the program -- actually very primitive; That program didn't
reduce every cell (this does.)

This doesn't neither. That's the way how mathematics works. Elementary
logic, actually. You only have to count. you can prove that, but
I'm not interested in a fake test. You cannot prove that all odd numbers
are primes by looking at examples:

3,5,7 prime
9 measurement error
11,13 prime

works for my examples, up to a small error, by induction for all odd
numbers

This is just silly. A "proof" is nothing you can run by example, a proof
is a logical argument. I provided one where you only need to supply
*some* examples, and then one can derive a proof.

But of course, you won't run this. This is because it would unravel this
time's fraud, isn't it?

well, same as always

So long,
Thomas

k it's all like flamey and stuff but really

actually infinite compression isn't possible

0
1

that's it. two combinations. there's no way of defining any
probabilistic quantization using parametric curves because there's
nothing smooth going on, actually.

that being said, wrap your mind around what this actually means as we
get close to a technological singularity where we could potentially
write down the most complex algorithm (all the data to be), and tell
me what that does when you have an observer involved.
you'd then have all the data, plus all the data from the observer's
viewpoint (which itself is a a subsection of the expanded, interacting
points of the all the data). this seems to be a type of paradox,
created by observers.

unless you're willing to argue that the paradox wouldn't occur since
no observer will *ever* be able to construct an algorithm to describe
this geometry, then we have a very, very interesting moment which
wouldn't be within existence at all.


basically, either it's that we'll *never* be able to produce such
dense information, or that there's something that exists outside
mathematics', and thus all physical laws, realms.

this is my theory. it's scientific, rigid, predicts specific outcomes,
and has experimental applications.


point one: 'weak prediction' the logic behind the expanded 'time' form
of the all of data is such that if there were enough physical matter
present at the beginning of time to account for all of the expansion
*and* interaction of absolutely everything ever, we would have found
traces. instead, we've found a crazily high energy spark in the
darkness, but all that energy and decaying particles still aren't
enough to correspond to the quantized interactions of those same
elements throughout all of time.

point two: 'strong mathematical law' even if we'd found new dark
matter in existence that could make up the quantized information
density, there would still *never* be a moment inside of time where
the observer and the algorithm for all the data could exist
simultaneously, mathematically. that would be like saying that the
full digital expansion of pi can be found inside pi itself. even as pi
is infinite in detail, it will still *never* produce pi after the 1st
digit.

imagine a 46 symbol engine A-Z and a-z. each symbol is taken as the
next one from the lord of the rings modulo the space removed file
size. this gives a rotator for any symbol, as long as a letter index
seed is stored within the phase space of the algorithm.

An interesting thing occurs with the probability of capa to non capa.
and all letter mapping is reversable.

because the capa are fewer in number they contain more information,
true?

the only reason for the non reversability of a non capa maop to a
capa, is the fact that statistically you may have to pass over another
non capa of the same letter to reach a capa letter. otherwise this
would be a Jaxon modulatable symbol exchange.

The thing is if a direct mapping is not used for the symbol exchange
(a algorithmic sequence with no interceeding non capa copies, pure 1
or 0 stream) then the symbol exchange needed for a modulation becomes
possible.

now the best way for achiving the symbol bias within the algorithm, is
to 'go through' the option of using a 0 longer than using a 1.

THIS CAN SUPPRISINGLY BE ENGINEeRED

what does the lord of the rings read like with all the interseeds
removed???

50:50 can be demi randomized to (25,2):(50,1)
this can then be cross switched to (25:1):(50:2) = 25:100 = 1:4

unfortunetly this then has an exit to sample probability reduction to
25:50

but lukily 3 seperate bias elements/rotators/rings being statistically
independent ENUGH

can be producted 25^3:50^3 = 1:8 ok

so this ring majority selection estimate (1:4) but active all cycles
not 1/8th cycles (hence why 3 used as always majority win)

is a jaxon modulatable stream.

luckily the user data gets absorbed

ok

cheers.

excellent, consider jaxon modulation to be a error correction code for
a compact virtual media (based on three rings of low information
count) which just happens to have some unuseable media positions, but
luckly enough useable ones.

ha ha ha, he he he, me is majick

i should be so statistically random, statistically random^3, i should
be so statistically random in lo-ooove. - kylie the scientist