Fundamental Compressionist Philosophy.

[Detlef Morgenstern]

Hello Andrew,

I feel a convergence of software (Gerry), philosophy (you) and
hardware (me). Let us invest effort in building functioning
implementations of our ideas.

I agree that there is a close link between C&C from a specific point
of view.
--- Andrew Stanworth <andrew.stanworth at bigfoot.com> wrote: 

> I accept CasC at a deeper level, whereby a programmable computer
> is a compressed system already!! By this I mean that a computer
> is composed of functional blocks (which ultimately can be
> produced from nothing but two-state switches) which are
> interrelated by the process of 'programming' but which
> the 'computer' itself contains as 'essential chunks of
> functionality' (i.e., already compacted - conceptually
> if not physically).

A programmable computer represents our knowledge on computing. It is
an abstraction. Which means it is compacted knowledge. One could say:
If you want to compute, you must have an abstraction of what
computing is. You must compress your observation evidence on how one
can compute until you reach the essence - a theory of computing.
Hence, no compression -> no abstraction -> no computing.

> I think your approach is motivated by a desire to increase the
> inherent efficiency of the system, as well as trying
> to understand something deeper about the essence of
> 'functionality' itself - which seems to hold the prospect
> of satisfying both practical and aesthetic concerns.

My approach is motivated by the desire to build a simple machine
which can abstract.
(1) Tell it what request->reply associations it has to deliver, and
it will do so (the trivial 'echo' level).
(2) Give it an order to reproduce an identical behaviour consuming
fewer resources. As few as possible! The only way to do so is
rearranging resources (switches or whatever you want to see as atomic
'units') with a gradient towards higher compaction. The machine can
check two simple things without external interference and *without
any knowledge on the context* of its task:
(a) Does it still function as before? (It may store the 'echo'
prototype of itself and compare the behaviour of the current mutation
against its own prototype)
(b) Does it consume less resources (number of switches etc.) than the
prototype?

The compaction process can be driven by
- evolution-like principles
- heuristics
- hard rules
all of which incorporate our compacted knowledge (abstraction) of how
abstraction works.

There is a chance that the machine will find another implementation
of itself which is significantly smaller. The chances are the higher,
the more regular the body of request->reply associations is which the
machine is told to compress.

Any smaller implementation found by the machine is a better
abstraction. A significant compaction may make us say:
'The machine has found a law'.

Does someone here know such a machine?

This is my motivation.

Detlef
PS. After its first successful abstraction we should let it run on
improving its 'prototype' compression rules. Let it have a contest
against itself: Given a certain prototype, which compression rules
deliver better and/or faster abstractions?








__________________________________________________________________
Do You Yahoo!?
Gesendet von Yahoo! Mail - http://mail.yahoo.de