Digital Emulation

And the Digital Divide.

This is the third chapter in my story about how I became skeptical of computationalism. The first, Brains Are Nothing Like Computers, introduces the topic, defines some central terms, and meanders off into a couple of Rooms. The second, Brains Are Not Algorithmic, explores the Lucas-Penrose argument — turning on Gödel’s Incompleteness theorems — that whatever it is that brains do, it is not computational.¹ That post also touched on the Penrose-Hameroff proposal that brains leverage quantum effects, specifically in the microtubules of brain cells.

Now I want to start taking a closer look at computation, in particular with regard to simulations of physical things. Which might raise an immediate question; does that mean there are simulations of non-physical things? There are, indeed, and an example of one makes a good starting place for introducing both simulations and abstractions.

Simulating a Calculator

Consider a simple calculator, the kind they give away almost free, the kind that only adds, subtracts, multiplies, and divides.² We want to consider simulating such a calculator with a computer program. As we think about them, we see calculators have a dual aspect. Firstly, they are physical devices. They come in a variety of models with various types of buttons, displays, and electrical requirements.

But — and this is the key point — they all function the same way. No matter which calculator you use, 21 + 42 is always 63. The old-fashioned mechanical calculators, which worked according to mechanical principles, still performed the same math. When we do basic math by hand — adding, subtracting, multiplying, dividing — we are implementing the same abstract “program” a calculator does.³

The program in question is Basic Math 1.0™, and it has been around a very long time. There are updated versions, but the original still works as well as ever. Every simple calculator implements this program regardless of how the physical device accomplishes the implementation.

This is true because Basic Math 1.0™ is an ancient abstraction derived from our history of counting sheep, figuring wages, and slicing pizzas. We’ll see later that objects with a dual physical/abstract nature are special cases, but because it is true in this case, we have two distinct paths with regard to computer program simulating a calculator. We can choose to simulate the physical device — a specific physical instance of a calculator — or we can emulate its abstract function.

Writing a computer program to emulate Basic Math 1.0™ is so easy that it’s a common exercise for student programmers.⁴ Writing a computer program to simulate a physical calculator — with all the physics that entails — is an undertaking for a team of professionals. The takeaway here is the vast difference in size and complexity between the two.

Basic Math 1.0™ is a set of algorithms — little computer programs — and they are already abstract, so emulating them is almost trivial. Merely a matter of translating an algorithm for one system into a matching algorithm for another.

Another takeaway here is that, because calculators have an abstraction, emulating that with another abstraction (i.e. a computer program) is easy. There generally is no reason to simulate the physics of a specific calculator unless the point of the simulation indeed is the physical characteristics of a specific calculator (perhaps to determine the effects of various physical stresses).

In cases of dual aspect, though, it usually is the abstraction that’s of interest rather than a specific physical instance. Often a key characteristic of dual physical/abstract systems is that the system composition and details are irrelevant. Math is math regardless of whether done with scratch paper, an abacus, a calculator, or a computer.

Simulating a Tree

But suppose we wanted to simulate a tree. Trees have no inherent abstraction; they’re concrete physical objects doing the things trees do. There’s no algorithm we can replicate. The only choice available is to create our own numerical abstraction of tree function at whatever level needed to capture the tree dynamics of interest to us. We need to create a numerical model of a tree.

If for landscaping we only wanted to simulate growth and shade, we could use a simple model that embodies the growth rate and foliage density of the types of trees we thought of planting. But if we wanted to study how trees change internally during seasons, we’d want a much more detailed model — probably something at least at the cellular level.

The question with simulating physical objects is how detailed the simulation has to be to capture the object faithfully enough — where “faithfully enough” depends on the intent of the simulation.

Keep in mind that nature “computes” reality at the quantum level, and it’s possible that some systems require granularity that fine. In such case, no simulation with granularity larger than the quantum level can ever be completely accurate.⁵ Many believe plants leverage quantum effects in photosynthesis, so it’s possible the only completely accurate simulation of a tree is a quantum one.⁶

And if a completely accurate tree model requires quantum-level precision, what does that suggest about the brain? Are brains likely to be more or less complicated than trees?

Simulating a Brain

Strong computationalism asserts the brain is like a calculator. That there is a program the brain “runs” — mind.me™ — and it can be translated like any other code to run on any computer. This is emulation — functionalism at the level of mind. Such a program would deal with software and data objects like “hope”, “love”, “curiosity”, “anger”, and “impatience”.⁷

