The Deluge

we’ve installed the foundation piles and are ready to start building Mirror worlds. In this chapter we discuss (so to speak) the basement, in the next chapter we get to the attic, and the chapter after that fills in the middle region and glues the whole thing together. The basement we are about to describe is filled with lots of a certain kind of ensemble program. This kind of program, called a Trellis, makes the connection between external data and internal mirror-reality. The Trellis is, accordingly, a key player in the Mirror world cast. It’s also a good example of ensemble programming in general, and, I’ll argue, a highly significant gadget in itself. The hulking problem with which the Trellis does battle on the Mirror world’s behalf is a problem that the real world, too, will be confronting directly and in person very soon. Floods of data are pounding down all around us in torrents. How will we cope? what will we do with all this stuff? when the encroaching electronification of the world pushes the downpour rate higher by a thousand or a million times or more, what will we do then? Concretely: I’m talking about realtime data processing. The subject in this chapter is fresh data straight from the sensor. we’d like to analyze this fresh data in “realtime”—to achieve some understanding of data values as they emerge. Raw data pours into a Mirror world and gets refined by a data distillery in the basement. The processed, refined, one-hundredpercent pure stuff gets stored upstairs in the attic, where it ferments slowly into history. (In the next chapter we move upstairs.) Trellis programs are the topic here: how they are put together, how they work. But there’s an initial question that’s too important to ignore. we need to take a brief trip outside into the deluge, to establish what this stuff is and where it’s coming from. Data-gathering instruments are generally electronic. They are sensors in the field, dedicated to the non-stop, automatic gathering of measurements; or they are full-blown infomachines, waiting for people to sit down, log on and enter data by hand.

Building Mirror worlds

we’ve laid the foundations. Now we’ll build the building. But first, let’s take stock. A large bunch of software ideas have paraded gamely past the reviewing stand one-by-one, trumpets blaring; and by this point, it may no longer be easy to keep them all straight. So here is a quick summary. Garden-variety infomachines are (of course) a fact of life. Ensembles are also a fact: Programmers build and run them every day. Linda is a fact; its presence continues (at least for now) to expand, as a research topic and as a practical tool. The roping together of networked computers into a single “hypercomputer” is a new fact— esoteric stuff; but it’s such an obvious and compelling idea, and it’s working so well in practice, that it continues to come on strong. The world Tuplesphere is of course a non-fact. It’s a mere forecast. But—some sort of integrated worldwide communication scheme, based on persistent information objects, will eventually exist. That’s a forecast that is almost inevitable. The Trellis as a working ensemble is a fact. Substantial prototypes are up and running; they perform as advertised. The Trellis as a daily tool is a mere forecast. The Trellis is still a creature of the research lab; but it’s packed and ready to leave home. The FGP infomachine is a fact, too: Real prototypes are up and running. Like the Trellis, it’s still a laboratory creature. Like the Trellis, it will be ready to leave home soon. But the FGP infomachine that leaves home first will be a simple, in some ways primitive version of the system that further research will eventually produce. An FGP machine that can cope with “emotion,” with full-fledged pseudomemories or with human language is a mere forecast. Of course, we don’t need all this fancy stuff for a Mirror world. The FGP software that exists today isn’t far from meeting all of our immediate Mirror world needs. These are the Mirror world’s ingredients—Trellises and FGP machines; above all, ensembles, and the software technology to build them cleanly and support them efficiently. The raw materials are in place.

Simple Mind Machines

