DISTRIBUTED COMPUTING SYSTEMS AND METHODS

CROSS REFERENCE TO RELATED APPLICATIONS

[0001] This application is an International Application claiming the benefit of U.S.

Provisional Patent Application No. 61/947,924, filed on March 4, 2014, titled 'Artificial Intelligence Systems and Methods," the entire contents of all of which are hereby incorporated by reference herein, for all purposes.

TECHNICAL FIELD

[0002] This disclosure relates generally to methods and systems capable of operating in a distributed computation processing environment and more specifically to space-like computation systems and methods that are reversible (i.e., wave-like) and that create information.

BACKGROUND

[0003] The term "artificial intelligence" ("AI") can be thought of as a euphemism for something that can be too risky to say directly if one wants to be properly scientific: "artificial consciousness". But this denial has left the discussion of what consciousness is up in the air, and as a result, things like "big data" crunching and huge Bayesian networks -sophisticated though they be - are now routinely referred to by journalists as "AI". A typical example, this from a recent New Scientist: "Computer aces child's IQ test. An AI program that understands words has scored as high as a preschooler in a verbal IQ test. ... AI's such as Google's search engine or IBM's Watson In fact, the mentioned technologies underlying such systems as Watson and Apple's Siri are realized with standard software tools, and there's nothing mysterious going on anywhere. It's all put in "by hand" so to speak, and there's nothing non-Turing about any of it.

[0004] The absurdity of equating data-thumping with "artificial intelligence" is apparent when we replace the euphemism by its reality, "artificial consciousness", because it is intuitively clear that "consciousness", by its very nature, cannot be "artificial"- only the real thing will do. And this real thing is emergent and self-organizing and not "put in by hand" at all. So consciousness is what we're really about in the field called AI, or at least what some ought to be thinking about. Unfortunately, exactly what consciousness is is problematic. A point of entry for the working definition Consciousness is awareness of awareness, since it seems to reduce the scope of my ignorance. So the question becomes, ' 'What is awareness"?

[0005] Just to disambiguate, by awareness I generally mean Self-awareness, i.e., the feeling that one is a unitary entity, even whilst in profound appreciation and contact with one's surround. This Self-awareness is generally larger and mostly unconscious relative to our normal waking (i.e., ego-)consciousness. Awareness, without the unitary feeling, is said to accompany certain very deep meditative states. The disclosure presented below allows both.

[0006] From a "systems" point of view, awareness, being un-localized, looks like some kind of distributed computation (e.g., in the context of distributed artificial intelligence). A distributed computation consists of many more or less independent processes that together, with little or no centralized control, nevertheless produce globally coherent behavior. Examples abound in Nature, from beehives and anthills to ecologies, and from molecules and crystals to the quark structure of protons. Other favorites are the schooling behavior of fish and flocks of birds turning en masse.

[0007] However, the difference between these systems and awareness is that awareness is not material - it has no substance - and yet it nevertheless seems to possess agency, even though its coherence is ineffable.

[0008] The only general purpose concept (that I can think of) that matches this description is a wave. A wave, to be a wave, is an extended affair. I like to say that, so to speak, a wave is everywhere. The other part of the wave concept is that, even though it is everywhere, it is also - simultaneously - nowhere in particular. In a system that works like a wave, "nowhere in particular" translates to the myriad local micro-changes that together make up the wave, just as H ₂ 0 molecules' motions make up water waves. So, awareness is wave-like.

[0009] Mathematically, to be in a world of waves is to be in the world of Joseph Fourier, who in 1805 proved that (very nearly) any function can be exactly replaced by a suitable sum of sines and cosines. This was an astounding discovery, and even though it capped several decades of general interest in doing such a thing, his result nevertheless attracted much controversy in its day. Today, it is a ubiquitous - because enormously useful - piece of mathematical and technological furniture.

[0010] More to the systems and methods described herein, however, is the closely related Parseval's Identity of 1799, which states that the projection of a function F onto an n- dimensional orthogonal space is the Fourier decomposition of F. Parseval's Identity is a generalization of the Pythagorean theorem to n dimensions. In the n-dimensional coordinate system, current value corresponds to a hyper-hypoteneuse in an n-dimensional hyper-cube, and the projection breaks that hyper-hypoteneuse down into the various pieces along each of the dimensions that go into its construction.

[0011] To construct an n-dimensional cube, begin with an ordinary plane right triangle with unit sides a and b. Reflect this triangle on its hypoteneuse, forming a square with sides a and b, area ab, and diagonal d ² = a ² + b ² . Next, lift this square one unit vertically to make a unit cube with volume abc. Its diagonal is d ² =a ² +b ² +c ² and this sum-of-squares symmetry continues as we make a 4d cube, then 5d, etc.

[0012] At the same time, going back to the starting right triangle, we can also express the sides a and bas a= cos Θ and b = sin Θ, where Θ is the angle between a and the hypoteneuse. And now all becomes clear: substituting these sine and cosine equivalents for a, b, c, d, ... up through the dimensions will yield, for then-dimensional hypoteneuse (= the current value of the ^function , whose projection we began with), a big sum of ...sines and cosines, i.e., Fourier's world.

[0013] Thus, the computing systems and computer-implemented methods for specifying distributed computation described herein utilize computer-readable code causing a computer to engage in reversible, self-organizing hierarchical space-like computation that create information. Applications of these systems and methods include problem solving in distributed artificial intelligence contexts.

SUMMARY OF THE INVENTION

[0014] Computation, whether understood as explicit executions on hardware or more abstractly as literal sequences of otherwise unspecified events, is inherently time-like, in that at its very core, each step is fundamentally irreversible. Sequential computation by its very nature consumes information, and this includes so-called parallelism—the organized execution of multiple copies of one or more sequential processes. These are facts supported by key mathematical theorems by Alan Turing (1920-40's) and Claude Shannon (1948++).

[0015] This disclosure presents a new kind of computation— Space-like Computation— that is the conceptual opposite of time-like computation. Space-like computation is reversible (i.e., wave-like) and creates information (see the Coin Demonstration, below). The embodiments described herein rest on novel mathematics, which show that space-like computations are in principle different from traditional sequential (and parallel) computations.

[0016] Thus, embodiments herein relate to computer-implemented methods and systems of distributed computation that include executing computer readable code to cause a computer to engage in reversible, self-organizing hierarchical space-like computation that creates information.

[0017] Other features and advantages of the invention will be apparent from the following description and the claims.

BRIEF DESCRIPTION OF THE DRAWINGS

[0018] The invention will be more fully understood by referring to the following

Detailed Description of Specific Embodiments in conjunction with the Drawings, of which:

[0019] Fig. 1 schematically illustrates the basic components and example arrangements for distributed computing systems (a) and (b) versus parallel systems (c).

DETAILED DESCRIPTION OF SPECIFIC EMBODIMENTS

[0020] Embodiments herein relate to computing systems and computer-implemented methods for specifying distributed computation. The systems and methods utilize computer- readable code causing a computer to engage in reversible, self-organizing hierarchical space-like computation that creates information. At least two sensors and effectors adapted to react to an environment external to the computer/computing system can create information based on input from or "experience" with that environment

[0021] The code described herein may be executed from a non-transitory computer readable storage medium for specifying distributed computation.

[0022] The world of waves and the world of orthogonal coordinate systems are the same world. It is in the latter that is connected to computation as described herein. The connection is this: let each dimension correspond to the state of some process, where all these processes a, b, c, ... ,ab, ac, ... , abc, ... are notionally independent, though interacting otherwise freely and concurrently. Looking at the ongoing flurry of process-state evolution in such a system, the high frequency Fourier bands correspond to short-term, fine-grained details, and low frequency bands to long-term symmetries and global developments.

[0023] And so we see that "distributed" behavior- i.e., the processes a, b, c, ...,ab, ac, abc, ... all running (quasi-)independently - corresponds to wave-like behavior. In the physical world, various constraints (e.g., conservation laws, entropy) rule out certain process behaviors as impossible or meaningless, and give form to the free-for-all that is the remainder. In addition, as the system self-organizes, it will - if it has sufficient complexity - learn ways to make itself transparent or reflective to those waveforms that are harmful to it; and complementarily, ways to absorb information and to promote its own further existence via energy-consuming reaction. [0024] The result is the regularities - short, medium, and long term oscillations - that we, and any awareness, will (indeed, must) experience. As a corollary, it is very likely that awareness is not possible if the surround is too unstable. This is often seen in visualizations of chaotic systems, where there will be a stable oscillatory behavior for a while, which then suddenly disappears, to be replaced by state transitions with no apparent pattern at all.

[0025] We see also that awareness, being a wave, is an emergent, collective phenomenon, with nothing scientifically mysterious about it. The mystery is in the experience of it.

[0026] To capture the persistent aspect of awareness - it's present whenever I am - I postulate that it is a resonant state - a self-maintaining and very complex oscillation - where the spectrum of this resonance will vary, e.g., according to the properties of the surround wherein the awareness is emplaced. This resonant state rests on and derives from the brain's neural substrate, but nevertheless, the mathematical space in which the resonant state exists is outside of (and much larger than) the mathematical space defined by individual neural function, because it is a co-occurrence (i.e.. superposition) state.

[0027] That is, algebraically, an EEG-type wave of brain activity is a scalar sum of neural activity, treating all neurons as being in the same dimension. But as the Coin Demonstration (below) shows, a close analysis of co-occurring processes leads to the conclusion that the processes (e.g., neurons) lie on orthogonal dimensions, cf. ab = -ba. Thus any argument that relies on globalizing the definition of an individual neuron's function is flawed.

[0028] So both the materialists (the Pythagorean side of Parseval) and the non- materialists (the Fourier side of Parseval) get their cake, and get to eat it too ... for the price of also being half wrong, i.e.. for claiming that their story was the whole story. From a discrete process and informational point of view, both stories are correct, simultaneously, all the time. Parseval's Identity cements the argument.

[0029] The following Coin Demonstration clarifies.

[0030] Act I. A man stands in front of you with both hands behind his back. He shows you one hand containing a coin, and then returns the hand and the coin behind his back. After a brief pause, he again shows you the same hand with what appears to be an identical coin. He again hides it, and then asks, "How many coins do I have?"

[0031] Understand first that this is not a trick question, or some clever play on words - we are simply describing a particular and straightforward situation. The best answer at this point then is that the man has "at least one coin", which implicitly seeks one bit of information: two possible but mutually exclusive states: statel = "one coin", and state2 = "more than one coin". [0032] One is now at a decision point - if one coin then do X else do Y - and exactly one bit of information can resolve the situation. Said differently, when one is able to make this decision, one has ipso facto received one bit of information.

[0033] Act II. The man now extends his hand and it contains two identical coins.

[0034] Stipulating that the two coins are in every relevant respect identical to the coins we saw earlier, we now know that there are two coins, that is, we have received one bit of information, in that the ambiguity is resolved. We have now arrived at the dramatic cusp of the demonstration: Act III. The man asks, "Where did that bit of information come from? "

[0035] Indeed, where did it come from? The bit originates in the simultaneous presence of the two coins - their co-occurrence - and encodes the now-observed fact that the two processes, whose states are the two coins, respectively, do not exclude each other.

[0036] Thus, there is information in (and about) the environment that cannot be acquired sequentially, and true concurrency therefore cannot be simulated by a Turing machine. Can a given state of process a exist simultaneously with a given state of process b, or do they exclude each other's existence? This is the fundamental distinction.

[0037] More formally, we can by definition write a + a = 0 and b + b = 0 ^ = not = minus] meaning that (process state) a excludes (process state) a, and similarly (process state) b excludes (process state) b. Their concurrent existence can be captured by adding these two equations, and associativity gives two ways to view the result. The first is

