| niels.froehling@seies.de 2005-12-12, 6:55 pm |
| >> In short you suggest that the redundancy in the formulation of the
>
> Thatz a nice way to put it :-)
I even have a completition:
The redundancy in the way to formulate data in our world, makes
compression
possible, without that everything couldn't be differenciated from
random data.
The redundancy comes from the way language is defined in this very
moment, so
my guess is that with more complex language-models (those should occur
with the
progress of humankind, maybe they're even machine-invented), the data
that is
compressable _decreases_.
This is contradictious to the understanding, that when the amount of
data
that is formulated in language A increases, you can compress more data.
But
the condition of this is (counting-theorem) that the amount of data
that is
compressible increases, because of repetition of (different)
compressible
data. That doesn't happen when you make language B in that less
pattern/repetition occurs.
> My idea was that humans should keep a more open mind when deciding on
> what might have higher probablities, or when deciding how to predict
> better. Maybe rely more on experimental results rather than intiution.
>
> With brute force, you have managed to eliminate humans altogether.
> Welcome SkyNet.
But redundancy is a _must_ for the human way of thinking, it's like
you
have a 'suffix-tree' instead of a 'markov-chain' (with cycles). For me
compression is nothing else (like a lot of other computer-calculated
solutions) than the after-burner (post-processor) for the human way. A
helper-utility for optimization problems.
We are utilized for maximum pattern-recognition/pattern-combination,
the computer is utilized for maximum re-representation of human output.
We and the computer combine, not oppose.
That means each technology (brain/cpu) is used for what it's really
good
for, none can replace the other. The human has the idea, the computer
proofs it.
So my point was a bit sarcastic, be fast where it's needed to be fast,
and efficient where it's needed to be efficient, no single option is
'optimal'.
[color=darkred]
> We are always making compression-ratio vs speed trade-offs. To include
> time in definition would have made it very complex to define
> "shortest". eg. "What is the shortest program that will generate a
> specific string in a given time?" (I am just guessing here)
But that's how it should be. How can you call an effectivly
non-terminating
program (runs from the second second of the beginning of the universe
to
the second before the end, you don't have time to analyse the result)
be
called 'optimal'?
Ciao
Niels
|