Fundamental Compressionist Philosophy.

Tue May 22 05:15:49 PDT 2001

Hi Gerry and Detlef,

Gerry wrote;-

| The idea that a switch (in the form of a transistor) is a basic 'atom' of
| computing has led to some research, which, in my view is slightly off
| target. People have tried to do computing using light and they have also
| tried to do it using individual molecules. In both cases, it is often
| assumed that the necessary first step is to make a switch and then
| everything else can be built from that.

I am familiar with some of the work in this area, both inorganic and
biological.  As far as I am concerned, the bottom line is that if a system
can not implement some form of stable input/output associated two-state
switch, it can't be used to build a computer.  If it can support this, then
everything else can indeed be built from that (that was, after all, the key
point of my web-page).  In this sense, it is not so much the necessary first
step, as the fundamental requirement.  Consequently I think that research
into such capabilities is essential.

| This is not exactly wrong, but I think it may miss some opportunities. I
am
| developing the idea that computing is largely about matching patterns and
| unifying them. This kind of thing can be done with switches. But it can
also
| be done in other ways. With light, in particular, there are exciting
| possibilities for matching patterns in very flexible ways and with very
high
| levels of parallel processing. If people concentrate on building switches,
| they may miss these kinds of possibilities.

I understand that there is virtually never a 'need' to reduce to absolute
fundamentals when thinking about actually realising a system, especially in
our the modern universal computing machine (UCM) rich environment.  As far
as actual functionality goes, producing even the simplest architectures of a
functional system entirely from switch systems is a **cker, and could
possibly lock a designers thinking into low level 'micro' functionality.
So, in effect, I also agree with you.  My bottom line in this is that there
are many different architectures of UCM, operating at many different levels
of complexity (from a brief examination of your computing by compression
ideas, though a little shady on the specific nuts and bolts of your
implementation, it seems plain to me that this system design functions as a
UCM), which one you choose depends purely upon how easy it is to configure
it to accomplish your desired task(s).

Your system seems to rely upon the reduction of data through compression, to
reveal its underlying connectedness (data without such underlying
connectedness being one definition of 'randomness' and hence of no benefit
to process with your system).  Thus, it exposes the functionality by
compaction of input data (i.e., identifying the underlying patterns of
regularity) rather than needing the functionality to be programmed in before
the input data can be processed.  In this way you arrive at a system which
can also be driven in the opposite direction, through the exposed levels of
connectedness, to produce output data which obeys the same, now exposed,
'rules' of connectedness.  Hence the name of this discussion group -
'Computing as Compression', though 'Programming as Compression' (PaC) seems
a much better description (and acronym).

I can also see that your system belongs in the 'neural network' family of
architectures.  Please note that I do not say that it 'is' a neural network
in the commonly accepted algorithmic view of the term.  Instead I think it
is a close relation.  My reason for saying this is that both systems can be
driven by input data to elucidate a non-specified connectedness - i.e., they
are both learning systems which make connections in the manner of neuronal
tissues - though in your system, this neuronal functionality does not seem
to be plainly in view.  Also, they can be driven in either direction once
programmed (or as they are being programmed).

The section in my book "The Myth of Reality" at www.seaca.org entitled
"Fundamental Psychological Development" deals with my interpretation of
essentially the same process (i.e., of learning through pattern matching)
though it deals with the human machine (and the impetus driving it to learn)
rather than any accepted computer architecture.

In case I haven't already made it clear, it's plain that the core concept of
your system has great potential and many applications - and I like it!!

Detlef wrote,

I see a clear difference.  Firstly, your example falls foul of the
mind/matter philosophy-schism debate.  In short, my answer would be that
without either mind or matter there would be no aromatic functionality (in
the food taste sense of aromatic).  Secondly, it must be understood that I
am not a switch fetishist.  I couldn't give a **ck  ;-})  about physical
switches, they are just a device I used to try to portray the core concepts
as a tangible reality.

| Which still unanswered question can be answered, knowing that
| (binary) computing rests on switches?

The concept which I hope the 'switch' embodies, is the fundamental,
reductionist, building block of all communicable knowledge.  As far as the
questions it can answer - I am currently writing up the philosophical
implications.

| I think, we have to dig a little deeper.
| How must we arrange the switches that least effort is needed to
| instruct the system for the set of desired request->reply
| associations?
|
| We can approach this from the content side - which Gerry is doing.
| We can approach this from the hardware side - which I try to tackle.

I understand that where Gerry's interest in computing as compaction rests
upon the use of compaction to produce the specifically desired functionality
of a system, your interest in computing as compaction is to compact the
functionality of the system itself.  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.  I look forward to discussing these matters further with you.

For myself, it seems that my interest in 'Computing as Compression' is
related to the behaviour of granular thermodynamic systems (i.e., functional
3-D cellular automata with what are, presumably, the core rules driving
evolution and natural selection - specifically the drive towards greater
efficiency).  Hence, my interest in compaction straddles both areas,
compaction to produce local functionality and compaction to produce greater
inherent efficiency of the system as a whole (and its sub-units).
Consequently, I see an equivalence between compression and optimal energy
redistribution (i.e., thermodynamics) and so, in the aforementioned CA, it
is perhaps helpful to think of my interest as properly being called 'Life as
Compression' (not in this context Conway's Life!)- though since it is a life
supported entirely through a UCM framework, it falls under the 'Computing as
Compression' umbrella.

Detlef;-

| -- Does a falling stone compute? --
|
| Yes. It represents a complex network of differential equations
| reflecting these physical phenomena:
| - cinematics
| - gravity
| - principle of the conservation of energy
| - aerodynamics
| and - if fast enough -
| - thermodynamics, gas dynamics, and optics.

In my CA system, a falling stone would be computed and would not compute in
and of itself!!!!!

Detlef also wrote;-

| It is difficult to imagine an *efficient* way of programming which
| has nothing to do with compression.
|
| Along this longer chain
| Computing <-> Programming <-> Programming Efficiency <-> Compression
| I accept CasC.

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).
With this in mind, and also bearing in mind your interests, it would be
interesting to see if Gerry's system, supplied with the appropriate
programming examples, would automatically identify the essential functional
building blocks needed to produce a computer architecture able to support
the programming language directly (which I strongly suspect it would - and
see no reason why not).  In effect, what I have proposed is that it should
be possible to achieve your goals via specific implementations of Gerry's
ideas.  Also, it should be possible to set the level of compaction to
achieve any level of complexity of such functional building blocks - and
hell, that keeps everybody happy even if they don't like thinking about
computing as arrays of two-state switches!!  It also puts Gerry's system
back as being 'Computing as Compression' (in case it seems as though I keep
changing my mind, it is just that looked at from one angle Gerry's system is
better described as being 'Programming as Compression', but viewed from
another it is better described as 'Computing as Compression' - it's just the
context that changes and not the system).

Detlef;-

I am in the process of producing another page for my website which includes
my definitions of the above terms (as a necessary step in the writing up of
the philosophical implications already mentioned).  So, I will return to
this later Detlef (not that I mean to disagree with you, or that you
necessarily wanted me to talk about this, it jsut so happens that I am in
the middle of doing it and I haven't quite finnished yet).

Best wishes to Gerry and Detlef,

Andrew.

P.S. I am sick of switches now ;-})

e-mail: andrew at seaca.org
website: www.seaca.org