From newshub.ccs.yorku.ca!ists!helios.physics.utoronto.ca!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wupost!darwin.sura.net!europa.asd.contel.com!uunet!mcsun!uknet!edcastle!aiai!jeff Thu Jan 16 17:20:00 EST 1992
Article 2674 of comp.ai.philosophy:
Xref: newshub.ccs.yorku.ca comp.ai.philosophy:2674 sci.philosophy.tech:1826
Path: newshub.ccs.yorku.ca!ists!helios.physics.utoronto.ca!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wupost!darwin.sura.net!europa.asd.contel.com!uunet!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: <5967@skye.ed.ac.uk>
Date: 13 Jan 92 21:41:32 GMT
References: <5918@skye.ed.ac.uk> <1992Jan10.011118.26218@bronze.ucs.indiana.edu> <5943@skye.ed.ac.uk> <1992Jan12.211951.20547@bronze.ucs.indiana.edu>
Reply-To: jeff@aiai.UUCP (Jeff Dalton)
Organization: AIAI, University of Edinburgh, Scotland
Lines: 49

In article <1992Jan12.211951.20547@bronze.ucs.indiana.edu> chalmers@bronze.ucs.indiana.edu (David Chalmers) writes:
>In article <5943@skye.ed.ac.uk> jeff@aiai.UUCP (Jeff Dalton) writes:
>
>>This sounds plausible, but you still seem to be thinking of the
>>program as a fairly direct description of what will happen at the
>>hardware level on particular kinds of machines.  Your neural net
>>program could be transformed into a program with the same I/O
>>behavior but in which there wasn't a variable for the activation
>>of each unit.
>
>This seems to be the key point.  The notion of "implementing an
>algorithm" that I'm using is stronger than mere I/O equivalence, but
>rather puts certain restrictions on states and state-transitions --
>so that e.g. there should be identifiable physical states determining
>the value of a given variable, and so on.  So insofar as certain
>compilers are only concerned with preserving mere I/O equivalence,
>then they're not implementing the program in the sense that I'm using.

But I'm not sure what your sense of "implement" is.  I'm not
sure how it connects with actual practice at all.

>Otherwise you reach conclusions such as that one could implement an
>outputless 5000 line program statements with a trivial process that
>ignores the complexity of the original program; or one could implement
>a neural network with a lookup table.  I'm concerned here with Marr's
>algorithmic level, not his "computational" level (a terrible choice of
>word, incidentally).

Well, real compiers do in fact peform such "optimizations" as
eliminating code that doesn't have any effects outside of a loop.
That's one of the problems with benchmarks that loop 10,000 times
without doing anything.  There are even compilers that turn programs
that have no I/O into programs that don't do anything at all and
hence terminate almost immediately.  And all but the most trivial
compilers will do things with variables so that there is no simple
correspondence between, say, source code variables and memory
locations.  So conclusions such as the one you mention above are
not foreign to the actual practice of implementation.

>Incidentally I recall that there was a Ph.D. thesis that came out of
>Edinburgh a year or two ago on just this topic, giving a good account
>of implementation and algorithmic equivalence.

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 stil be applied.

-- jd


