A process is a progressive course, a series of procedures. A procedure is replicable (if you understand it) in an algorithm; its parts have a chronological cause-and-effect relationship that can be anticipated. A procedure can be replicated with the appropriate combination of commands. In short, a procedure is deterministic and can be computerized within a given context.
Conversely, a process cannot be computerized, but, as we have said, it can be computer-aided. Particularly in the design process, respective events are not chronologically ordered. The following scenario, without the enrichment of graphics, intonations, bodily involvement, crudely illustrates an architect-machine dialogue:
Machine: George, what do you think about the children’s activities in this project? Architect: How far must a child walk to nursery school? Machine: The average distance is 310 feet. Architect: Each dwelling unit must have direct outdoor access and at least three hours of direct sunlight. Machine: Of the children we were just discussing, 92 percent must cross a road to get to school. Architect: We will look at that later. With respect to dwelling units, we must assume at least two vehicles per family. Machine: Your ozalids are ready. Your wife has just called.…
The example describes a participation where each party is interjecting and superpositioning events directed toward a common goal.
Each event is either a temporal or sequential occurrence; together they constitute part of a process. A sequential response of one protagonist is generated by the previous event in the dialogue, usually on the behalf of the other. A sequential event is a reply. It can be the reply to a facial expression or the answer to a question. What is important, however, is that not only is one actor responding but he can assume that the other is listening and probably is aware of the context. In other words, a sequential episode assumes the reply of one (intelligent) system and the attention of the other system—a chain of chronologically ordered incidents.
This well-known command-and-reply relationship between man and machine does not in itself constitute a dialogue, as it ignores all events except those ordered by time sequence. The Soviet Union’s A. P. Yershov (1965) has a diagram illustrating this proverbial man-machine interaction, as he calls it, “director-agent” interaction. Note that in the diagram, Professor Yershov has drawn three arrows within the man’s head and only one arrow within the machine. The three arrows imply an ever-continuing act particular to the role or constitution of the man and not the machine. Let us call this act deliberation.
The act of perpetual cogitation can be equally accorded to machines, especially since we have previously insisted on a dedicated small machine in residence, devoting its full computational ability full time. We will call machine deliberation “temporal” work. It resides in the background and surfaces as an interrupt. The interrupt (though not necessarily the deliberation) is context-dependent; thus we can probably assume that the temporal zone requires an intelligence. Furthermore, note that it is this zone of temporal events that the designer interrupts when presenting a fact or a task.
The Yershov diagram. This first appeared in a paper presented at a Seminar on Automation of the Thinking Process held at the Kiev Center for Scientific and Technical Information, Kiev, USSR, 1963.
Design History Chart (Myer and Krauss, 1967). The diagram represents a series of procedures rather than a process. The chronology of left to right, the two-dimensional apsects of the printed page, and the start/finish overtones all contradict the nature of the design process. If it were possible to diagram this process, then such diagramming would occur out of context, and present-day machines could handle it without an artificial intelligence. (Diagram courtesy of the M.I.T. Center for Building Research)
In the foregoing sketch, the machine addresses the architect, presumably interrupts him. Following, the architect addresses the machine (in fact interrupts) with a specific question that is not a reply but is within the same context. The machine’s reply is sequential: “… 310 feet.” While the architect thinks about the response, the machine further investigates the children-nursery relationship (we assume here a previous experience by the machine with such issues). Within three seconds of user deliberation, a machine could devote between three hundred thousand and three million operations to the children-nursery relationship.
Meanwhile, during the machine’s activities, the architect reinterrupts the machine and states criteria with reference to a new context: “Each dwelling unit must have direct outdoor access and at least three hours of direct sunlight.” After the machine has listened (and heard), it interrupts the architect and lets surface from the temporal zone the unsolicited information about children’s circulation. The architect postpones consideration of his oversight and proceeds to supply further design constraints.
Following, the machine interrupts again with a time-dependent occurrence.
It may now be more evident why an evolutionary machine must have the capacity for context recognition. A complete mishmash of irrelevant comments from a nonintelligent, nonevolutionary machine would confuse the designer and thus stifle the design process. While at the onset of any partnership the machine’s interruptions might appear random or disorderly, they would gain relevance through evolution. The sophistication of these temporal actions is essential for machines to mature into intelligent partners.
Creative Commons Attribution 4.0 International License (CC-BY 4.0)
