This is the third of a series of posts about causal systems. In the first post I introduced five physical systems (personal communication, sound recording, light circuit, car engine, digital computer). In the second post I considered numerical representations of those systems — that is, implementing them as computer programs.
Now I’d like to explore further how we represent causality in numeric systems. I’ll return to the five numeric systems and end with a much simpler system I’ll examine in detail next time.
Simply put: How is physical causality implemented in virtual systems?
In a physical system, be it a tin can phone or a sophisticated computer, physical laws apply to how the system functions.
A chain of physical vibrations travels from vocal chord to eardrum in the former case. A mesh of voltages and transistor circuits interact in complex ways in the latter.
We create causality in physical systems by connecting the right parts together, be it cans and string or integrated circuits and wires. The system causality comes from how those parts behave individually and collectively.
Likewise, a virtual causal model also depends on the right parts, but these parts are virtual: math and logic. (Same thing, really; logic is a form of math.)
We’ve seen how the primary information of virtual systems consists of arbitrary numbers given meaning via an external map. In such systems, causality is also arbitrary and given meaning externally.
A key piece of advice for really seeing movies, TV shows, or graphic novels, is to always keep in mind that everything was put there deliberately (and therefore means something).
There are exceptions, especially in movies filmed outside with lots of people, or with shows that capture live events, but the visuals of most movies and TV shows are carefully planned. (CGI and action sequences are extremely well-planned.)
And certainly, in a graphic novel, every bit of visual art is drawn deliberately. (Very much like those well-planned movie scenes. Storyboards and graphic novels are very nearly the same thing.)
Often, a virtual reality is much like creating a CGI sequence. In fact, many CGI sequences are virtual realities created for a given scene or movie.
But there can also be virtual machines, devices or systems. A numerical simulation need not be of reality “as we know it.” That’s what I’ll look at first — the virtual devices that replaced our physical systems.
The key point here is that when you roll your own reality (with numbers), you have to do everything yourself. If it’s there, it’s because you put it there.
The text messaging system Alice and Bob use is a piece of software (an “app”) with a UI (a user interface) as well as an internet interface that lets it send and receive messages. The system likely has the notion of “conversations” with different “contacts” — those conversations consisting of a time-ordered sequence of messages.
The virtual reality is that of a text messaging machine. The application emulates how that machine would behave if it existed.
A physical machine would have a control panel of some kind; the virtual machine uses the cell phone’s physical display and inputs to emulate one. (With the wonderful advantage that virtual displays can be anything they need to be in the moment.)
In a physical machine, pressing a button closes contacts and causes a control signal that starts a chain of causal events implementing the action signified by the button press. The causal chain here resembles the tin can phones or light circuit — physical “pushes” that are the primary information content.
In a virtual machine, essentially the same thing happens, in this case using a chain of logic. The button may be a detected screen touch but has the same effect of starting a chain of events. In this case, however, the primary information is encoded numerically by the physical part of the system — the “pushes” aren’t directly connected with it.
Alice and Bob can also speak to each other by converting their voice to numbers, sending the numbers, and converting them back to voice on the other end.
The basic causal notions here are similar (especially if they have voice mail), but there are differences due to handling sound on the user side and the phone system on the network side.
Note this is causality at the application level — the overall behavior of the software system. Something like a [Delete] operation involves many causal steps arranged in a many-layered organizational hierarchy.
At the top, a single notion [Delete] caused by a single user gesture, but supported pyramid-fashion by layers of increasing detail. At the bottom are the actual code statements (variables, if-then-else statements, and loops) that do the step-by-step work of implementing the program’s casual design.
The second system, sound recording, is essentially just a much more sophisticated version of Alice and Bob talking digitally.
There’s a lot more attention paid to the quality of the sound as well as audio processing features, but the general principles remain the same. Sound is converted to numbers, which can be manipulated and stored, and later converted back to sound.
The causality of these systems is whatever the application designer put into them. A digital equalizer, for example, is designed as an emulation of an analog equalizer. This usually involves a UI — often one that looks like a hardware version might.
Where the hardware device uses the electrical behavior of physical circuits, the digital device manipulates numbers to accomplish the same effect.
For instance, a physical filter uses electrical resistance to different frequencies as the causality behind its function. A digital filter emulates that causality using calculations on the numbers representing sound based on a mathematical sound model.
An interesting aspect of this is that those calculations can perform manipulations on the sound difficult, or even impossible, to achieve with electrical circuits. It is possible to manipulate sound in ways that are non-causal in terms of the physical world!
The light circuit can only be simulated, not emulated. The bit of code in the previous post shows how the causality of a functional simulation might be written. Such a simulation is as simple as the circuit itself.
There is also the option of simulating the physical characteristics of the circuit. In this case the code must implement the causality of the applicable physics accurately enough for the results to match reality.
I didn’t mention simulating the physical systems in the cases of personal communication or sound recording, but the option does exist. We’d use such a simulation if we wanted to study the physical characteristics of a tin can phone or guitar amplifier. They’re much harder computationally, especially at lower levels of physics.
Usually we want to simulate the system at the highest level that accurately generates the outputs we need.
[One advantage expected from quantum computing is the ability to compute physical systems at their lowest levels. Quantum computers can potentially compute pieces of reality at the quantum level, just like reality Herself does.]
Even at higher levels, the difference is significant. Compare that small bit of code in the previous post to what it takes to simulate the circuit just at the electrical circuit level:
We have to model voltages pushing current through wires as well as the behavior of switches and light bulbs. The switch isn’t too bad, especially if we ignore issues about the physical contact surfaces, but the bulb requires we model wattage, current capacity, and maybe heat if it affects things. We also need some sense of “network” that lets us connect them in the right order.
The car engine also can only be simulated.
As with the light circuit, we can simulate the physics, in which case we need to write code that simulates the physical causality of car engines. You can imagine how complex and involved that could be.
A car engine involves a lot of physical forces and quite a bit of chemistry and fluid dynamics. It takes a team of real experts to write an accurate simulation for one.
A functional simulation could be a simple as a “black box” with an input of “throttle” and an output of RPMs. Or it could be as complicated as necessary to simulate the engine operational level of interest.
Either way, in all cases, like a carefully planned movie sequence, every aspect of the emulation or simulation is encoded by the program. Those aspects can attempt to match the physical world as closely as possible, or they can be anything desired for the virtual reality being created.
The computer is interesting because exact emulations are possible.
We do have the option of simulating the physics of a computer if we care about physical effects (like heating up). The same limits and difficulties apply as with any physical simulation — results depend on the accuracy and detail of the physics encoded in the software.
Computers also have a logical level — one of gates, counters, etc. Since these components are based on abstract numerical principles, we can perfectly emulate the function of the machine without regard to the physics of the hardware.
(See Full-Adder “Computing” for an example of both emulating and simulating a basic computer component.)
The logical causality of physical gates and other components comes from the electrical causality of the transistors that comprise their circuits.
That these circuits implement a logical causality makes them easy to emulate functionally. Computers are designed from numeric abstractions, which makes it easy to map them to another numeric abstraction.
[This can get interesting. Imagine writing an emulation of Computer A and writing it such that Computer A can run it (i.e. in a programming language Computer A understands).
If Computer A can run an emulation of itself, then the emulation can also run an emulation of Computer A. That emulation can run an emulation, and so on forever. Such a thing rapidly becomes impractical, of course, but is possible in principle.]
The details of implementing virtual machines, such as messaging, sound recording, or virtual computers, let alone physical simulations, are all deeply involved topics requiring academic study.
I could only give you rough sketches of most of them anyway (and that would take multiple posts), so I’ll stick with something simple — a (virtual) maze, such as one might encounter in a computer game.
That’s where I’ll pick up next time.
Stay virtually real, my friends!