keeping simple » automata

Process algebra reconsidered

admin — Fri, 07 May 2010 16:23:52 +0000

Paper is here.
The following incorrect claim is not unusual in the process algebra literature.

Basically, what is missing [in classical automata theory] is the notion of interaction: during the execution from initial state to final state, a system may interact with another system. This is needed in order to describe parallel or distributed systems, or so-called reactive systems. When dealing with interacting systems, we say we are doing concurrency theory, so concurrency theory is the theory of interacting, parallel and/or distributed systems.[Bae05]

Actually a sophisticated notion of state machine product was developed for representing composition of “interacting” state machines starting in the 1950s[HS66]. A general survey can be found in a monograph by Gecseg[Gec86], Domosi provides a more modern, more algebraic treatment [DN04] and [Yod09] provides practical techniques for construction of complex products.
[...]
The reader familiar with the process algebra literature will note that such an effort must find a way to model the non-determinism that is so fundamental to the process algebra world-view. Since deterministic programs are used to produce pseudo-random number sequences and to model Brownian motion and even the stock market (perhaps not the best example at this date) the problem is easier to solve than it appears at first. Section 4 will include a short discussion on the difference between “real” non-determinism and simulated non-determinism, but certainly there is nothing in the basic axiom set of Milner’s original process algebra that notices this distinction as far as I can see.

To read more see the paper.

Queues and algebra

admin — Mon, 01 Mar 2010 02:00:15 +0000

Suppose we have a state machine Q, that implements a common first in first out queue. The input alphabet of Q consists of “Deq” and “Enq x” where “x” ranges over a set of values, say, V. Let’s fix the max length of Q at some constant k. As usual, given a sequence of events “w”, write Q(w) for the output of Q in the state reached by following “w” from the initial state. For the empty string NULL, define Q(NULL)=(). If a=Deq then define Q(wa) depending on Q(w) – if Q(w)=() or Q(w)=(x) then Q(wa)=(). If Q(w)=(x1 .. xn) then define Q(wa)=( x1 …). If a=Enq x then if Q(w)=() define Q(wa)=(x), if Q(w)=(x1 .. xn) where n

If you visualize the graph of Q, you can see it contains non-trivial loops – which means that the monoid associated with Q contains groups. The advantage of decomposing Q into a product of smaller machines is that this might guide a smarter implementation. Well, I’m kind of cheating here, because programmers have found a variety of smart implementations that do strip out the group structure.

The easy decomposition produces two counters, and a collection of k storage elements that are loop free state machines: an input “store x” moves the machine to a “x” state. They do contain loops but only trivial ones. The counters are group machines. We number the storage cells 0 to k-1. We can have one mod k counter that “points” to the tail of the queue and one that counts the size of the queue. On an enq operation the enqueued value is stored in the storage element identified by subtracting the size from the tail mod k, and the size is increment mod k+1. An enq operation when the size=k is ignored and has no effect. On a deq, the size is decremented and the tail is incremented by one mod k+1. What we’ve done is construct a system in which the state machine monoids are two cyclic groups and k-aperiodic monoids. If we then switch to more complicated data structures, like ordered lists, it’s not that hard to see how a permutation group might be used to manipulate pointers to a pile of storage locations. For example (n1,n2,n3,n4,blank, n5,n6) might be an ordered list with n5 and n6 being free. An enqueue would generate some shuffle to say, (n1,n2,n5,n3,n4,blank,n6) and then a dequeue would produce (n2,n5,n3,n4,blank, n6,n1).

A nice property of groups is that “undo” always works. So if the data in the storage elements can be marked in some way, a deq or enq can be undone by subtracting mod k or permuting backwards.

simple lemma about pipelines

admin — Fri, 26 Feb 2010 01:23:42 +0000

The connection between group structure and pipeline design seems like it merits a lot more attention than it gets. It’s not too hard to show that in a pipeline like the one to the right, the induced monoid of M1 must be a homomorphic image of the composite state machine. This immediately brings in the limiting factors of simple groups.

KR theory is too vague though. For example, I’d like to know something about the relationship of M and M’ in the case that the induced monoids are isomorphic. They definitely do not have to be the same, but seems like they should be similar enough so that changing the output map would equalize.

Process Algebra and classical automata

admin — Sun, 01 Nov 2009 19:25:36 +0000

The long awaited process algebra paper is now finally available in PDF

Reducing Process Algebra.

Process algebra (updated)

admin — Fri, 10 Jul 2009 01:32:41 +0000

