From newshub.ccs.yorku.ca!ists!helios.physics.utoronto.ca!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!ucbvax!VNET.IBM.COM!kap Tue Apr  7 23:22:30 EDT 1992
Article 4742 of comp.ai.philosophy:
Path: newshub.ccs.yorku.ca!ists!helios.physics.utoronto.ca!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!ucbvax!VNET.IBM.COM!kap
>From: kap@VNET.IBM.COM (Kenneth A. Presting)
Newsgroups: comp.ai.philosophy
Subject: Re: A rock implements every FSA
Message-ID: <9203261657.AA12526@ucbvax.Berkeley.EDU>
Date: 26 Mar 92 16:46:24 GMT
References: <92Mar18.182726est.14357@neat.cs.toronto.edu> <1992Mar19.000544.22634@bronze.ucs.indiana.edu>
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: kap@vnet.ibm.com
Lines: 98

<92Mar23.003224est.14362@neat.cs.toronto.edu> <1992Mar24.025128.9379@bronze.ucs.indiana.edu>
            <92Mar25.053818est.14337@neat.cs.toronto.edu>

In <92Mar25.053818est.14337@neat.cs.toronto.edu> Calvin Bruce Ostrum writes:

>dc| However, one might get around this by adding the
>dc| constraint that the rock maintains a list of all inputs so far.  This
>dc| ensures that it will always be in a distinct physical state after any
>dc| sequence in L*.  Of course we would now be far from any ordinary "rock",
>dc| but there is a sense in which what we added is trivial, and we wouldn't
>dc| expect it to add amazing cognitive powers to a system, so that if
>dc| the result goes through with this extra constraint, functionalism may
>dc| may still be in trouble.  I'll come back to this.
>
>We are tempted to disallow this by saying that the rock required is too
>fantastic.  I left open whether or not such a rock was too fantastic by
>saying (although "commonly occuring natural conditions" is too strong, and
>Dave thinks "multiply implemented" is too weak):

This is not a problem.  Take a lump of clay as the "rock".  "Input" could
then be fine scratches on a flattend surface of the clay.  To return the
lump to the initial state, fold the input surface over on itself and
flatten the lump again.  (This is supposed to be the way the Babylonians
used cuneiform script for taking temporary notes)  Now the lump has an
internal "record" of everything that was ever written on it.

If you're willing to be more abstract in the kinds of things you allow
to be a "list of inputs", then you could consider any old rock, and let
scratches on it be the inputs.

Of course, no rock could implement this trick out to infinity, but
then neither could any person or any computer.

>
>cbo| What is not obvious (to me) is if
>cbo| there are any commonly occuring natural conditions under which there
>cbo| must be multiply implemented automata, such that many of these automata
>cbo| are not only non-isomorphic, but also not comparable under this
>cbo| "reducibility ordering".
>
>My feeling is that we still should be able to say something in this case,
>however.  There just seems something wrong with these ad hoc disjunctions,
>and we want to eliminate them while retaining the natural "multiple
>realisability" that led away from central-state identity theory in the
>first place. I have some extremely half-baked (and obvious) ideas about
>how this might be done.

I had a theory on this topic myself.  Does anybody out there remember
"Implementationism?"

>dc| (3) If implementation of an FSA A suffices for the possession of
>dc| certain cognitive properties, but A is an implementation of a
>dc| simpler FSA B that is behaviourally equivalent, then implementation
>dc| of B also suffices for possession of those cognitive properties.
>dc| [Irrelevance of implementational detail.]

If this principle is accepted, then the consequences could be very
adverse for functionalism.

Note that when physically implementing an abstract automaton, the
physical representation of input and output data formats is entirely
arbitrary.  Furthermore, the input representation is typically quite
different from the output representation (eg keystrokes vs. pixels).
With all this arbitrariness in the mappings, any rock with an adequate
number of distinct states would be behaviorally equivalent to any
automaton.  And it it not to difficult to (idealistically) conceive
of a rock with countably many states, or a continuum of states.

This objection is not meant to be a show-stopper.  It is just one
more detail that has to be ironed out in the concept of implementation.

> ...  Nevertheless, let us see if there
>is a way to tighten the definition of implementation so that we can cut
>out more implementations, being left with only the more complex "intended
>implementation".     ...
>take the defining table for the map-tester, and we make minimal changes
>in its entries, by introducing an "error" into the output function or the
>state transition function.  We now insist that the implementation supports
>counterfactuals such as "if this automaton had been this slightly
>different one, then it would act in this different manner", in addition
>to the ones we already require it to support. (I'll spare the formal
>details of how this would modify the definition of implementation).

These formal "details" may turn out to be much more challenging than
they first appear.

The theory of counterfactuals is very controversial; counter-identical
statements such as you propose are the among the most problematic
topics in the theory.  If Functionalism is to be saved only by appealing
to unspecified future developments in the theory of counterfactuals,
it may be a very long time before the functionalists can answer such
basic questions as "which objects instantiate automaton X?"

It was bad enough when Functionalism was the only game in town.  Now
we're supposed to stop playing Functionalism and play Counterfactuals
instead?   Yuck.  There has to be a better way.

Ken Presting  "Psst - wanna buy a hot concept?"