we plunge now into the deepest, trickiest, most treacherous and remarkable undersea cavern in the whole coral reef, the question of simulated experience. when we get to the bottom we will be face to face with the fundamental question of artificial intelligence (henceforth AI). we won’t know how to solve it, but we will be shining a flashlight in its face. what does it mean to think? How does thinking work? Not “how does the brain work,” but what does the thinking process consist of, in logical terms? we don’t need to understand lungs to realize that respiration has something to do with grabbing air, letting it soak in somehow and then pushing it out. Thinking is (one suspects) just as basic a physiological process as breathing; how does it work? Presumably it’s not mere random helter skelter scurrying about. There is some system at work, some process, presumably. Even when you are not hard at work solving a math problem, planning a strategy or wracking your brain for the name of someone’s daughter, there is something ticking over in there, as steadily (maybe even as rhythmically) as breathing. what is this process? As usual, we have a particular, concrete problem and a software solution in mind. The problem is crucial to Mirror worlds: How do we make the experience key work? In answering we will (again) be addressing a major problem in the non-Mirror world as well. In the last chapter, I discussed the extraction of information from fastflowing data streams at the source. we turn now to oceans of data that have accumulated in databases. what can we do with this stuff? All those multi-billions of records on file? Here, the focus is different. You don’t worry so much about extracting information fast, as the data values fly by. You focus instead on the problem of comparing many stored incidents or situations. In pursuing this concrete problem, I’ll keep the deep questions and long-term implications at bay, for the most part—but they do have a tendency to wind their tendrils around the subject matter in this chapter. I will be describing a “simulated mind” designed for a well-defined, utilitarian purpose.

Space, Time and Multi-time

we move now to the world of asynchronous ensembles. we’ve discussed information machines. Now imagine a lot of them zipping around separately, each piloted by its own Actor—communicating occasionally, getting born and self-destructing spontaneously—all converging like a swarm of space-scooters or electronic piranhas on some lurking huge problem in the near distance. Now this is computing! A group of objects that interact; a group, accordingly, that is more than the sum of its parts. If you assemble a hundred toasters side-by-side and turn each one loose on a slice of bread, what you’ve got is a hundred toasters, toasting their hearts out. If you assemble a hundred monkeys side by side, what you’ve got is not merely a hundred monkeys. You have a monkey community of some kind, an ensemble and not simply one hundred separate parts. Toasters don’t interact, but monkeys do. One hundred information machines working on the same problem also form an ensemble, an entity that is more, in some sense, than the sum of its parts. Like monkeys, these information machines interact. They must communicate and coordinate with each other in order to make progress as a group on the same problem. An ensemble is asynchronous if each part is independent, ticking along at its own pace. In the ensembles we’re talking about, each information machine is encased in its own little piece of spacetime. The machines are unsynchronized: No machine can predict exactly what any other machine is doing at any given time, because each Actor runs his own show, executes his own script. Nothing outside the machine beats time or constrains the Actor in any way: He barrels along at his own speed. Asynchronous ensembles (ensembles for short) are a major topic for software in general. They are the crucial Mirror world technology. Mirror worlds would be unthinkable without them. But here’s another interesting thing about ensembles: They are also the “crucial technology” of nature and mankind. That’s a biggish statement. But a bit of thought makes it clear that physical, chemical, biological and sociological systems are virtually all asynchronous ensembles of one kind or another.

Disembodied Machines

we begin with the central question. The answer forms the most important part of the Mirror world’s intellectual foundation. It also forms, for that matter, the most important part of computer science’s intellectual foundation; which makes it one of the central questions in modern engineering, and arguably the most important question in the history of technology. Despite which, it is a question that is rarely asked; and on rare occasions when it is, the answers you hear tend to be blatantly wrong. what is a program? what does “software” mean? Any technoglitz book that proposes to slobber on for hundreds of pages about software (there are plenty of them nowadays) should make you acutely uncomfortable unless it starts out by telling you what software is. And not many do. Because (or at least partially because) the answer isn’t simple. Or to put it another way, the answer is simple but it’s also subtle, because it requires that we give a name to something that (like adolescent female pigeons or the sky just as a cold front is arriving) we are accustomed to seeing but not to identifying. I’ve said that a computer program is a kind of machine, which is true. But it’s a funny kind of machine that must be defined with care, or we miss the whole point. I’ll define a program as an example of something I’ll call an “embodied machine”; this will place it roughly at the midpoint between a lathe and a symphony. I need to say, first, what a “machine” is in general. (Arguing about this definition used to be a fairly popular diversion. Machines are not the sexy proposition they once were...) Let us say, for present purposes, that a machine is a man-made structure that converts energy into value. This definition is vague on purpose, but it makes several points. A machine is man-made (a cloud doesn’t qualify), and it is a structure—an object that occupies space and time. (An idea doesn’t qualify). A machine is the meeting place between physics and society: It converts energy, which has a precise physical definition, into value, which doesn’t. Value is whatever you say it is.