The first part of a critique of process algebra is below.Â This relates to the Recursion and State paper and explicatory blog entry where I show how to compose classical automata and define them “abstractly” and to a complaint about the weak critique of automata theory in standard process algebra literature and also to a remark about Dijkstra’s error. Â There are other parts of it scattered around in some recent posts and some other issues that need to be raised, but the basic argument is in place.

The source of error (updated)

admin — Wed, 08 Jul 2009 05:10:54 +0000

Here’s Edsger Dijkstra discussing the birth of the use of axiomatics in computer science – the start of “formal methods” research.Â What’s striking is the assumed choice between “axiomatic” and “mechanistic” as if there was no other way. In a later note he writes:

And now we are back at our old dilemma. Either we take by definition all properties of the model as relevant, or we specify in one way or another which of its properties are the relevant ones. In the first case we have failed to introduce in the name of “divide et impera” an interface that would allow us to divide and rule and the study of how we could build upon the (only implicitly defined) interface seems bound to deteriorate into a study of the model itself; in the second case we are again close to the axiomatic method….

[...]

Or, to put it in another way: if the traditional automata theory tends to make us insensitive to the role interfaces could and should play in coping with complex designs, should it then (continue to) occupy a central position in computing science curricula?

And I’m struck by the ideaÂ that seems utterly wrong to me, that one either uses the methods of formal logic OR one is stuck without any ability to abstract or underspecify

The reason mathematics has advanced so much was not because of the Euclidean axioms-lemma-theorem straitjacket, but in spite of it. Luckily, when we actually discover mathematics, we do it the Babylonian way, empirically and algorithmically. It is only when it is time to present it, that we put on the stifling Greek formal attire.

so says Doron Zeilberger

UPDATE: I have a draft of the “process algebras considered harmful” note up.

Recursion and state

admin — Thu, 02 Jul 2009 21:32:40 +0000

Despite some deep results, algebraic automata theory has fallen out of favor in theoretical computer science. Reasons include the disciplines failings such as a love of over-generality, weak mathematical background of people working on “formal methods”, and gap between theoreticians and engineers. But perhaps the key reason is that traditional state machine presentations in terms of state sets and transition maps are awkward and carry too much irrelevant information.

The standard presentation of a Moore machine isÂ M=(A,X,S,st,Î´,Î³)Â whereÂ “A” is the alphabet of events, “X” is the set of outputs, “st” is the start state,Â Î´:S x Aâ†’ S is the transition function and Î³:S â†’ X is the output function.Â ButÂ we really don’t care about the state set in all but the simplest state machines. Interesting systems have ridiculously large numbers of states.Â Names of states don’t matter.Â Extra states don’t matter. Suppose “s” is an element of “S” that is unreachable – no sequence of inputs will drive M to “s” from “st”. In that case what difference does removing “s” from “S” make? Or suppose s and s’ are both reachable but not only is Î³(s)=Î³(s’) but for any sequence of inputs that can drive the machine from s to a new state, the output of that new state is identical to the output of the state reached by following the same sequence of inputs from s’.Â In that case, we could simplify S and Î´ by removing one of the duplicative states and merging paths.

What’s more interesting is to consider what output a Moore machine will produce from a sequence of inputs: thinking of the Moore machine as a map from input strings to outputs. This isÂ a function that can be constructed by primitive recursion on strings.Â First, extend Î´ to strings to define a new function Î”. TheÂ Â empty string that has zero length doesn’t cause any state change Î”(s,empty)=sÂ Â and if “w” is a string and “wa” is the string obtained by appending “a” to “w”, then Î”(s,wa)= Î´(Î”(s,w),a).Â DefineÂ M*(w) = Î³(Î”(st,w)). The idea is that M*(w) is the output produced by M in the state reached by following “w” from the initial state.Â If you look at M* you see it contains all the interesting information in M -Â because the names of states and unreachable states and duplicate states are not interesting. In fact in the 1950s Myhill and Nerode described how to generate a state machine (not necessarily a finite state one) from any function on the set of strings over an alphabet.

These functions are much more useful in describing complex state systems than are Moore machines – not least because they can be partially specified when we don’t know or care about all the possible behaviors of the system and because they can be composed in a way to represent any interconnection.

In the next post, I’m going to discuss composition of message passing processes and compare to the “formal methods” approach which is based on the incorrect assumption that automata need to be “enhanced” in some way and that replaces automata with things that have very little mathematical structure at all.