Imagine the watershed for a river. Every drop of water that falls in that area, if it doesn’t evaporate or sink into the ground, eventually makes its way, through creeks, streams, and rivers, to the lake or ocean that is the shed’s final destination. The visual image is somewhat like the veins in a leaf. Or the branches of the leaf’s tree.
In all cases, there is a natural flow through channels sculpted over time by physical forces. Water always flows downhill, and it erodes what it flows past, so gravity, time, and the resistance of rock and dirt, sculpt the watershed.
The question is whether the water “computes.”
It can be viewed purely as a matter of definition. Very much like the noisy forest tree, it all depends on what you mean by “sound.”
Or by “computes.”
Computer science offers one definition, a rigorous one: A computation is anything that can be described by a Turing Machine (TM).
In order to call something a computation, there must be a TM that describes that computation. (Period.)
(The ringer in that list is the first term. It’s the only one people debate.)
I prefer the CS definition of computing because it removes a lot of ambiguity about what can (in the strictest sense) be said to be a computation. In particular, it removes debate over that first term.
It does beg for a word to mean what rivers do, or what orbiting things do, or even just what thrown balls do. Or airplane wings, or thermometers, or audio amplifiers,…
Unfortunately, “calculate” is just a synonym for “compute.” A word I like better is “evaluate” (but it doesn’t trip off the tongue well).
Physical systems evaluate the conditions of their environment and react in a directly causal proportional way.
Two key words there are direct and proportional.
There is a view that broadens the meaning of computation such that (what I’d call) evaluation is included.
On this account, depending on how broad the view is, various things that evaluate and react, or that process inputs into outputs, are computing and are thus computers.
So — by definition — planets compute their orbit, water computes its path to the sea, and a transistor radio computes music from radio waves. A slide rule is also a computer. So is an old-fashioned camera.
Therefore, a full-adder logic circuit computes its output.
If one takes a broader view of computation, that conclusion does follow.
If one takes the CS view of computation, it does not.
Simple as that! 😀
Today’s post goes over why CS says not, but ultimately, it comes down to one’s definition of computing.
I favor the CS definition because it removes ambiguity, but also because I see the broadening as begged by computationalism on the desire to see the brain as a “computer.”
(Because, if the brain is a computer, it shows computers can be conscious.)
I think computationalism can still approach consciousness by simulation, emulation, or replication. None of those require the brain be a computer. They just seek to model a physical system.
A conflict comes from the proposition that, if the mind can be run as an algorithm, it necessarily must be one already. Which suggests the brain has to be some kind of computer.
But the brain doesn’t look or work anything like a computer, so the definition must be broadened.
Definitions aside, I want to show you a few interesting things about modeling a full-adder with software.
I think the full-adder turns out to be an interesting example, because physical ones are a reification (an implementation) of an intentional abstract mathematical object.
Because the full-adder is a mathematical abstraction, there are two basic approaches: model the abstraction; model a simulation of a physical reality.
As the examples show, simulating physical reality is always more complicated than modeling an abstraction.
For a sense of what I mean, compare modeling the functionality of a simple four-function calculator to modeling a simulation of all its physical behavior.
The full-adder is easier to discuss, and has crucial differences that, under the CS definition, make the calculator definitely a computer while the full-adder definitely is not.
To understand why, we can look at a physical implementation:
Essentially, the circuit is a network of transistors (inside the logic gates), and current flows not terribly unlike water flows downhill. Whether it follows a given path depends on the physical forces in play.
(In a logic circuit, in some cases, beavers have built a dam across some paths and blocked the water. But sometimes water comes from another direction and knocks the dam away.)
Here’s another implementation of the same logic:
This circuit is interesting because it uses just one gate. It makes the idea of simulating it easier; we just need that gate.
Both logic circuits implement the logic table shown at top. That table is one way of expressing the full-adder abstract logic. Here’s another:
Those two logical expressions also express the full-adder abstraction. They are one way to generate the table. (The ⊕ symbol means XOR; the ∧ symbol means AND, and the ∨ symbol means OR.)
Logic Circuit #1 (above) directly reifies those two expressions. There is a one-to-one correspondence with the expression and the circuit.
Crucially, current flows like water through the gates (reacting to inputs), and the logical expressions have an immediate value (for any given inputs).
The truth table up top also shows that, for any given inputs, there is an immediate output.
No secondary calculations are required is the key point. The system reacts directly (and proportionally) to physical forces (in an analog way).
In a sense, “tugging” on an input physically causes an output to “wiggle.”
When it comes to modeling a mathematical abstraction, such as a full-adder, we can model the abstraction, or we can model a physical reification.
Generally speaking, a software model of an abstraction will be less complex than a software model of a physical system.
A key reason is that it’s usually easy to model the entire abstraction in a “perfect” way (that is, with full fidelity). With a physical model, we have to choose what level of the physics to model.
The lower the level, the more complex the system (usually), so the crucial trade-off is: How low do we have to go to faithfully emulate the system?
The full-adder is simple enough that we can have a reasonably simple software model for the logic gate circuits above. To replicate the properties of a full-adder, we don’t need to simulate the physics of the circuit so much as its logic.
To make this more concrete, I wrote three posts for my computing blog:
The first one features five different software models (code routines) of the full-adder abstraction.
The second and third each feature simple software models of physical full-adders, specifically Logic Circuits #1 and #2 (above).
Note that, because the physical instances reify an abstraction, their design severely constrains their operation. That’s why they operate in “digital” fashion.
This makes them much easier to model than a truly analog system! (In truth, the two examples really model the logic diagrams rather than physical circuits. Modeling the actual electronics is even more complicated.)
The main thing to notice is how short the examples in the first post are. These model the abstraction directly.
The first one uses a truth table and just looks up the answer. The second one implements the logical expressions at a code level. The third and fourth model the mathematics of adding bits.
The fifth one is a little unusual. It implements the state model of the full-adder. The state table makes it a bit bigger than the rest, but the code is still very simple.
Writing about the two gate simulations took a post each because, even modeling the relatively abstract gates, the model is more involved. For one thing, the network of gates has to be modeled in addition to the gates.
Further complicating things, there is a need to model the real-time flow of current (or abstract logic) and the gates evaluate their inputs.
On the CS view, a full-adder is not a computation, because, as an abstraction, it evaluates to an immediate answer, and, when reified, has analog physical flow characteristics, not computational ones.
But a calculator is, because there is no expression that evaluates to an immediate expression, because its operation requires steps, and because its operation requires a specifically designed structure (the algorithm).
The objection may be that the full-adder has a bunch of algorithms that implement it, so why isn’t it a computer?
One answer: Because its fundamental definition isn’t algorithmic.
Another answer: Being able to model something with an algorithm doesn’t make the thing being modeled algorithmic. (E.g. Weather.)
The real bottom line here is that:
- On the CS view, a full-adder isn’t a computer.
- The brain is very similar to a full-adder in operation.
Certainly much more similar than it is to a computer!
Stay computational, my friends!
 “If you build it, they will come.” There can be a kind of cargo cult thinking to the idea that a system that appears conscious will be conscious.
 As far as I know, there are no full-adders in nature. I’d love to know if I’m wrong about that. DNA, maybe? Quantum physics?)
 The expression for Logic Circuit #2 is, of course, much more complicated:
For the full expression, recursively expand the z, y, and x, terms in the bottom two expressions.
 Similar to how tweaking a sensor neuron in your toe physically causes a matching neuron in your brain to light up. There are no logical process steps occurring.
 (technically: saturated transistor fashion).