Scaling down granularity

[Chuck Carlson]

: Hello All,

: What does compression mean?
: a) Disassemble (take to pieces)
: b) Discard redundant elements
: c) Re-assemble NOT losing functionality

: This procedure leads to a "purified", less redundant, more abstract version
: of the thing (idea, specification, construction, machine, algorithm) you
: had. I think this is the point why I like the compression idea that much.
: It seems to promise we can find means for "mechanically" deriving
: abstractions from sets of facts.

I've always been fascinated by abstraction and wondered about it's
definition and how it could be accomplished on a computer.

: (To the people who searched the Web for 'compression' and came here by
: chance: How do you compress a camcorder? Use a hammer (you will lose
: functionality forever - this is trivial). What else? Disassemble and pack
: neatly. But it won't take videos any longer. If you want it working again,
: you must unpack and re-assemble it (zipping and unzipping). What we are
: discussing here is the third way: How can you "make the functioning
: camcorder more compact", how to "miniaturize" it. And this is the
: challenging point - how can we automate this procedure?)

Another example would be the relationship between the blueprint of a
building and the building itself.  Lets say you were given the building,
in all it's detail, as a huge set of patterns.  How can one, in an
automated way, derive the blueprint from this data?  My guess would be
that another set of patterns, representing the knowledge of architects,
draftsmen, builders could be applied to the building data to produce the
blueprint.

: When applying compression steps (a) to (c), you will find, that it is near
: to impossible to discard redundant elements because nothing is completely
: redundant; in most cases only a part of an element could be discarded.

If you knew what your final goal was, then it would be easier to determine
what was redundant or not.  In any case, one would have to keep around the
complete set of elements, or know how to recreate it, so as to be able to
construct various compressions or views of the system depending on what one
was interested in.

: Consequently, you will start disassembling this very element, and so on.
: Consider another point. When disassembling a thing, which will be the most
: comfortable way of maintaining overall functionality of the thing? Try to
: disassemble to elements which are still functioning entities! (Object
: oriented program design does this "intuitively".)

: Compression is that difficult, because we are faced with two conflicting
: goals: disassemble as far as you can, but do not disassemble further than
: the individual elements lose their lives.

One has to disassemble in order to know what and how to compress.  But the
act of disassembly means that you already know about certain components.
In your camcorder example, to disassemble it, we would look for things we
already knew would help us take it apart, such as screws and latches.
In a compression oriented computing environment, data sets would have to
be entered already disassembled or linked to components that were already
in the system, which were described using the most fundamental information
components.

: It seems you can compress a system the easier, the more the system designer
: considered the feature of compressibility. To me, this is the reason why we
: are faced with a still marginal progress in the field. Up to now, none of
: us cared about compressibility. The granules we are working with are too
: bulky. How would you compress a CISC CPU? It was not designed to be
: compressible. And all the large, unstructured programs designed for such a
: CPU run into the same trouble.

If we had computing environments which would not allow us to input thse
huge, bulky chunks, we could avoid a lot of problems.  Of course, such
a system would be hard to use at first, because we would have to specify
lots of details, until we reached a point where we could start describing
things using compressed components the system had already discovered.

: To make compression really compute, we must provide (at least - simulate)
: an environment which welcomes compression, which is built of minimal
: functioning entities which can be flexibly aggregated to systems of
: arbitrary size, and which can be re-arranged at any time we wish.

This is the most important goal for me.

: Only this
: way the compression trick will work. We must first scale down granularity
: of existing technologies before we can harvest compression crops.

We can do this scaling down by describing the components of existing
technologies using our hopefully-soon-to-be-descovered fundamental
information component.

: I suggest
: the listening CasC community answering these questions:

: Which is the smallest entity of which still can be said, ...
: (1)  it is a fact (the minimal data element)?
: (2)  it is a command (the minimal activity element)?
: (3)  it stores a fact (the minimal memory)?
: (4)  it processes a command (the minimal processor)?
: (5)  it recognizes a pattern (the minimal detector)?
: (6)  it says which two facts have to do with each other (the minimal
:      association)?
: (7)  it describes what to do or what to conclude if (the minimal rule)?
:      and
: (8)  Which is the granularity level from which on you cannot distinguish
:      any further between declarative and imperative instructing?

These are some of the very fundamental questions that need to be answered.
I've often thought about what was the smallest information building block
that could be used to construct anything.  But maybe, the ultimate
granularity is a just a point in a multidemensional space and then the
problem comes down to how these points are compressed, manipulated,
combined, and viewed.

: So far for today. You feel, I ask these questions because I want to provoke
: you talking. I am glad I found this mail list which may contribute to the
: future of computing.

Thanks.  You provided excellent discussion points.

: Detlef Morgenstern
: Dresden, Germany

Chuck Carlson
Berkeley, California