Brian Scurfield wrote:


Bruno recently urged me to read up on Tim Maudlin's movie-graph argument against the computational hypothesis. I did so. Here is my version of the argument. ............................

According to the computational hypothesis, consciousness supervenes on brain
activity and the important level of organization in the brain is its
computational structure. So the same consciousness can supervene on two
different physical systems provided that they support the same computational
structure. For example, we could replace every neuron in your brain with a
functionally equivalent silicon chip and you would not notice the
difference.


Computational structure is an abstract concept. The machine table of a
Turing Machine does not specify any physical requirements and different
physical implementations of the same machine may not be comparable in terms
of the amount of physical activity each must engage in. We might enquire:
what is the minimal amount of physical activity that can support a given
computation, and, in particular, consciousness?

Consider that we have a physical Turing Machine that instantiates the
phenomenal state of a conscious observer. To do this, it starts with a
prepared tape and runs through a sequence of state changes, writing symbols
to the tape, and moving the read-write as it does so. It engages in a lot of
physical activity. By assumption, the phenomenal state supervenes on this
physical computational activity. Each time we run the machine we will get
the same phenomenal state.


Let's try to minimise the amount of computational activity that the Turing
Machine must engage in. We note that many possible pathways through the
machine state table are not used in our particular computation because
certain counterfactuals are not true. For example, on the first step, the
machine might actually go from S_0 to S_8 because the data location on the
tape contained 0. Had the tape contained a 1, it might have gone to S_10,
but this doesn't obtain because the 1 was not actually present.

So let's unravel the actual computational path taken by the machine when it
starts with the prepared tape. Here are the actual machine states and tape
locations at each step:

        S_0   s_8   s_7   s_7   s_3   s_2 . . . s_1023
        t_0   t_1   t_2   t_1   t_2   t_3 . . . t_2032

Re-label these as follows:

        s_[0] s_[1] s_[2] s_[3] s_[4] s_[5] . . .s_[N]
        t_[0] t_[1] t_[2] t_[3] t_[4] t_[5] . . .t_[N]

Note that t_[1] and t_[3] are the same tape location, namely t_1. Similarly,
t_[2] and t_[4] are both tape location t_2. These tape locations are
"multiply-located".


The tape locations t_[0], t[1], t[2], ..., can be arranged in physical
sequence provided that a mechanism is provided to link the multiply-located
locations. Thus t[1] and t[3] might be joined by a circuit that turns both
on when a 1 is written and both off when a 0 is written. Now when the
machine runs, it has to take account of the remapped tape locations when
computing what state to go into next. Nevertheless, the net-effect of all
this is that it just runs from left to right.

If the machine just runs from left to right, why bother computing the state
changes? We could just arrange for each tape location to turn on (1 = on) or
off (0 = off) when the read/write head arrives. For example, if t_[2] would
have been turned on in the original computation, then there would be a local
mechanism that turns that location on when the read/write head arrives (note
that t_[4] would also turn on because it is linked to t_[2]). The state
S_[i] is then defined to occur when the machine is at tape location t_[i]
(this machine therefore undergoes as many state changes as the original
machine). Now we have a machine that just moves from left to right
triggering tape locations. To make it even simpler, the read/write head can
be replaced by a armature that moves from left to right triggering tape
locations. We have a very lazy machine! It's name is Olympia.

The main objection that comes to my mind is that in order to plan ahead of time what number should be in each tape location before the armature begins moving and flipping bits, you need to have already done the computation in the regular way--so Olympia is not really computing anything, it's basically just a playback device for showing us a *recording* of what happened during the original computation. I don't think Olympia contributes anything more to the measure of the observer-moment that was associated with the original computation, any more than playing a movie showing the workings of each neuron in my brain would contribute to the measure of the observer-moment associated with what my brain was doing during that time.



What, then, is the physical activity on which the phenomenal state supervenes? It cannot be in the activity of the armature moving from left to right. That doesn't seem to have the required complexity. Is it in the turning on and off of the tape locations as the armature moves? Again that does not seem to have the required degree of complexity.

It might be objected that in stripping out the computational pathway that we
did, we have neglected all the other pathways that could have been executed
but never in fact were. But what difference do these pathways make? We could
construct similar left-right machines for each of these pathways. These
machines would be triggered when a counterfactual occurs at a tape location.
The triggering mechanism is simple. If, say, t_[3] was originally on just
prior to the arrival of the read/write head but is now in fact off, then we
can freeze the original machine and arrange for another left-right machine
to start from that tape location. This triggering and freezing can be done
using a simple local mechanism at t_[3].

But this would still be just a playback device, it wouldn't have the same "causal structure" (although I don't know precisely how to define that term, so this is probably the weakest part of my argument) as the original computation. To build all these pathways, you could expose a given deterministic A.I. to all possible strings of sensory input of a certain finite length, record the results for each string, and construct an Olympia-type-playback device for each one. But although the original computations contributed to the measure of a huge number of observer-moments, playing back recordings of them would not, I think.


This actually brings up an interesting ethical problem. Suppose we put a deterministic A.I. in a simulated environment with a simulated puppet body whose motions are controlled by a string of numbers, and simulate what happens with every possible input string to the puppet body of a certain length. The vast majority of copies of the A.I. will observer the puppet body flailing around in a completely random way, of course. But once we have a database of what happened in the simulation with every possible input string, we could then create an interactive playback device where I put on a VR suit and my movements are translated into input strings for the puppet body, and then the device responds by playing back the next bit of the appropriate recording in its database. The question is, would it be morally wrong for me to make the puppet body torture the A.I. in the simulation? I'm really just playing back a recording of a simulation that already happened, so it seems like I'm not contributing anything to the meaure of painful observer-moments for the A.I., and of course the fraction of histories where the A.I. experienced the puppet body acting in a coherent manner would have been extremely small. I guess one answer to why it's still wrong, besides the fact that simulated torture might have a corrupting effect on my own mind, is that there's bound to be some fraction of worlds where I was tricked or deluded into believing the VR system was just playing back recordings from a preexisting database, when in reality I'm actually interacting with a computation being done in realtime, so if I engage in torture I am at least slightly contributing to the measure of observer-moments who are experiencing horrible pain.

Jesse




Reply via email to