From newshub.ccs.yorku.ca!ists!helios.physics.utoronto.ca!news-server.ecf!news-server.csri.toronto.edu!rpi!usc!wupost!darwin.sura.net!Sirius.dfn.de!math.fu-berlin.de!uniol!unido!mcsun!uknet!edcastle!aiai!jeff Thu Jan 16 17:22:17 EST 1992
Article 2770 of comp.ai.philosophy:
Xref: newshub.ccs.yorku.ca comp.ai.philosophy:2770 sci.philosophy.tech:1868
Path: newshub.ccs.yorku.ca!ists!helios.physics.utoronto.ca!news-server.ecf!news-server.csri.toronto.edu!rpi!usc!wupost!darwin.sura.net!Sirius.dfn.de!math.fu-berlin.de!uniol!unido!mcsun!uknet!edcastle!aiai!jeff
>From: jeff@aiai.ed.ac.uk (Jeff Dalton)
Newsgroups: comp.ai.philosophy,sci.philosophy.tech
Subject: Re: Causes and Reasons
Message-ID: <5994@skye.ed.ac.uk>
Date: 15 Jan 92 21:28:30 GMT
References: <5943@skye.ed.ac.uk> <1992Jan12.211951.20547@bronze.ucs.indiana.edu> <5967@skye.ed.ac.uk> <1992Jan14.192736.24736@bronze.ucs.indiana.edu>
Reply-To: jeff@aiai.UUCP (Jeff Dalton)
Organization: AIAI, University of Edinburgh, Scotland
Lines: 85

In article <1992Jan14.192736.24736@bronze.ucs.indiana.edu> chalmers@bronze.ucs.indiana.edu (David Chalmers) writes:
>In article <5967@skye.ed.ac.uk> jeff@aiai.UUCP (Jeff Dalton) writes:
>
>>But I'm not sure what your sense of "implement" is.  I'm not
>>sure how it connects with actual practice at all.
>
>It seems straightforward enough that there is a sense of "implement"
>in which optimizing compilers do not strictly implement the original
>program, as the implemented mechanisms don't follow all the steps
>specified in the program.

But what, exactly, counts as a correct implementation in your
sense of the word?  Note that I don't have to rely on any steps
being eliminated, because there are still very different ways
to implement the program and because there is still no simple
correspondence between variables in the source code and machine
locations.  Just think of procedure calls, where different
variables correspond to different stack locations at different
times; or think of register allocation.

As an example of different ways to implement, consider that
a functional program might be translated into combinators (no
explicit variables left) and executed on a graph reduction
machine, or it might be executed by an interpreter written
in C and running on a Sun4.

Indeed, so far as I can tell you would say a compiler that
unrolls a loop or puts the test at the end and starts the
loop with a transfer to the end (which happens) isn't
"implementing" the program.

>                       I don't want to spell it out, because the
>details are complicated for variables, conditionals, data structures,
>loops, and so on; and furthermore the details of the story for e.g. C
>aren't necessary for my argument -- it goes through just as well
>for Turing Machines.

Do you think a C program and an equivalent TM specify the same
casusal structure, in some sense?  

In order to make it seem that a program specifies a causal
structure, you always turn to a much more direct specification
of a causal structure, namely the description of a machine.
Moreover, you talk about a pretty direct correspondence 
between machine states and brain states.  So the class of
physical causal structures that correspond to the machine
is kept fairly small.

So if description of the brain in terms of state transitions
works at all, it seems that there's going to be a machine
that rather directly has the same transitions.  So it may seem
plausible that all "implementations" of the machine have the
right physical structure.   

But programs map onto a much greater range of physical causal
structures, and so it's much harder to see how all implementations
will be right.

>>When considering equivalence of algorithms one commonly regards
>>the the relationship between the arguments and results of a procedure
>>(or function) as the "I/O behavior" that must be preserved.  But the
>>same sorts of optimizations can still be applied.
>
>There's far more to the equivalence of algorithms than just I/O
>behaviour!  Otherwise e.g. every sorting algorithm would be equivalent.

You're right, but they are all equivalent in a sense.  What I'd
like to know is exactly what sense of equivalent is needed for
your idea of implementation.  Requiring that implementations have
the same time complexity (ass be order n**2, for example) isn't
enough to, say, produce a direct correspondence between variables
and machine locations, nor does it prevent a wide range of loop
optimizations.

>(This suggests the thought of a very smart optimizing compiler that
>detects that a given procedure is performing bubblesort, and so
>produces quicksort in the compiled version.  I/O equivalent and very
>useful, but not strictly an implementation.)

As a somewhat related example, consider that a program is writen
in a programming language, and that different implementations of
the language might have different performance.  For example,
maybe there's a built-in sort procedure.

-- jeff