Weak computationalism asserts only that mind would emerge from a simulation of the physics of the brain. In principle, this is no different from simulating a heart or lung. The simulation concerns itself only with the physics of cells or biochemistry (or lower). This further divides into strong-weak, which asserts the simulation itself is conscious, and weak-weak, which asserts only that the program’s outputs will pass a Turing Test as if it were conscious.⁸

I think weak-weak has the greatest chance of success, and I’ll explore it more in the next post. I’m dubious about strong-weak (let alone strong) for reasons I’ll explore in the remainder of this post.

Digital Dualism

It isn’t always appreciated, but strong computationalism is inherently a dualist metaphysics.⁹ It assumes Mind is an abstraction distinct from the physical implementation that happens to be running it. That dualism is exactly what would allow mind.me™ to run on standard digital computers.

The Lucas-Penrose contention is that — whatever Mind it is — is not algorithmic, there is no algorithm for it. Their argument includes the limits Gödel’s theorems place on mathematical systems (which includes algorithms). They claim no computer can, even in principle, do certain tasks humans do with ease.¹⁰

Even if they’re right, this only rules out the stronger forms computationalism. I think a physics simulation of a human brain is different enough that this dualism may not apply.

The question of what the brain is instead of an algorithmic machine deserves its own post, but my short answer is that the brain is a massively parallel analog system. One might (somewhat poetically) compare the overall process to how rainfall and gravity etch a watershed into a landscape over time.

Our minds are landscapes etched by experience and acquired knowledge. Every “drop” that ever fell on us contributed in some small way to the composite whole of who we are.

The Digital Divide

I want to dig deeper into the divide that separates the abstract numerical world of software from the concrete physical world of the machine running the software. In particular, with regard to software implementing mind.me™.

If you’ve played computer games that simulate some sort of reality, you’ve probably experienced software bugs that allowed impossible things — people intersecting with tables or walls, for instance. These bugs happen because there is no physical reality to the simulation to prevent them. The code itself must carefully check to see if objects intersect.

Consider a simple example, a simulation that represents cubes. It can model a cube with two 3D coordinates of opposing corners. Suppose cube #1 is represented as the points (0,0,0) and (2,2,2). That means it extends on all three axes from (0,0,0) to (2,2,2). So, if cube #2 is represented as (1,1,1) to (3,3,3), it overlaps cube #1.

But the model just has four 3D points, and there is no innate restriction on them. Only by doing some math can we know the cubes intersect.

That was a simple example with a simple shape and only two of them. More realistic simulations can have hundreds or thousands of objects that potentially intersect, and those objects can have any shape. The computation for intersection gets complicated.

The key point is that virtual reality has no physics other than those implemented in the software. And as pointed out above, physics simulations aren’t trivial, either in their design or implementation. They tend to be big and complicated. And thus, hard to get right.¹¹

This means a virtual reality has no innate cause-and-effect relationships.

A second consideration involves the abstract nature of a numerical model. Above, cubes were represented only as the two (x,y,z) coordinates of opposing corners. More complicated shapes obviously require more numbers, and this requires a model — an abstract design specifying the kind of numbers and what they mean.

Note also that, if we meant to simulate real cubes with real physics behavior — including appearance — then we need a lot of numbers describing the cube’s mass, composition, and surface properties (texture, color, etc). The more accurately we want (or need) make our model, the more parameters it requires.

And these are all just numbers the software manipulates. Crucially, at this level — of data movement and binary math — the simulation of, say, Tetris looks very much like that of any other software. At the system level, it’s just 1s and 0s moving around and interacting logically with other 1s and 0s. If you sat inside the CPU watching, you would be hard-pressed to identify which program was running.

The key difference between a physical system and a numeric one lies in the difference between analog systems and digital ones. That’s where I’ll pick up next time.

Until then…

1. In the sense of computation defined by computer science under Church-Turing.

2. The kind found in those 1970s calculator watches.

3. Viewed at the functional level of “what something does”.

4. I just whipped one up in less than 30 minutes.

5. Recall from last time John Lucas’s conclusion, “…now we can see that no mechanical model will be completely adequate…”

6. Which implies a quantum supercomputer far beyond anything we have now.

7. Roughly a bit as depicted in Inside Out (2015).

8. And by many accounts, as if is good enough.

9. Ironically, most supporters of strong computationalism also favor physicalism.

10. So far it is true that computers do with ease things humans find hard, but humans do with ease things computers find hard.

11. Hence all the bugs in games and other software.