Robust-first Computing Wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Robust-first computing concepts: Neutral Dynamics ======

Here's a question.  It's sort of a riddle or a //koan//:

  What is the behavior of a computer without a program?

Before a programmable computer has been programmed, before a customizable machine has been customized, before an adaptable device has been adapted --- before, in short, **we have exerted our will upon a system** --- how does it behave?  What does it do?

We call the answer to that question a machine's //neutral dynamics//.  The behavior of a programmable machine, before we program it or interact with it, is its neutral dynamics.  If the machine is sufficiently stateless, its behavior //between// our interactions with it may also be called its neutral dynamics.

The neutral dynamics is a fundamental concept for the effective prediction and control of a machine's behavior.  It is the canvas and the frame, the playing field and the rules, the //givens// we must consider --- both in the design and implementation of a program for a machine, and in the assignment of credit or blame when a program execution succeeds or fails in achieving its goals.

For the benefit of non-programmers, we note immediately that the distinction between "spontaneous" and "programmed" machine behavior is not fixed and absolute, but malleable and contextual.  It is partly a matter of choice, of our adopted definitions and interpretations and interfaces, just as the concept of a //virtual machine// allows us to reinterpret a hardware+software combination as being a new kind of hardware.  As programmers, we are free to conceptualize the hardware-software boundary wherever it provides the most leverage for us to accomplish our goals. 

So in the general philosophical case, the definition of neutral dynamics depends not only upon the programmable machine, but also upon us, the machine's programmer --- as well as upon our mutual surroundings, and upon the phase of the fabled double moon of Ivvaric III, and so on.  But we let all that go, because our present concerns are grounded and practical.  As programmers, we want to familiarize ourselves with typical neutral dynamics --- to recognize them when we see them, and gain some experience dealing with them --- to make more effective use of the machines we encounter in our environment.

The most elegant hack is not necessarily the fastest piece of code to write or to run, nor the smallest.  The most elegant hack is the one that best integrates the job to be done into the neutral dynamics of the machine.

===== The neutral dynamics of classical computing =====

So, then: //What is the behavior of a computer without a program?//  Well, for a classical, traditional computer, typically the answer is: **Nothing**, or **Waiting For Program**.  Before being programmed, a traditional computer sits waiting, frozen.  Its neutral dynamics is a static fixed point; it is computing the identity function; its state-versus-time phase plot is just one single dot.

And such static neutral dynamics is certainly one sensible option.  The program tells the computer **everything** it should do, we reason, so without a program the machine can do **nothing**.  Being in a single completely determined '**Reset**' state makes our job as programmers easier --- at least to get started.

But such fixed-point neutral dynamics is far from the only possible case.  If it is our will to learn the time of day, for example, and we happen upon a person that seems likely to know, we can run the 'Excuse me, have you got the time?' program upon that person, and quite likely achieve our goal.  Whatever that person was up to before we exerted our will upon them --- crossing the street, buying an apple, daydreaming until the bus comes --- it was **something**.

And in any case, classical computers with static neutral dynamics are getting harder to find.  When you power up a typical new machine today, it //tries to program you//.  It tries to get you going answering questions, giving your name and this and that and god forbid your credit card number, and like a pushy house guest it immediately wants your wifi password to start sucking great gobs of who knows what through your internet connection.  Programmers often have to do quite a bit of work to gain the upper hand in such who's-programming-whom wrestling matches.

===== Neutral dynamics in the Movable Feast Machine =====

A Movable Feast Machine is an array of //sites//, each like a box in a piece of graph paper.  At any given moment, each of those sites may be empty or may contain one //atom//.  Each atom is an instance of some type of //element//, and over time the atom will spontaneously behave in a manner characteristic of its type.
{{ youtube>5P6Dihkrvus?large|Random walking in the MFM}}

The spontaneous behavior of an empty site is to change nothing about itself or its neighbors.  As a result,  
an entirely empty Movable Feast Machine will remain empty --- unless acted upon by an external force --- and so the collective neutral dynamics of an empty MFM is a fixed-point, just like a classical computer.  

But while the bit values in a classical computer are utterly passive until acted upon in the course of a sequence of execution, in the Movable Feast Machine, individual atoms have inherent behaviors which they actively perform whenever they get the chance. 

One of the most basic of such behaviors is //diffusion//.  If an atom has nothing better to do --- or after it has done whatever else it wishes --- many MFM Elements specify that atoms move to a random adjacent site, if such a move is possible.  This yields a vastly different neutral dynamics compared to a classical computer.  Rather than a single static fixed point, such a machine wanders around in a phase space whose dimensionality depends on the number of diffusing atoms, or on the overall size of the machine, depending on how you look at it.  

The video at right illustrates eight 'Data' atoms diffusing in the //mfms_l// 'large' MFM simulator.  The color coding uses Dave Green's excellent [[https://www.mrao.cam.ac.uk/~dag/CUBEHELIX|cubehelix]] color scheme to represent the time since a site's value has changed --- so for the most part, we aren't actually seeing the Data atoms in this video, we're seeing where they've been and how long ago.  Video frames are captured at gradually accelerating intervals so that after $N$ seconds of video, something roughly proportional to $N^3$ total events have occurred.  We call such a representation //cubic time//, and it provides one way of observing a machine's dynamics over a range of time scales.  (Other possibilities, beyond regular //linear time//, include //quadratic time// and //exponential time//.)

This video ended up a little pretty, so I just stuck some public domain Tchaikovsky underneath it using Google's video editor (that's why it's rough at the end; I'm an utter newb at Google's video editor).  See what you think.

Is such a neutral dynamics harder to predict accurately than the classical machine RESET state?  Absolutely.  If we do it right, in fact, it will be essentially impossible to predict, in detail, from the outside.  Harder for the programmer?  Yes, definitely, in some ways: MFM programmers must be aware of odds and statistics rather than just logic and inference.  But harder for an attacker too, and the MFM programmer has the advantage --- we very much hope --- of getting there first.