Talking about the Pile Interactive Learning Environment (PILE) is talking about notation first.
Let there be different kind of entities:
- transitions (arcs)
- responses (actions)
- circles (forms)
- horizontal dotted lines
In the figure (a) above, we see an arc, i.e. a transition. Transitions are annotated by an event symbol (like a) and an optional response symbol (like x), which are separated by a slash character from each other.
Instead of a, we will use event# as event symbol: event#1, event#2, …, etc. or #1, #2, #3, …, etc. for short (see figure (b)). And Ui instead of x accordingly. Ui is short for Unique identifier. Ui is the response to an event#.
Transitions connect something, in other words Pile_Objects, i.e. forms. In figure (c) we see such a form drawn as a circle, which is marked by a Cp symbol. Cp is short for Combinative Pointer.
Please note: that circle is not a box! (nor a container!) It is just a form with a mark.
Equipped with these prerequisites, let us now enter the PILE PETER Universe. That means, first of all, that we cross a boundary: the boundary between a Pile Agent and the Pile Engine. We are now the engine. The agents are our new and only environment.
Let us define a System Definer (SD). Our SD is event#0 or
SD = #0
Okay, we–the engine–are on duty now. What can we do for our agent? We can handle events, i.e. meaningless(!) numbers. Semantics is not our business! Meaning, usefulness, and alike is agents‘ call.
Something very important is still missing: the user. The user is the observer and able to watch both of us: the engine and the agents.
The PILE PETER Universe is a very simple universe. There is a stream of some letters only:
That translates into events like this:
- event#1 = P,
- event#2 = E,
- event#3 = T,
- event#2 again!, and
- event#4 = R.
Please note: There are five letters, but only four events!
Let’s call the events #1 to #4 Terminal Values or Tvs for short.
The user/agent likes to have this Terminal Values now registered by means of us, the engine.
The Cauchy/Cantor Diagonal Method, as described in (Hardgrave 1976 – A technique for implementing), provides us with the Ui. The following figure is a table demonstrating the mapping for the pair <Cp0,Cp1>,
Cp0 increases down the left side column and Cp1 increases across the top (row). The value (Ui) of the mapping may be found in the table at row Cp0, column Cp1.
So, the Ui of our Pile_Object <0,1> is 3. This is what we can write down as response in the transitions‘ annotations (behind the slash characters).
The next figure shows the current state of the PILE PETER Universe, i.e. our Pile System:
The Cp2 of our new Pile_Object is 5, cause it is ‚the fifth element‘ (!) in our system (5 is the actual value of our global Cp2 counter). Constructing the other Pile_Objects is left as an exercise for the reader.
The amount of Pile_Objects is fixed by the number of Tvs. Given four Tvs there are 2^4 = 16 Pile_Objects plus one Pile_Object acting as SD. Four of that 16 Pile_Objects ‚are‘ Tvs.
Note (2006-06-29). 17 Pile_Objects seem to be the limit if one is interested in getting a ‚hanging‘ binary tree as PILE PETER Universe, isn’t it? Could we create more Pile_Objects than that 17? Or could we get the same functionality with less Pile_Objects as well?
The resulting PILE PETER Universe is only a small example of a Pile System, but nevertheless worthwhile to play with to gain some own experience. I’m curious to read your comments, which I’d prefer to share with the community in the Pile mailing list.
P.s. (2006-06-29 15:25 CEST) The PILE v0.1 Notation is build upon previous work done by Miriam Bedoni, see (Bedoni 2005 – Pile-The Technique.pps); Proutskova 2004 – The Pile System; Dave Harel (1987): Statecharts: a Visual Formalism for Complex Systems. Science of Computer Programming 8 (1987,3), 231-274; George Spencer-Brown, Wolf 1999 – Laws of form = Gesetze der Form; Hardgrave 1976 – A technique for implementing…; and many others… Thanks!