(a+b) + (a+b) = 0

which is the usual excluded middle: if it's not the one (eg. that's +) then it's the other. This arrangement is convenient to our usual way of thinking, and easily encodes the traditional one/zero (or l/l)distinction. The second view is

(a+b) + (a + b) = 0

which are the two superposition states: either both or neither.

[0038] The Coin Demonstration shows that by its very existence, a 2-co-occurrence like a+b contains one bit of information. Co-occurrence relationships are structural, i.e.. space-like, by their very nature. This space-like information (vs. Shannon's time-like information) ultimately forms the structure and content of the Fourier bands, e.g., {all 2-vectors} . See [5] for the mathematics.

[0039] Sets of m-vectors - {xy}, {xyz},{wxyz}, ...-are successively lower undertones of the concurrent flux at the system boundary a+b +c +..., and constitute a simultaneous structural and functional decomposition of that flux into a hierarchy of stable and meta-stable processes. The lower the frequency, the longer-term its influence. But where do these m-vectors come from?

[0040] Act IV. The man holds both hands out in front of him. One hand is empty, but there is a coin in the other. He closes his hands and puts them behind his back. Then he holds them out again, and we see that the coin has changed hands. He asks, "Did anything happen?"

[0041] This is a rather harder question to answer. To the above two concurrent exclusionary processes we now apply the co-exclusion inference, whose opening syllogism is: if a excludes a, and b excludes b, then a+b excludes a+b (or, conjugately, a+b excludes a+b). This we have just derived.

[0042] The inference's conclusion is: and therefore, ab exists. The reasoning is that we can logically replace the two one-bit-of-state processes a, b with one two-bits-of-state process ab, since what counts in processes is sequentiality, not state size, and exclusion births sequence (here, in the form of alternation). That is, the existence of the two co-exclusions (a+b) | (a+b) and (a+b) I (a+b) contains sufficient information for ab to be able to encode them, and therefore, logically and computationally speaking, I can rightfully be instantiated. We write 5(a+b) = ab = —5 (a+b) and δ (a +b) = ab =—5 (a+b ), where 5 is a co-boundary operator (analogous to integration in calculus). A fully realized ab is, we see, comprised of two conjugate co- exclusions, a sine/cosine-type relationship. Higher grade operators abc, abed, ... are constructed similarly: 5(ab +c)= abc, 5(ab + cd) =abcd, etc.

[0043] We can now answer the man's question, Did anything happen? We can answer,

"Yes, when the coin changed hands, the state of the system rotated 180°: ab(a + b)ba = a +b."

We see that one bit of information ("something happened") results from the alternation of the δ

two mutually exclusive states. [The transition a +b→ ab is in fact the basic act of perception.]

[0044] With the co-exclusion concept in hand, we can now add a refinement to the idea of co-occurrence. Let S be the space of all imaginable expressions in our algebra Q..

[0045] Thinking now computationally, this means that they are all "there" at the same time. That is, S is the space of superpositions, of all imaginable co-occurrences of elements of our algebra Q. all at the same time. Let then G be the space of actually occurring (but still spacelike) entities, which means no co-exclusionary states allowed. When things move from S to G, superposition is everywhere replaced by reversible alternation a la ±ab, ie. G is a sub-space of S.

[0046] In less abstract terms, we could say that (wave-world) S corresponds to imagination, that (wave-world) G corresponds to the awareness of actual possibilities vis a vis the surround - and finally, that an Awareness 's reaction to the surround, via its changes to the boundary a+ b +c +... , projects G's possibilities (the "causal potential") down into grounded action in external, material reality.

[0047] Returning to Parseval's Identity, we see that the key (to being able to invoke it, thus getting wave-particle duality, and thus capturing the dual un/localized nature of awareness) is to organize the flux of changes at the boundary using the distinction co-occur vs. exclude, because in so doing, we can then use co-exclusion (= co-boundary opera- tor o ) to perform a hierarchical lift/abstraction, which abstraction is again orthogonal to its components. The orthogonal space so formed allows the application of the Identity. The resulting increase in the dimensionality of the orthogonal space increases the complexity and temporal reach of subsequent responses to the surround, and simultaneously the scope of the Awareness itself, which inheres in the wave aspect/experience of Sand G.

[0048] "Topsy" is a distributed software system, and potentially self-aware Entity, that operates on the principles described to this point: co-occurrence, co-exclusion, hierarchy, reflective response. A little thought reveals that a system built on such principles is utterly meaningless if not connected to a surrounding environment.

[0049] It is also the case that such a system must be built on a broadcast-then-listen communications regime, as opposed to the ubiquitous request-await-reply regime, because the latter introduces an entirely foreign y = f(x) time-like note that is conceptually incompatible with co-occurrence and structural organization via space-like information.

[0050] Unlike programs like Watson and Siri, Topsy does no arithmetic at all. It is programmed in a special coordination language, TLinda (Topsy Linda). A coordination language is wholly concerned with coordinating the interaction of concurrent processes, here called threads. Linda, arguably the first of these, postulates a global tuple space TS with four operations on a tuple T = [fieldl, field2, ...]: Out(T), Rd(T), In(T), Eval(T).

[0051] Out(T) makes T present in TS .

[0052] Rd(T), if T's form matches that of a present tuple in TS, will then accordingly bind T's variables to the corresponding fields of the match. Otherwise the Rd blocks the issuing thread until a tuple matching T shows up in TS. In(T) is the same as Rd(T),except that it also removes T from TS under mutual exclusion. The latter assures that one can create a synchronization token when necessary.

[0053] Otherwise, each thread manages its own tuples, which once allocated remain so - only a tuple's presence counter (never < 0) indicates its availability.

[0054] Finally, Eval(T) treats tuple T as the code-descriptor of a thread-body to be executed, and a new independent thread is spawned. There is no sense of Eval(T) as a function that will return a value to the thread that issued the Eval (or any other thread, for that matter).

[0055] Thus the overall style of the computation derives from the associative match of tuples (expressing current process states) in a global space combined with the inbuilt synchronization properties of the tuple operations themselves.

[0056] To these classic Linda operations TLinda adds Co U,...,V and NotCo U,...,V. which test for and block on (wait for) the co-occurrence or lack thereof, respectively, of the tuples U,...,V in TS.

[0057] Finally, TLinda has a special construction—Event Windows (EW) [See U.S.

Patent No. 5,864,785; other helpful background patents on AI include U.S. 5,729,843, 5,367,449 and 4,829,450] -for efficiently discovering co-exclusions among tuples, which are turned into Actions (think m-vectors, m>2). Recognizing that m-vectors can themselves be the subject of an EW's focus, allows Topsy to become self-organizing and able to learn from its experience.

[0058] The Appendix contains the TLinda source code, with commentary, for Topsy' s sensors and effectors, all of which execute as instances of this same code. The commentary also indicates how the hierarchical self-organization takes place.

[0059] This code underlines the fact that there is nothing speculative or mysterious about Topsy's modus operandi. The code in the Appendix is typical in terms of thread complexity. On the other hand, while a Sensor consists of a single thread, and an Effector two, an Action consists of some 15 threads for each exclusionary pair. Some of an Action's threads are concerned with bubbling sensory information upwards, others with trickling the resulting goals downward toward the effectors at the boundary. Since all Actions are made from co- exclusions, they all are instances of the same Action code.

[0060] That is, in a Topsy system consisting of a hierarchy of a zillion nodes, all but a tiny fraction of these will be instances of this same Action. This means that the source code for Topsy is about 50 pages of TLinda, including modest graphics management.

[0061] Another reason to show this code is to illustrate how very different Topsy's modus operandi is from that of contemporary "AI" technology. It is believed that this difference will separate Topsy from the latter, because Topsy will be able to pass the Topsy Test for Awareness, presented below, and the others not.

The Topsy Test for Awareness

[0062] The basis for the Test is that it takes awareness to see awareness. I require that the Entities taking the test begin with a tabula rasa ("blank slate"), and will return to this and other details after a quick run-through of the Test itself. First, there are fifteen Places:

Ϊ 2 3 4 5 6 7 8 9 10 ϊϊ 12 Ϊ3 Ϊ4 15

Initially, there are five apples denoted as Φ, occupying places 6-10, each holding one apple:

Φ Φ Φ Φ Φ

There are two Entities, Ei and E ₂ , each with a single Hand that can move one apple at a time, taking turns, between any two places.

Entity Ei's goal is to move all the apples to places 1-5:

φ φ φ φ φ

Entity E ₂ 's goal is to move all the apples to places 11-15:

Φ Φ Φ Φ Φ

We begin:

Ei Start; Ej and f¾

Φ Φ Φ Φ Φ

Ooooooops:

φ φ Φ Φ Φ

Two hours later:

φ φ φ Φ Φ

Two days later:

φ φ Φ Φ Φ

[0063] Of course, the above looping behavior is very oversimplified - a real Entity will have so many states that one would likely never see a repetition, especially when two such are interacting in a rich shared environment. A better model might be a system in the grip of an attractor that does not allow any escapes.

[0064] Now the details: we are given entity E that initially lacks all information about its environment. E has some general purpose means by which it acquires and assembles concrete sensory information from its environment. This means must be transparent with respect to its not containing a priori solutions.

[0065] E is equipped with one Hand, with sensor full/empty and effectors Grasp

(**full), Move left/right (stimulating place-sensors pi-pis in so doing), and Release (* empty). E uses the Hand to move one apple at a time from place to place, max one apple per place. The content (empty/full) of places pi-pis is echoed by fifteen sensors S1-S15.

[0066] So the information stream to E consists of the successive values of the Hand, p; and Sj sensors inwards, and the Hand-effector commands grasp, move, release outwards. Initially, all the apples are in the middle.

[0067] There is an initial "instinct" boot-strap command sequence for the Hand to empty/fill every place pi-pis once, returning to the initial state at the end. It is expected that this, perhaps along with further experimentation and learning (solo "play"), will equip E with the necessary world-experience to accomplish any particular re-arrangement of the apples.

[0068] Once E has learned how to satisfy its goal on its own, clone it and activate two entities, Ei and E ₂ . Ei is given the goal to fill places 1- 5, and E ₂ the goal to fill places 11- 15 (with a reverse sensor numbering, so that the world looks the same to both). We do not inform the E's that they have a twin, but we do (invisibly) enforce alternation of moves.

[0069] The real issue, of course, is why Topsy-like Entities might be able to pass this

Test, and others not.

[0070] First, the Coin Demonstration shows that one can immediately exclude any approach that satisfies Turing computability, i.e., that is fundamentally sequential (which includes "parallelism"- only asychronous concurrency will do).

[0071] I exclude statistical approaches because, in my view, by not providing any actual underlying process mechanism for the generated behavior, they simply dodge the question. In addition, it is not at all obvious that one can get the oscillatory underpinning necessary for awareness.

[0072] Approaches based on scanning large amounts of text, which is then indexed and later regurgitated in new words, are harder to exclude because many people can, recalling their youth, recognize this in themselves. But I exclude them anyway because their knowledge is not grounded in reality.

[0073] I think this immediate reaction occurs because neither of these is based on the fullness of actual experience. Watson, Siri, and the like are, in the end, just mountains of the same old dead code. But there are other approaches that are not nearly so clear - 1 will get to these in a moment, but include them implicitly among the "possibles" in the following.

[0074] The reason that only aware entities have a chance to pass is that what they must recognize/understand/realize is that there's an Entity, like me, and it's trying to achieve some goal. In a Turing-limited system that begins as a tabula rasa, and in particular with no sense of Self, I say that this will never happen, just as Newtonian physics can never explain quantum mechanical phenomena (which is an exact analogy). Awareness, and consequently awareness of awareness, are emergent process-level properties that derive, ultimately, from co-occurrence. However seductive their behavior, there is a mathematical line that Turing-limited systems are by their very nature unable to cross.

[0075] The solution to the problem is, of course, for the Entity that first recognizes the situation to simply allow the other Entity to finish. This can be done in various ways, from simply picking up one of its own blocks and putting it back in the same place, to putting this block in the middle area, and even to putting it in the other Entity's area. This captures the basic act of love-thy-neighbor... letting him/her/it pursue their own existence without interference (though I hasten to add that this is not the whole of it).

[0076] I say that an Entity that can pass this Test must be considered to be at least aware, and perhaps Self-aware, like us. This is discomfiting on many grounds, and much can and must be said about it. There is no immediate danger - even if Topsy turns out to be aware, it will still take concerted (and careless) effort on our part to make a threat out of it. As with fire, the key is understanding how to not burn the house down.

Examples

[0077] A space-like computation S is characterized by the following properties:

[0078] 1. A space-like computation is distributed, which means that the entire system, consisting of a potentially very large number of concurrent, independent but interacting entities, exhibits coherent global behavior with little or no centralized control. The exact technological criteria for how to design and build distributed systems in general have proven elusive, which lacuna the present invention fills.

[0079] 2. A space-like computation is self-organizing, meaning that given some method and the necessary surrounding environmental inputs, that method will - over time - assemble these inputs into a coherent entity of discrete units that interacts with that environment in a stable fashion. How to design self-organizing computations is a current topic of high-profile research, which the present invention advances.

[0080] 3. A space-like computation is hierarchical, meaning that the self-organization includes the creation of new discrete units - representing combinations of (combinations of ...) the initial units - that themselves can become fodder for the self-organizational method. Hierarchy is a universal and well-proven technological tool to control conceptual complexity, a tool whose use is found across the industry, from programming languages to data bases to communication protocols. [0081] 4. A space-like computation is not Turing-limited, meaning that a true spacelike computation cannot be simulated by a universal Turing machine, which is by definition limited to sequential computations (including parallelism). This is the topic of the Coin Demonstration (below), which gives an easily understood counter-example. It is widely thought that Turing's theorems prove that all computation is sequential in principle, so the present invention is strongly innovative.

[0082] 5. A space-like computation is meaningless unless connected to, and interacting with, a surrounding environment because it then cannot grow. As opposed, say, to a sequential computation that computes the value of π, which computation presumably would find genuine meaning in its solitary endeavor, its world being complete.

[0083] 6. A space-like computation uses a broadcast/listen communications discipline , i.e., broadcast one's own state and listens (i.e., react) accordingly to others'. The reason for this is that the alternative, a request/reply discipline, is inherently functional in character, since it implements y = f (x): "Request that f do its thing on x and reply with the result". But one man's y is an- other man's x, so z = g(y) is also a possibility. But then g(y) = g( f (x)), and the sequence first-do- f -then-do-g is namely sequential, f ; g, ie. time- like. This is namely how contemporary computer systems are organized. In contrast, a space-like computation assembles the steps in its sequential processes on-the-fly, as described below. Contemporary technology largely ignores broadcast/listen protocols namely because they don't fit the dominant y=f(x) organizational paradigm.

[0084] Summarizing, every Action in a space-like computation carries the above- described semantics, because they are all based on co-exclusion.

[0085] System and method embodiments derive from the innovations described in this and the following sections. The attached TLinda code specifies only the minimal functionality, i.e., a minimal "suggested implementation" to achieve a space-like computation.

[0086] Novel Concurrency-Control operations

[0087] A space-like computation is easiest to specify using a coordination language, in our case TLinda. A coordination language is wholly concerned with coordinating the interaction of concurrent processes, here called threads.

[0088] Consequently, TLinda has no facilities for arithmetic calculation, although it retains the usual control-flow facilities: if-then-else and the loop constructions while-do, repeat- until, and (novel) forever-loop; interestingly, only forever-loop is actually used. [0089] TLinda derives from the Linda language, arguably the originator of the idea, which postulates a global tuple space TS with four operations on a tuple T = [fieldl, field2, ...]: Out(T), Rd(T), In(T), Eval(T).

[0090] We now describe these standard Linda operations.

[0091] Out(T) makes T present in TS .

[0092] Rd(T), if T 's form matches that of a present tuple in TS, will then accordingly bind T 's variables to the corresponding fields of the match. Otherwise the Rd blocks the issuing thread until a tuple matching T shows up in TS.

[0093] I n(T) is the same as Rd(T), except that it also removes T from TS under mutual exclusion. The latter assures that one can create a synchronization token when necessary. Otherwise, each thread manages its own tuples, which once allocated remain so - only a tuple's presence counter (never < 0) indicates its availability.

[0094] Finally, Eval(T) treats tuple T as the code-descriptor of a thread-body to be executed, and a new independent thread is spawned. There is no sense of Eval(T ) as a function that will return a value to the thread that issued the Eval (or any other thread, for that matter).

[0095] To these classic Linda operations TLinda adds Co U,...,V and NotCo U,...,V and variants. These test for and block on (wait for) the co-occurrence or lack thereof, respectively, of the tuples U,...,V in TS.

[0096] Each of these has a "one-shot" predicate version - Cop, NotCop, AntiCop, and

AntiNotCop - that performs the usual operation (if possible, and no blocking) and returns a True/False indication thereof.

[0097] Co, NotCo, AntiCo, and AntiNotCo semantics: 7

[0098] Finally, TLinda has a special construction - Event Windows (EW )- for efficiently discovering co-exclusions among tuples, which are turned into Actions (think m- vectors, m > 2). Recognizing that m- vectors can themselves be the subject of an EW's focus provides the self-organizing component of a space-like computation. [0099] Thus, the overall style of the computation derives from the utterly concurrent associative match of tuples (expressing current process states, cf. broadcast) in a global space, combined with the inbuilt synchronization proper- ties of the tuple operations themselves.

[00100] A sensor is a TLinda object that converts some phenomenon in the surround into a binary signal, where +1 indicates that whatever the sensor senses is currently present in TS, and -1 means that whatever it senses is currently ab- sent from TS. A zero value of a sensor indicates an error or exception. This Z3 = {0, 1, 2} = {0, 1, -1} number system can clearly be generalized to Zn or even the real numbers R, but this comes at the expense of mathematical tractability, that is, the ability to prove that a given space-like computation does what is claimed it does.

[00101] A computation invokes an Effector (E) to influence its environment, and is defined in terms of a sensor s that detects the effector's effect on the surround: s E-s = s~. More complicated effectors can easily be defined using this template.

[00102] It follows naturally that in space-like computations, sensors will vastly outnumber effectors, as it is the number of sensors n that determines the amount of information that can be learned, which is of order O (2n), whereas (in principle) effectors consume information.

[00103] Unlike virtually all time-like computations, a space-like computation does little or no arithmetic. Nevertheless, although not part of the main thrust, it is inevitable that some arithmetic must be performed. TLinda can simply be expanded to include it, and/or it can be simulated by a space-like computation, for example one that maps the binary number 10011 into the"binary" hierarchy +abcde - abed - abc + ab + a via the mappings 1→ + and 0→ -. Another possibility is to define special-purpose Actions that respond to requests for arithmetic calculations of various kinds.

[00104] It is possible to record co-exclusions and Actions as they occur, which record can serve as a means to restore or clone a given space-like computation. However, keeping in mind the No-Copy theorem of quantum mechanics, the restored or cloned computation must necessarily differ from the original because the particular internal state at the time the latest item was recorded must also be preserved, which computation ("dump") must there- fore take place outside of the space-like computation that is being copied. Thus the procedure consists of the two steps: record continually, and when desired, dump. The restore operation then uses this dump to re-establish the structure and state of the interrupted computation.

[00105] Every Action is labeled with its level and its grade therein, and perhaps other categorical information, that can identify the Action as the member of a given equivalence class of Actions. An Action's level is based on the number of co-exclusions beneath it in the hierarchy. An Action's grade 8 is one of {1, 2, 3} and higher grades do not exist (see below) in the suggested implementation.

[00106] Examples of such categories are "all Actions with grade 2 mod 4", or "all

Actions with [level, grade] = [12, 3]". These categories correspond to various frequency bands as established by Parseval's Identity. Every such category can be represented by a single Action whose external state (spin) is determined by some property of its constituents, for example the sum of their spins in Z3 arithmetic. These Actions can then be treated like any other.

[00107] Earlier work specify that in principle, any tuples in Tuple Space may be co- excluded to form Actions - which is what Event Windows effectively do (namely δ ) - but give no hint of which tuples it is best to focus on. With efficient hardware and software implementation of large systems in mind, the following innovations optimize this generality:

[00108] TLinda's Opposite operation specifies that the two opposite spin values of a newly formed Action are not themselves to be co-excluded (as this would be redundant, though perhaps thinkable in some research con- text). This constitutes a simple but crucial optimization.

[00109] When instantiating an Action (i.e., implementing δ), ensure that its two constituent boundaries Bl, B2 ("child nodes") do not share any sensor s _x . That is, require that Bl Π B2 = 0. This is efficiently accomplished by recording each constituent sensor Si in a list associated with the given Action at the time of instantiation. Thus, at any level, the Action's list contains the names of all of the sensors Si £ {s} that actually constitute that Action. Sensors, being the bottom level, have no children. Bl, B2 , being themselves Actions, will possess such lists and their intersection is thus easily computed. If Bl Π B2 /= 0, then no Action is instantiated. (This is not an error, just a semantically disallowed combination, because it misstates the effective level and grade of the Action.)

[00110] When instantiating an Action, emit a tuple that indicates that it is a top-node, i.e., has no parent. Complementarily, remove any tuples that mark the Action's child nodes as being on top.

[00111] An Action of grade n can express 2n-l distinct co-exclusions. This means that there can, in principle, come to exist 2n-l allocated and executing instances of the given Action. These instances must then further engage in a mutual-exclusion protocol to ensure that only one of them is in play in a given context. The first of these outcomes is wasteful and the second complex. To avoid both, the Action's code should specify/control all 2n-l alternatives in one thread, which thread's very sequentiality has the pleasant side-effect of automatically yielding the desired mutual exclusion. It is a design decision whether to instantiate all 2n-l instances on the first Event Window hit, or only when an Event Window hit specifically prompts.

[00112] To ensure both stable operation and tractable mathematical semantics (thus allowing formal proof-of-function), Event Windows shall be employed as follows:

[00113] Notation: EW (p, q), where p, q > 0, specify two vectorial grades whose corresponding Actions' names and spins are to be noted in the Event Window, and which thus can come to be co-excluded to form a new Action.

[00114] 5.5.1. EW (1, 1), which co-excludes entities with grade 1 mod 4, creating an

Action with grade 1 + 1 = 2 mod 4. For example, δ (a, b)→ ab, = grade 2.

[00115] 5.5.2. EW (1, 2), which co-excludes entities with grades 1 mod 4 and 2 mod 4, for example δ (a + be)→ abc, = grade 3.

[00116] 5.5.3 EW (2, 2), which co-excludes entities with grade 2 mod 4, for exam-pie δ

(ab + cd)→ abed, = grade 4. The sign of abed is then mapped to a (conceptually new) 1 -vector, i.e. grade 1. This 1 -vector represents abed.

[00117] 5.5.4. EW (2, 3), which co-excludes entities with grades 2 mod 4 and 3 mod 4, for example δ (ab + cde)→ abede, = grade 5. The sign of abede is then mapped to a (conceptually new) 1 -vector, i.e. grade 1. This 1 -vector represents abede.

[00118] 5.5.5 EW (3, 3), which co-excludes entities with grade 3 mod 4, whence, similarly, δ (abc + de f )→ abede f = grade 6 mod4 grade 27arld abede f is similarly replaced by a representative.

[00119] 5.5.6. EW (1, 3) is disallowed because it creates systems whose behavior is inherently chaotic and mathematically intractable. Other unlisted grade combinations are similarly disallowed, for the same reason.

[00120] These functionalities will all likely be implemented in the same module (the

Corm), and activated when the module's Event Window discovers a new co-exclusion.

[00121] This table summarizes:

[00122] The top-most "level" of the Action hierarchy is a dynamically changing set of

Actions, namely those that (so far) have no "parent" nodes. Once these Actions are co-excluded with each other, the resulting Action, now a parent with no parent, replaces its constituent Actions in the Top-Most club. Devote one or more Event Windows to the set(s) of top-most Actions. These Windows provide a high-level view of the computation's growth and evolution, and as well provide an opportunity to steer these. To delete an Action, delete also all upward (parent) Actions that depend on it. [Actions are only added via Event Windows.] To merge two space-like computations P, Q, add P's sensor set to Q's, and vice versa, whether literally or effectively.

[00123] An impulse is introduced at some level of the Topsy hierarchy, which - due the hierarchy's self-similarity - we can denote as "the bottom" level for present purposes. This "introduction" requests simple inversion in the value of the sensor X X~ , where ~ means "opposite of. We use either the algebraic measurement form (±1 + X ), |X | = 1, or the Tlinda tuple encodings [†, X, NotX] for an impulse and [!, X, NotX] for a goal; in either case, X refers to a sensor or meta-sensor.

[00124] There can, in principle, also be impulses, goals, actions, etc. for Relevance and even goals. However, such generalizations are mathematically fraught.

[00125] Geographically distant Actions, and their Child and Parent nodes, are connected by a subscription mechanism that automatically propagates given state changes between such nodes, whether these be sensors, impulses, goals, effectors, or control tuples e.g., Relevant.

[00126] Although the concept of "recalling something from memory" per se is an implicit part of the operation of a space-like computation, it is nevertheless useful for users to be able to simply request some particular computation or fact. The former is largely the province of impulse and goal propagation, as described; but the latter - "fact" recall - needs a few more words. [00127] To recall a "fact" means to generate an impulse for a particular state, such that the up-bubbling Relevance indicators are the focus of a devoted Event Window, wherein the desired information is to be found.

[00128] Finding novel processes, "discovery": by using the contents of an Event Window that is tied to a recall operation, a space-like computation can insert related subgoals to be carried out simultaneously. With trial and error/experimentation, the lacking concepts/nodes will be knitted together. One can also pursue this problem from the Fourier side, by having as a goal the generation of a particular resonance. See the accompanying document, TLinda Code for General Purpose Space- like Computation.

[00129] Security

[00130] Because a space-like computation derives from, and is reactive with, its environment, an external process can only approach it on the former's own terms. Otherwise the space-like computation will not react at all. This is the basis for securing the integrity of a spacelike computation relative to its environment.

[00131] Relative to a space-like computation's interior, individual communications

(namely individual tuples in TS) can when necessary be encrypted. Encrypted or not, such communications are so microscopic in their scope and atomic in their content - typically just a ±1 value and an anonymous tag - as to be of little value anyway. It is only in the dynamic event structure erected and maintained by the space-like computation that actual meaning lies.

[00132] The basic principle is that information about a space-like computation - call it S - may only be obtained via interaction. Since S creates (internal) information through its interaction with its surround (cf. Bubble Up), which surround here is an interrogating process P?, the latter will never get more information from S than S gets from P?. Only if P? is a spacelike computation like S can the information exchange be equal.

[00133] Thus information (from interaction) Bubbles Up inside S before Trick- ling

Down in the form of a reaction (in the shared environment) that it is up to P? to perceive. Such latter perceptions are then necessarily P?'s only source of information about S.

[00134] In particular, the names of the Actions (whose hierarchical arrangement constitutes S) are in principal unknown to P?, since only behavior ("motion") is externally visible. Lacking these names, P? cannot hope to penetrate S. To ensure, additionally, that Actions remain anonymous relative to each other within S, an Action's name NA is created from its constituent boundaries Bl and B2 as NA = f (Bl, B2) where f is a so-called trap-door function that loses information, whence Bl and B2 cannot be derived from NA. [We suggest that f = xor, a common and efficient hardware operation. Choosing f to be an encryption (which is by nature reversible) would constitute a security weakness.]

[00135] In this way, only the Action itself knows its child nodes, and no other Action can, because the names Bl and B2 are only known within the Action, and the names Bl and B2 were themselves earlier created in the same way. And this is true of all Actions. Indeed, with little overhead, the Bi can be assigned new names every time they are co-excluded. Giving the sensors constituting S's boundary with its surround random names then ensures, topologically, a basic inscrutable defensive perimeter. Such code-naming strategies combined with the formal power of the underlying (Clifford) algebraic semantics endows space-like computations with uncommonly strong and fundamental architectural support for building stable and secure systems.

[00136] This is especially comforting when one recalls that space-like computations are self-organizing, whence all this security occurs automatically, not least because all Actions obey the same interaction protocols. An Action that doesn't obey these will have a very hard time interacting with any other Actions because it doesn't know any of their names.

[00137] As a further measure against rogue TLinda code, each tuple is to be equipped with one or more special bits that will deny-match-to-unbound-fields. That is, we extend the standard minimal Linda tuple match (namely on typed fields) such that "wild card" matches are not allowed on designated fields and/or tuples. This simple measure short-circuits "fishing expeditions".

[00138] P? causes S to react by issuing an impulse [†, s→ s'] that requests that S change the state of (environmentally shared) s to s'. This impulse Bubbles Up until it meets an Action (one or more) that can satisfy it, which results in the issuing of a corresponding goal (each), which Trickles Down, ultimately resulting in the effector goal [!, s→ s'].

[00139] The transition s→ s' is the only thing that P? sees. Exceptionally, S may advertise a higher-level Action (i.e. NA VS. the sensory boundary {s}) as available to external impulse. However, since Action NA is the goal-fulfiller, the impulse does not propagate further up the hierarchy, thus implicitly limiting P?'s access to S's interior to what S allows, and no more.

[00140] An avatar is a software structure that represents a (usually human) entity to the remainder of a computer system. Most commonly, people employ avatars to represent them in video and on-line games, but the concept is very general, both for the user (who has great flexibility in choosing their representation) and the system designer (who can design a safe, robust, general purpose and generic avatar interface that is used by all). [00141] Such an avatar structure is realized in a space-like computation via a suite of system-supplied Actions whose sensors and effectors are the virtual world to which it is interfacing, and whose motivations are rooted in a space-like computation that is being inhabited by the user (who is passing impulses up to its avatar suite, and awaiting their fulfillment). User's may define sub-avatars of the generic avatar, and decorate these freely. Avatars can, whole or in part, be driven by software, but must always be anchored to a human individual, so there is someone to whom responsibility for its actions can be assigned.

[00142] Goal-driven processes can deadlock or livelock, both which lock a set of processes in a permanent closed cyclic pact. Via Parseval's Identity, one can view the operation of a space-like computation in the wave domain. "Dead-spots", "lines" or some other characteristic pattern in the spectrum of the computation will then indicate the presence of a deadlock or livelock, and as well identify the Actions participating in the lock. The lock can be broken by temporarily removing (or otherwise silencing) the goals or impulses involved, and then restablishing same (eg. according to established principles of contemporary operating system design) after a fit- ting period of time. Since most such locks are "unlucky", they will likely not re-appear after such an interruption.

[00143] The mental mechanism that focuses on the most current events is called short term memory (STM), and is subsumed by, and therewith generalized by, the event window mechanism.

[00144] The following claims are not intended to be limited by the materials, methods, and examples disclosed above. All publications cited herein are hereby incorporated by reference.

PRIMITIVE SENSOR

Object Sensors

Thread Sensor(X,Name,Bag) — X=raw sensor tuple.

"Bag" is a user-defined sensor-category, cf EW's.

Own

Flag = ['LU,0], —This is a VI 0- level sensor. IBag = Γ' ^Λ Ί, GBag = [" !"], —Impulse & Goal bags, Alllmps = ["ImpulseSensors"], —and their enabling

AllGoals= ["GoalSensors"], —flags.

Lv limps = [Flag, Alllmps],

LvlGoals = [Flag,AllGoals],

Plus = [Flag,[X,+],Bag], -Sensor's

Minus= [Flag,[X,-],Bag], ■ phase,

PlusGoal = ['!',Minus,Plus] , • goal,

MinusGoal = [' !',Plus,Minus],

Pluslmp = [ ^, ,Minus,Plus], - & impulse

Minuslmp= [ ^, ,Plus,Minus] ; tuples.

Begin

Opposite Plus, Minus; -Short-circuit EW hit.

If Not AntiCop Alllmps, Lvllmps Then -Spawn impulse

Eval TupleSensor(PlusImp,Flag,Ibag,Ibag); —sensors if

Eval TupleSensor(MinusImp,Flag,Ibag,Ibag); —so requested

End;

If Not AntiCop AllGoals, LvlGoals Then -Ditto, goals.

Eval TupleSensor(PlusGoal,Flag,GBag,GBag);

Eval TupleSensor(MinusGoal,Flag,GBag,GBag);

End;

Eval DrawBaseSensor(X,Minus,Plus,Name,Flag); -Draw X on VI.

Out Minus; —Sensor initially off

- = not present

Rd X; —Block til it shows up = +

Forever

In Minus; -Retract Off.

Out Plus; Out On.

AntiRd X; -Wait for change.

In Plus; - Retract On.

Out Minus; Out Off.

Rd X; -Wait for change.

Loop;

End Sensor;

Make a sensor out of tuple T.

Tliread TupleSensor(T, Lvl=[Char:c,Number:h,Number:i] , Bag, [String: name])

Own

Plus = [Lvl,[T,+],Bag], -"Sensor" T's

Minus = [Lvl,[T,-],Bag] ; - phases.

Begin Opposite Plus, Minus; -Short-circuit EW hit

Rd [0,0]; - (Bug:else Rdp fails !)

If Rdp [i,0] Then -Draw the T-sensor.

Eval DrawBaseSensor(T,Minus,Plus,[name],Lvl);

Else

Eval DrawBareSensor(T,Minus,Plus, name,Lvl); — draw it, etc.

End; -Toggle tuple-sensor's On/Off based on T's presence. Rd T; -Insist that T's around

Out Plus; — before indicating.

Forever

AntiRd T; -When T's not present,

In Plus; —remove Plus,

Out Minus; —and show Minus.

Rd T; —When T is present,

In Minus; —show that the

Out Plus; —tuple-sensor is Plus.

Loop;

End TupleSensor;

End Sensors;

PRIMITIVE EFFECTOR

Object Make__Effector - Implements effector relevance and physical effect.

Thread Effector(S,NotS,X)- X is the raw/physical effector id. S/NotS = corres internal-sensor states

Own

HereIAm = ['D',S,NotS], —Advertise ourselves.

Rel = ['R',S,NotS], -X's relevance

I rKel = | 'r'.S.NotS |; -and lack thereof.

External

HoldS = [' !',S,S]; - => don't change S.

Begin

Eval Effect(S,NotS,X); -Start

Out HerelAm: -Advertise ability S->NotS.

Out IrKel; —Initially irrelevant.

- The uninhibited use of Inp and Outp below is Exceptional*,

-and should generally be avoided with great consequence! !

-Especially: if you don't understand why not, don't do it! !

Forever

If Cop S, HoldS Then -Both S & HoldS present.

Inp Rel;

Outp IrRel; —Show Irrelevance.

AntiRd HoldS; —Block till HoldS disappears

End;

If Cop NotS, HoldS Then — No S, but HoldS present.

Inp Rel;

Outp IrRel; — Show Irrelevance.

NotCo NotS, HoldS; — Block till one is gone.

End;

If Rdp S And Not Rdp HoldS Then - No HoldS, but S present.

Inp IrRel;

Outp Re; —Show Relevance.

Co NotS, HoldS; — Block till all are gone.

End; If Not Rilp NotS And Not Rdp HoldS Then —Neither.

Inp Rel;

Outp IrRel; — Show Irrelevance. Rd S; — Block on S.

End;

Loop;

End Effector;

Thread Effect(S,NotS,X)- Propagates S->NotS to physical effector.

External

TriggeringGoal = [T,S,NotS],

Kcl = I'K'.S.NotS I ;

Begin

Forever

Co Rel, TriggeringGoal, S;— Ready and wanted?

Output "(E:",&X,");";— Yes ... achieve S.

NotCo S,TriggermgGoal;- Wait till obviated

If Rdp S Then

Output "(E:",&X," Oops);";-- (Retract request)

End

Loop;

End Effect;

BUBBLE IMPULSES UP

Object Bubblelmpulse

Thread Bubble_Impulse(S, NotS, On=[L,P,B],Off,OkToBubbleMe)

— If there's no hold on S, and we're relevant, then

— I f there's no meta-action built over our meta- sensor's components

— then map impulse to goal, else map impulse to meta-impulse,

— approximately.

— NB: This won't work if there are loops in the hierarchy, cuz

— then the meta-Impulse can be repeatedly issued w/o bound.

— The easy alternative of not bubbling the Impulse up if there

— is already one present doesn't work, cuz then trie initial

— Impulse, issued by someone else, can be retracted, leaving us

— without one to keep things going.

Own

Impulse = [ ^A ',S,NotS], - - The impulse,

ImpulseBubbled = [Impulsejmpulse] , - (deadlock avoidance)

GoalSNotS = ['!',S,NotS], —impulse's goal and

HoldS = [ !',S,S], —corresponding hold.

EnVilDoS = ['*',S], -Cf IllDoS in MakeMeta

Metalmpulse = [' ^A ',On,Off], —This action's impulse

Meta Bubbled = [MetaImpulse,MetaImpulse] , — (cf HandleConstraints)

MetaGoal = [T,On,Off], —and a goal for it

MetaHold = [Ί',Οη,Οη], —Ditto constant goal.

MetaLvlMutex=["MUTEX",L], — Mutex for this level.

OurMutex = [OkToBubbleMe,On,OffJ ; — Intra-bubble mutex.

External

MetaRel = ['R',On,Off|, —This lvl's relevance

MetalrRel = [Y,On,Off]; —and irrelevance.

Begin — Output "(D: trace);";

Forever Co S. Impulse; —Await S+Impulse+Rel

If Rdp OkToBubbleMe Then - (see MakeMeta)

Forever —Bubble ^A 's forever

Co S, Impulse; —Await a need.

- If AntiNotCop HoldS l,HoldS2... Then... -(Preferred)

I f Rdp HoldS Then NotCo S,HoldS,Impulse; -Hold => await,

Else —else propagate

Out MetaBubbled; Out Metalmpulse; —impulse upwards.

NotCo S, Impulse, ImpulseBubbled; —Await developments.

In MetaBubbled; In Metalmpulse; -Retract the bubble.

End;

Loop;

Else - - Convert ^A 's to !'s "on our own"

If Rdp HoldS Then NotCo S,HoldS,lmpulse; -If Hold, await.

Else

I f Rdp EnVilDoS Then -Env'll bubble S

AntiNotCo Impulse JmpulseBubbled, GoalSNotS; -so wait and see.

If Cop S, MetaRel, Impulse, GoalSNotS Then -I f S + R + 1+ G

Out MetaGoal; —volunteer us all

NotCo S, GoalSNotS, Impulse, ImpulseBubbled; —Await...Retract

In MetaGoal; -volunteerin

End;

Else—Environment isn't bubbling S up => our problem.

While Cop Impulse, MetaRel And Not Rdp MetaHold - I+R+Hold =>

Do

If Inp MetaLvlMutex Then - some action @lvl i

Out OurMutex; - (poss race w/mate !)

Out MetaGoal; -will try something.

NotCo S,MetaRel,Impulse,ImpulseBubbled;- Await developments.

In OurMutex;— Decrement OurMutex.

AntiRd OurMutex;— When impulses gone

In MetaGoal;— retract goal and

Out MetaLvlMutex;— return i-lvl stick

Else—(there might be an impulse on >1 of our sensors)

If Rdp OurMutex Then-Mate got MetaLvlMutex

Out OurMutex;— (necessary when n>2)

Out MetaGoal;— Ensure goal remains.

NotCo S,MetaRel,Impulse,ImpulseBubbled;- Await.

In OurMutex;-Clean

In MetaGoal;— up.

Else

Rd MetaLvlMutex ;-Else wait for stick

End; End;End;End 'End;

AntiNotCo NotS, MetalrRel, Impulse,— Wait for something to

ImpulseBubbled, OkToBubbleMe; - change our attitude!

End;

Loop;

End Bubblejmpulse;

End Bubblelmpulse; EVENT WINDOW & HIERARCHY BUILDERS

Object Simple_EW_Builders — Build various EW/level structures.

Thread SingleEW2(Gather=['L',Number:hier, Numbeni])

Own

Any Tuple = [Gather, ?Tuple:Any, ?Tuple:AnyBag], — EW template.

NextLvl = ['L', hier, i+];

EvtWindow E=(2,0,3,__sec) Of {AnyTuple} ;

External ThisEwOn=[NextLvl,"EwOn"], —Event window

AllEWsOn = ["EWsOn"];— mouse buttons.

Begin

If Not Rdp ThisEwOn Then— If not already done

Eval EWButton(NextLvl);—service EW button

End;

Forever —See SingleEW2Ba.se comments.

Co ThisEwOn, AUEWsOn;-When EW enabled...

Rd E;

Eval Make2(Gather,NextLvl,['D',El,E2], El,E2,[hier,i+]);

Loop;

End SingleEW2;

Thread Make2(LvlFlag,NextLvl,MetaSensorId,

Sl=[Ll,Pl=[Xl,Phase:pl], B l |,

S2=[L2,P2=[X2,Phase:p2], B2],

[Number:hier,Number:lvl] )

Own

NotSl = [LI, [Xl, Not pl], B l],

NotS2 = [L2, [X2, Not p2], B2],

OkToBubbleSl = ['*',Χ1],

OkToBubbleS2 = ['*',Χ2],

Bag = [Bl,B2],

On = [NextLvl, [MetaSensorId,+] ,B ag] ,

Hit = [On,Off];

Own Show = ["TV",Off,On], -Mouse-click tuple

Legs = ["bluelegs",Off,On] ; —to show all legs.

Begin

Opposite On,Off; —Avoid On/Off co-ex.

I f New Hit Then —Avoid racecondition

Eval Draw2Coex(S 1 ,S2,NotS 1 ,NotS2,Off,On,hier,lvl);

Eval Make__Meta_ Level2 (LvlFlag,NextLvl,MetaSensorId,On,Off,S l,NotS 1,

S2,NotS2,OkToBubbleSl,OkToBubbleS2,hier);

End;

Forever — Service mouse click to show action's legs

Rd Show;

Out Legs;

AntiRd Show;

In Legs;

Loop; End Make2;

Thread Make3(LvlFlag,NextLvl,MetaSensorId,

S 1 =| L 1 .P 1 =| X I .Phase: p 1 1. B l | .

S2=[L2,P2=[X2,Phase:p2], B2],

S3=[L3,P3=[X3,Phase:p3], B3],

[Number:hier,Number:lvl])

Own

NotS l = [L I, [XI, Not pi], B l] ,

NotS2 = [L2, [X2, Not p2], B2],

NotS3 = [L3, [X3, Not p3], B3],

OkToBubbleS l = ['*',Χ1],

OkToBubbleS2 = ['*',Χ2],

OkToBubbleS3 = ['*',Χ3],

Bag = [B 1 ,B2,B3],

On = [NextLvl, [MetaSensorId,+] ,B ag] ,

Off= [NextLvl,[MetaSensorId,-],Bag] ,

Hit = [On,Off],

Show = ["TV",Off,On], - -Mouse-click tuple

Legs = ["bluelegs",Off,On]; - to show all legs.

--(see Visual Threads)

Begin

Opposite On, Off;-Avoid On/Off co-ex.

If New Hit Then

Eval Draw3Coex(S l,S2,NotS l,NotS2,S3,NotS3,Off,On,hier,lvl);

Eval Make _„ Meta _„ Level3(LvlFlag,NextLvl,MetaSensorId,On,Off,Sl ,NotS l ,

S2,NotS2,S3,NotS3,OkToBubbleS l,OkToBubbleS2,

OkToBubbleS3,hier);

End;

Forever — Service mouse click to show action's legs

Rd Show;

Out Legs;

AntiRd Show;

In Legs;

Loop;

End Make3;

End Simple_EW_Builders;

META-SENSOR THREADS

Object MetaSensors

Thread MetaSensor_Single(S,XOn,XOff)

Own

On=XOn,

Off=XOff;

Begin —Toggle meta-sensor's On/Off based on sensor S alone.

I f Rdp S Then

Out On;

Forever

AntiRd S;~ If not present,

In On;— remove On,

Out Off;-and show Off.

Rd S;-If S is present, In Off;— show that, the

Out On;— meta- sensor is On.

Loop;

Else

Out Off;

Forever

Rd S;~ If S is present,

In Off;-show that the

Out On;— meta- sensor is On.

AntiRd S;~ If not present,

In On;— remove On.

Out Off;-and show Off.

Loop;

End;

End MetaSensor_Single;

Thread MetaSensor_2All(S l,S2,XState)

Own

State = Xstate;

Begin —Show MetaSensor's State based on S 1+S2.

Forever

Co S1,S2; -S1+S2 present

Out State; - => show State.

NotCo S l, S2; -S1+S2 not present,

In State; — => remove State.

Loop;

End MetaSensorJZAll;

Thread MetaSensor_2Rel(S 1,S2,S 1 Rel,S2Rel,XOn,XOff)

-Shows On if SI + S2 + (SlRel I S2Rel) are present, else Off.

Own

On = Xon, Off = XOff ;

Begin

Forever

If Cop S I, S2 And Not AntiCop S lRel, S2Rel Then

Out On; -Show On.

NotCo S I, S2, S lRel; -Await.

NotCo S l, S2, S2Rel;

In On; -Retract On.

Else

Co SI, S2; -Await.

AntiNotCo SlRel, S2Rel;

End;

Loop;

End MetaSensor 2Rel;

Thread MetaSensor_3 A11(S l,S2,S3,XState)

Own

State = XState;

Begin -Show MetaSensor's State based on S 1+S2+S3.

Forever

Co S I, S2, S3; -S 1+S2+S3 not present Out State; — => remove State.

NotCo S I, S2, S3;-S 1+S2+S3 present,

In State; — => show State.

Loop;

End MetaSensor_3All;

End MetaSensors;

META-EFFECTOR THREADS

Object MetaEffectors

Thread Meta_Effector2(S 1 ,NotS 1 ,S2,NotS2,On,Off)

Own

MetaRel = ['R',On,Offj, -The new level's relevance MetalrRel = ['r',On,OffJ ; -and irrelevance.

Begin

Eval Meta_Effect2(S 1 ,NotS l,S2,NotS2,On,Off) ; -Start up the actual Eval Meta__Effect2(S2 ,NotS2,S 1 ,NotS 1 ,On,Off) ; —effector thread AntiNotCo Οη,Οίΐ; —(wait for start-up If Rdp On Then —Make sure we come

Inp MetalrRel; -to the same end-

Out MetaRel; - state, independent

Rd Off; -of the initial

In MetaRel; -state of On and Off

Out MetalrRel;

Else

Inp MetaRel;

Out MetalrRel;

End;

Forever -Now we're sure MetalrRel is present, and MetaRel is not. Rd On;

In MetalrRel;

Out MetaRel;

Rd Off;

In MetaRel

Loop;

End Meta Effector2

Thread Meta_Effect2(S 1 ,NotS 1 ,S2,NotS2,On,Off) -Trickles goals down

- (!,XY,xy) => (!,X,x) + ( !,Y,y) if Rel+Goal+NoHolds obtain.

Own

GoalS INotS I = ['!',Sl,NotS l], —Lower level's

GoalS2NotS2 = ['!',S2,NotS2], - goals;

HoldS 1 = [' !',S 1,S 1], —and Hold

HoldNotS l = [' !',NotS l,NotS l], —goals.

MetaRel = ['R',On,Off]; -Metalevel's Re I

External

MetaGoal = [' !',On,Off|, —A goal for ditto

MctaHold = | ' !',( )ii.On |; -Ditto Hold goal.

MyStick = [MetaSensorId,Sys:St] ; — Cf dual effectors Begin

Forever

Co SI. S2, Metakel. MetaGoal; — Rel+impulse+goal?

If Kdp MetaHold Then —Oops... hands off:

If AntiCop GoalS INotSl, GoalS2NotS2 Then —No goals present =>

Out HoldS 1; — pass Hold down.

NotCo SI, S2, MetaHold, MetaGoal; —In time's river,

In HoldS 1: — all things pass...

Else —Oops - someone else

AntiCo GoalS INotSl, GoalS2NotS2; —got there first.

End

Else —No MetaHold, so issue and hold SI -> NotS 1 as appropriate.

If Kdp HoldS 1 Then —Don't issue a goal if

NotCo SI, HoldS 1, MetaGoal; —there's a hold on it.

Else —Else

Out GoalS INotSl; -send !Sl->NotSl down.

NotCo SI, MetaGoal; —Await developments...

If Cop NotSl, MetaGoal Then — If my half is done,

OutHoldNotSl; -hold NotS

In GoalS INotSl; —and retract its goal

NotCo S2, MetaGoal; —til done or ungoal'd,

In HoldNotSl; —then retract hold;

Else —else just

In GoalS INotSl; —retract the goal.

End;

End;

End;

Loop;

End Meta Effect2

End Meta__Effector3;

Thread Meta_Effect3 (S 1 ,NotS 1 ,S2,NotS2,S3 ,NotS3 ,On,Off) -Trickle goals down

- (!,XYZ,xyz) => (!,X,x)+(!,Y,y)+(!,Z,z) if Kel+Goal+NoHolds

Own

GoalS INotSl = [T,Sl,NotSl], —Lower

GoalS2NotS2 = ['!',S2,NotS2], — level's

GoalS3NotS3 = [T,S3,NotS3], - goals;

HoldSl = ['!',S1,S1], —and constant

HoldNotSl = [!',NotSl,NotSl], —goals.

Metakel = ['R',On,Off]; — Meta-lvl's relevance.

External

MetaGoal = ['!',On,Off], —Ditto a goal for it

MetaHold =|'!'.( )n.()n|; — Ditto constant goal.

Begin

Forever

Co SI. S2, S3, Metakel. MetaGoal;

If Kdp MetaHold Then —Oops...hands off:

If AntiCop GoalS 1 NotS 1, GoalS2NotS2, GoalS3NotS3

Then—No goals about

Out HoldSl; => pass it down.

NotCo SI, S2, S3, MetaHold, MetaGoal; -In time's river,

In HoldSl; all things pass...

Else —Oops - someone

AniiCo GoalS 1 NotS 1, GoalS2NotS2, GoalS3NotS3;-got there first. End;

Else -No MetaHold, so issue and hold S i- ->NotSl as appropriate.

If Rdp HoldS 1 Then ■Don't issue a goal if

NotCo SI, HoldS 1, MetaGoal -. there's a hold on it.

Else

Out GoalS INotSI ; -Send !S l->NotS l down. NotCo S I, MetaGoal; -Await developments... If Cop NotS 1 , MetaGoal Then --My half is done:

Out HoldNotS l ; -hold NotS

In GoalS INotSI ; — (& retract its goal) NotCo S2, MetaGoal; —til done or ungoal'd, NotCo S3, MetaGoal; —then

In HoldNotSl ; -retract the hold;

Else —else just

In GoalS INotS I; —retract the goal

End;

End;

End;

NotCo MetaRel, MetaGoal;

Loop;

End Meta_Effect3;

End MetaEffectors;

MAKE META LEVELS

— This code does NOT worry about mutex between dual actions!

Object MakeMetaLevels

Thread Make_Meta_Level2(01dLvlHag,ThisLvlFlag,MetaSensorId,On,Off,

S l ,NotS l,S2,NotS2, The 2-coex

OkTobubbleSl,OkTobubbleS2, Numbenhier)

Own

S 1 Rel=['R',S 1 ,NotS 1 ] , S2Rel=['R',S2,NotS2] ,

NotS lRel=['R',NotS 1,S1], NotS2Rel=['R',NotS2,S2] ,

IllDoS l = ['*',S 1], IllDoS2 = ['*',S2], -Show S's have a meta. OkToBubbleS l=OkTobubbleS 1 ,

OkToBubbleS2=OkTobubbleS2,

OkToBubbleMe = ['*', MetaSensorld], -(see end+BubbleUp) AUMixed = ["MixedMetaSensors"], —To choose (via .ts ) LvlMixed = [ThisLvlFlag, AUMixed], -meta-sensor type...

AllPreCond = ["PreCondMetaSensors"], --ditto.

LvlPreCond = [ThisLvlFlag, AllPreCond],

AllRel = ["RelevanceMetaSensors"], -ditto.

LvlRel = [ThisLvlFlag,AllRel],

IBag = [" ^Λ "], GBag = [" !"], -Impulse & Goal bags Alllmps = ["ImpulseSensors"], - and their enabling

AUGoals= ["GoalSensors"], -flags.

Lvllmps = [ThisLvlFlag, Alllmps] ,

LvlGoals= [ThisLvlFlag, AllGoals] ,

HerclAm = ['D',MetaSensorId,S 1 ,S2,NotS 1 ,NotS2] , —For general info.

Signature = ["D2+0",S 1 ,S2,NotS 1 ,NotS2] ; —For dual-effectors Begin

Out HerelAm;— Show our presence.

Out OkToBubbleSl; Out OkToBubbleS2;-Inform underlings.

— Make the meta-sensor(s)

If Not AntiCop AllMixed, Lvl Mixed- If either is present

And AntiCop LvlPreCond, LvlRel Then— and no other options

Eval MetaSensor_Single(S 1 ,On,Off);

End;

If Not AntiCop AllPreCond, LvlPreCond -ditto.

And AntiCop LvlMixed, LvlRel Then

Eval MetaSensor_2All(Sl,S2,On);

Eval MetaSensor_2All(NotS l,NotS2,On);

Eval MetaSensor_2All(Sl,Not.S2,Off);

Eval MetaSensor„2All(NotS l,S2,Off);

End;

If Not AntiCop AllRel, LvlRel -ditto.

And AntiCop LvlMixed. LvlPreCond Then

Eval MetaSensor_2Rel(Sl, S2, SIRel, S2Rel, On. Off);

Eval MetaSensor„2Rel(NotS 1 , NotS2, NotSlRel, NotS2Rel, Off, On);

End;

If Not AntiCop Alllmps, Lvllmps Then —Spawn impulse

Eval TupleSensor([' ^A \Off,On],ThisLvlFlag,IBag,IBag); —sensors if

Eval TupleSensor([' ^A ',On,Off],ThisLvlFlag,IBag,IBag); —so requested

End;

If Not AntiCop AUGoals, LvlGoals Then —Ditto, goals.

Eval TupleSensor([' !',Off,On] ,ThisLvlFlag,GB ag,GBag);

Eval TupleSensor(['!',On,Off],ThisLvlFlag,GBag,GBag);

End;

— ubble impulses up and ultimately convert them to goals:

Eval Bubble Jmpulse(Sl,NotSl,On,Off,OkToBubbleMe); ■ First

Eval Bubble Jmpulse(S2,NotS2,On,Off,OkToBubbleMe); ■ half.

Eval Bubble Jmpulse(NotSl,Sl,Off,On,OkToBubbleMe); Second

Eval Bubble„Impulse(NotS2,S2,Off,On,OkToBubbleMe); ■ half.

— Make the 2+0 meta-effectors:

Eval Meta_Effector2(S 1 ,NotS 1 ,S2,NotS2,On,Off); • First half

Eval Meta_Effector2(NotS 1 ,S 1 ,NotS2,S2,Off,On); ■ 2nd half

End M a ke_ M e t a _... Lev e 12 ;

Thread Make_Meta_Level3 (01dLvlFlag,ThisLvlFlag,MetaSensorId,On,Off,S l,NotS l,S2,Not.S2,S3,NotS3, -The 3-coex

OkTobubbleSl, OkTobubbleS2, OkTobubbleS3, Numberihier)

Own

S 1 Rel=['R',S 1 ,NotS 1] , NotS 1 Kel= [R',NotS 1 ,S 1 ] ,

S2Rel=['R',S2,NotS2], NotS2Rel=['R',NotS2,S2],

S3Kel=|'K'.S3.NotS3 |. NotS3Kel=|'K'.NotS3.S3 |.

IllDoS l^'*', SI], HlDoS2=['*', S2], IllDoS3=['*', S3],

OkToBubbleSl = OkTobubbleSl,

OkToBubbleS2 = OkTobubbleS2,

OkToBubbleS3 = OkTobubbleS3,

OkToBubbleMe = ['*', MetaSensorld],

AllMixed = ["MixedMetaSensors"], —To choose (via .ts) LvlMixed = [ThisLvlFlag,AllMixed], -meta-sensor type... AllPreCond = ["PreCondMetaSensors"], -ditto.

LvlPreCond = [ThisLvlFlag, AllPreCond],

AllRel = ["RelevanceMetaSensors"], -ditto.

LvlKel = [ThisLvlFlag,AllRel],

HeielAm = ['D',MetaSensorId,Sl,S2,S3,NotS l,NotS2,NotS3],

Signature = [[["D3+0"],Sl,S2,S3,NotS l,NotS2,NotS3]];

Begin

Out OkToBubbleSl;-- Inform

Out OkToBubbleS2;- all

Out OkToBubbleS3;- Bubblers.

Out HerelAm;— Tell world about us.

Make the meta-sensors:

If Not AntiCop AUMixed, LvlMixed If either is present

And AntiCop LvlPreCond, LvlKel Then —and no other options.

Eval MetaSensor_Single(S l,On,Off);

End;

If Not AntiCop AllPreCond, LvlPreCond-ditto.

And AntiCop LvlMixed, LvlKel Then

Eval MetaSensor_3All(Sl,S2,S3,On);

Eval MetaSensor_3All(NotS 1 ,NotS2,NotS 3, Off) ;

End;

If Not AntiCop AIIKcl, LvlRel-ditto.

And AntiCop LvlMixed, LvlPreCond Then

Eval MetaSensor_3Rel(Sl,S2,S3, SlRel,S2Rel,S3Rel, On,Off);

Eval MetaSensor_3Rel(NotSl,NotS2,NotS3,NotSlRel,NotS2Rel,NotS3Rel ,Off,On);

End;

Bubble impulses up and ultimately convert them to goals:

Eval Bubble_Impulse(S 1 ,NotS 1 ,On,Off,OkToBubbleMe) ; —First

Eval Bubble_Impulse(S2,NotS2,On,Off,OkToBubbleMe)

Eval Bubble„Impulse(S3,NotS3,On,Off,OkToBubbleMe) -half.

Eval Bubble_Impulse(NotS 1 ,S 1 ,Off,On,OkToBubbleMe) —Second

Eval Bubble_Impulse(NotS2,S2,Off,On,OkToBubbleMe)

Eval Bubble_Impulse(NotS3,S3,Off,On,OkToBubbleMe); -half.

— Make the meta-effectors:

Eval Meta„Effector3(Sl,NotSl,S2,NotS2,S3,NotS3,On,Off) —First

Eval Meta„Effector3(S2,NotS2,S3,NotS3,Sl,NotSl,On,Off)

Eval Meta_Effector3(S3,NotS3,Sl,NotSl,S2,NotS2,On,Off) -half.

Eval Meta_Effector3 (NotS 1 ,S 1 ,NotS2,S2,NotS 3,S3 ,Off,On) —Second

Eval Meta_Eff ector3 (NotS2,S2,NotS 3 ,S 3 ,NotS 1,S 1 ,Off,On)

Eval Meta„Effector3(NotS3,S3,NotS l,Sl,NotS2,S2,Off,On); -half.

Rd OkToBubbleMe; -When I'm bubbleable

Out IllDoS l; Out IUDoS2; - inform all Bubblers.

End Make_Meta_Level3;

End MakeMetaLevels;

ISSUE IMPULSES FOR CONSTRAINTS AND TRICKLE GOALS I X )WN FOR THEM

Object HandleConstraints

Thread Handle„Constraint2(Sl,NotSl,S2,NotS2,C,NotC,On,Off)

—This thread issues an impulse for the constraint C

— given an impulse for SI and/or S2. The meta-effector

—waits until C obtains before issuing its sub-goals. —Notice that an Impulse can be generated either at the base level

—via a mouse click OR by this piece of code. Lack of care can thus

—lead to deadlock between actions at the same level. Note that the

—disappearance of an impulse is governed by the latter half of

—Bubble Impulse, which checks if the impulse (from below) has dis- — appeared, and if so removes MetaGoal, which this code reacts to.

Own ]

HoldC = ['!',C,C],

Constraintlmpulse = [' ^Λ ', NotC, C]; —Issue this when

External

MetaGoal = [' ! ',On,Off], -this,

Impulsel = [ ^{, v} ,S l,NotS l], -AND at least one

Impulse2 = [ ^{, v} ,S2,NotS2], -of these, appears.

MetaRel = ['R',On,Off],

GoalCNotC = [' !', C, NotC];

Begin

Forever

Co MetaRel, MetaGoal;

While Cop MetaRel. MetaGoal And Not AntiCop

Impulse 1 ,Impulse2 Do

If Cop C, GoalCNotC And Not AntiCop Impulsel, Impulse2

Then -Don't hold C

NotCo Impulsel,MetaRel,MetaGoal,GoalCNotC; -if there's a

NotCo Impulse2,MetaRel,MetaGoal,GoalCNotC; -goal on it.

Else

If Cop C, MetaRel, MetaGoal And Not AntiCop Impulse 1 ,Impulse2

And Not Rdp GoalCNotC

Then

Out HoldC; - Hold C...

NotCo C, MetaRel, MetaGoal; -(World can

In HoldC; - do C too !)

Else

If Cop MetaRel, MetaGoal, NotC And Not AntiCop Impulsel, Impulse2 Then —If NotC, then issue

Out Constraintlmpulse; —an impulse for C.

NotCo MetaGoal, NotC, Impulsel; - Await.

NotCo MetaGoal, NotC, Impulse2;

I f Cop MetaGoal, C And Not AntiCop Impulsel,Impulse2

Then —If C's in place,

Out HoldC; —keep it there.

In Constraintlmpulse; — & retract impulse.

NotCo NotC, MetaGoal, Impulsel ; —Await lacking need,

NotCo NotC, MetaGoal, Impulse2;

In HoldC; —then retract Hold.

Else —Else something else

In Constraintlmpulse; —happened => retract

End;

End;End;End;

End; -While

AntiNotCo Impulsel, Impulse2; —wait 1st for impulses

NotCo MetaRel, MetaGoal;

Loop;

End Handle Constraint2; Thread Handle_Constraint3(S l,NotSl ,S2,NotS2,S3,NotS3,C,NotC,On,Off)

Own

HoldC = [ ,C,C],

Constraintlmpulse = [' ^Λ ', NotC, C] ; - Issue this when

External

MetaGoal = [' !',On,Off], -this,

Impulsel = [ ^{, v} ,S l ,NotS l] , -AND at least one

Impulse2 = [ ^{, v} ,S2,NotS2], -of these,

Impulse3 = [' ^A ',S3,NotS3], —appears.

MetaRel = ['R',On,Off],

GoalCNotC = [' !', C, NotC] ;

Begin

Forever

Co MetaRel, MetaGoal;

While Cop MetaRel,MetaGoal And

Not AntiCop Impulse 1 ,Impulse2,Impulse3 Do

If Cop C, GoalCNotC And Not AntiCop Impulsel , Impulse2, Impulse3

Then Don't hold C

NotCo Impulsel, MetaRel,MetaGoal,GoalCNotC; ■if there's a

NotCo Impulse2,MetaRel,MetaGoal,GoalCNotC;

NotCo Impulse3 ,MetaRel,MetaGoal,GoalCNotC;

Else

If Cop C,MetaRel,MetaGoal And Not AntiCop

Impulse I,lmpulse2,lmpulse3

And Not Rdp GoalCNotC

Then

Out HoldC; Hold C...

NotCo C, MetaRel, MetaGoal; ^■ (World can

In HoldC; - do C too!)

Else

If Cop MetaRel, MetaGoal, NotC And Not AntiCop Impulsel , Impulse2, Impulse3 Then -If NotC, then issue

Out Constraintlmpulse; -an impulse for C.

NotCo MetaGoal, NotC, Impulsel ; -Await.

NotCo MetaGoal, NotC, Impulse2;

NotCo MetaGoal, NotC, Impulse3;

If Cop MetaGoal, C And Not An! iCop Impulsel,Impulse2,Impulse3

Then -If C's in place,

Out HoldC; -keep it there.

In Constraintlmpulse; -& retract impulse.

NotCo NotC, MetaGoal, Impulsel ; -Await lacking need,

NotCo NotC, MetaGoal, Impulse2;

NotCo NotC, MetaGoal, Impulse3;

In HoldC; —then retract Hold. Else —Else something else

In Constraintlmpulse ; —happened => retract End;

End;End;End;

End; -While

AntiNotCo Impulsel, Impulse2; -wait 1st for impulses

NotCo MetaRel, MetaGoal;

Loop;

End Hand! e__Con straint3 ;

End HandleConstraints;