Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!dali.cs.montana.edu!milton!forbis
From: forbis@milton.u.washington.edu (Gary Forbis)
Newsgroups: comp.ai
Subject: Re: TM's (Was: Re: Searle and Radical Translation)
Message-ID: <6889@milton.u.washington.edu>
Date: 30 Aug 90 19:58:06 GMT
References: <628@ntpdvp1.UUCP>
Organization: University of Washington, Seattle
Lines: 43

I've been following this line for some time.  Ken Presting made me think
of an important difference between formal TMs and the day to day computation
machines actually do.

In article <628@ntpdvp1.UUCP> kenp@ntpdvp1.UUCP (Ken Presting) writes:
>> kohout@cme.nist.gov (Robert Kohout) writes:
>... The output of real computers is
>dependent on the past sequence of inputs, and this is exactly the
>phenomenon which concerns me. ...
>One reason that change in output over time is important is simply, learning.
>I do not see any hope of defining "learning" in terms of machines which
>always produce the same output from a given input.
>
>>If you are saying that a real machine can accept its inputs in little
>>chunks, while a TM requires its input up front I maintain that this adds
>>nothing to the computing ability of the machine. Obviously, one could take
>>the entire input over the life of a real machine and encode it in some
>>fashion that could suffice to be the single, "initial" input of a TM.

(I am sorry if any feel I have condenced too much.  I am trying to keep 
this article short and pnews requires and equal or greater amount of new 
text when compared to old text.  This lengthens what would otherwise be a
short reply to the context setting quoted material.)

There is more to real machines than accepting input and producing output.
In many cases there is a causal link between previous output and subsequent
input.  This is an additional reason that no real machine is equivalent to
a single TM whose input stream is predetermined.  If "the entire input over
the life of a real machine" were encoded "in some fashion that could suffice 
to be the single, 'initial' input of a TM" it would not represent the causal
link and as such would require some oracle to be defined.

An example.

A normal online application session involves separate create, inquiry, update,
and delete functions.  Unless the imput oracle knows the results of the create
prior to actually doing it it cannot encode input for update which relies upon
the output of the inquiry.  Now I could chop the input into little chunks for
each function but then carry some information as input to subsequent calls that
are not normally considered part of the input stream (the part Ken is calling
remembered.)

--gary forbis@milton.u.washington.edu