andersw+ at pitt.edu (Anders N Weinstein) writes:
>In article <6hqseq$q8n at ux.cs.niu.edu>, Neil Rickert <rickert at cs.niu.edu> wrote:
>>When a computation is being carried out on my computer, a series of
>>causal operations is taking place, using electrical signals and other
>>kinds of physical operations. There is also a symbol manipulating
>>game used in our theories of computation to describe what is
>>happening. Whether we should say that the symbol manipulation game
>>is actually going on is itself a tricky question.
>If I were to produce a few quite concrete symbol tokens, say on punched
>cards, and move them around in accordance with certain pattern-governed
>transfomrations, I presume there would be no question that I was
>manipulating some symbols in the physical world. (Or would there? From
>what you say, I'm actually not sure what *you* think on this).
That's difficult. I think it depends on your intentions. You might
actually be moving the cards around for a completely different
purpose (practicing for a card trick, say), and it just happens by
coincidence that the movements are in accordance with these pattern
governed transformation. This is why I said it was a tricky
question. However, that was not the main point I was making.
>>When I am using the computer for ordinary things (like writing this
>>message), I care only about the causal operations. The particular
>>choice of symbol manipulation game which somebody might choose to in
>>their description language is completely irrelevant to the
>>computation that is going on, as far as I am concerned as a user of
>>the computer.
>Sure as an outside user you don't care, but if something goes wrong,
>it can make a difference whether we lay blame to faulty hardware or
>a bug in the programming. But identifying the latter requires
>identifying a "symbol manipulation game".
Okay. But when you identify it as a programming bug, you have
already chosen to go by the source program as a description of what
is happening. If you did not have that source code, it might be more
difficult. You might instead have specifications of what the program
is supposed to do, and then you might have a basis for saying there
is a programming bug because the system does not have the specified
causal behavior.
Here is a problem behind my arguments. There are all sorts of logic
gates in a digital computer. You could make the case that every
input to a logic gate is a concrete symbol within the computer.
However, when we describe the action of the computer in terms of a
computer program, we only account for a fraction of those logic
inputs. We disregard the rest as involved with internal control
functions (refreshing memory, for example) which are not directly
related to the computer program. Nevertheless, if those other logic
inputs are not properly handled, we get the wrong answer. If there
was a suspicion of a hardware bug, the engineer would have to be
concerned with all logic inputs, and not only the ones that the
computer program accounts for.
Now what if we took a completely different subset of the logic
inputs, and managed to design an algorithm which is properly
described by the particular logic inputs we have selected. Could the
computer be equally said to be running this alternative algorithm?
If so, then there is no fact of the matter as to which program is
being executed. However, if "computation" has to do with a series of
causal operations, rather than a symbol manipulation game, the same
problem would not arise.