The Orb

To use a Mirror world program, you sit down at your computer, which has a large color screen and a connection to the local fiberoptic utility cable. (The screen and the cable are garden-variety technology today.) Or—if you’re willing to put up with a smaller picture and it’s a nice day—you pick up your laptop, tune in Data Radio and head for the hammock. In either case, you flip channels until you find the Mirror world of your choice, and then you see a picture. Capturing the structure and present status of an entire company, university, hospital, city or whatever in a single (obviously elliptical, high-level) sketch is a hard but solvable research problem. The picture changes subtly as you watch, mirroring changes in the world outside. But for most purposes, you don’t merely sit and stare. You zoom in and poke around, like an explorer in a miniature sub. At every level the display is live: it changes as you watch. You move a viewing-frame around the picture with a mouse or equivalent, probably equipped with knobs for zooming. You meet your software agents and other Mirror world visitors along the way. when your agents have developments to report, or when you choose to ask questions or plant new agents, you pop into a sub-screen that displays ordinary text. You can enter a Mirror world through any household computer, but a few extra controls come in handy. Your basic Mirror world computer is equipped with a perspective shifter, a diving mouse, a “history” key (with a time-travel velocity knob right next to it), the all-important “experience” key, and finally an “agent” key. There is the ordinary keyboard besides. (I’m describing hardware gadgets that are similar to what you can buy today at the corner computer store. If you plan to do lots of Mirror worlding, you’ll invest in the Mirror world Value Pack, or whatever; the extra gadgets are tacked onto the computer in the same way your mouse is attached. The “viewpoint shifter” probably looks like a joystick; the diving mouse is the same as any other mouse, but equipped with an altitude-control knob.

Mirror worlds?

what are they? They are software models of some chunk of reality, some piece of the real world going on outside your window. Oceans of information pour endlessly into the model (through a vast maze of software pipes and hoses): so much information that the model can mimic the reality’s every move, moment-by-moment. A Mirror world is some huge institution’s moving, true-to-life mirror image trapped inside a computer—where you can see and grasp it whole. The thick, dense, busy sub-world that encompasses you is also, now, an object in your hands. A brand new equilibrium is born. Suppose you are sitting in a room somewhere in a city, and you catch yourself wondering—what’s going on out there? what’s happening? At this very instant, traffic on every street is moving or blocked, your local government is making brilliant decisions, public money is flowing out at a certain rate, the police are deployed in some pattern, there’s a fire here and there, the schools are staffed and attended in some way or other, oil and cauliflower are selling for whatever in local markets... This list could fill the rest of the book. Suppose you’d like to have some of this information. why? who are you to be so nosy? Let’s say you’re a commuter or an investment house or a school principle or a CEO or journalist or politician or policeman or even a mere, humble, tax-paying citizen. Let’s say you’re just curious. You want to browse, take in the big picture (it’s your city, isn’t it?)—form some impression of how well the whole thing is working. So you build a model. You lay out a detailed map on your living room floor. You add little model buildings and bridges and cars and policemen and so on, and lots of blackboards. On the blackboards you will record information that doesn’t correspond to any physical object—the state of the budget, the weather; thousands or maybe millions of other tidbits. The blackboards are scattered all over. Given the blackboards, you don’t really need the map, the buildings and so on—the city-in-miniature.