From newshub.ccs.yorku.ca!ists!helios.physics.utoronto.ca!news-server.ecf!utgpu!cs.utexas.edu!qt.cs.utexas.edu!zaphod.mps.ohio-state.edu!ncar!noao!arizona!gudeman Tue Jan 28 12:17:34 EST 1992
Article 3133 of comp.ai.philosophy:
Path: newshub.ccs.yorku.ca!ists!helios.physics.utoronto.ca!news-server.ecf!utgpu!cs.utexas.edu!qt.cs.utexas.edu!zaphod.mps.ohio-state.edu!ncar!noao!arizona!gudeman
>From: gudeman@cs.arizona.edu (David Gudeman)
Newsgroups: comp.ai.philosophy
Subject: Re: Table-lookup Chinese speaker
Message-ID: <11869@optima.cs.arizona.edu>
Date: 24 Jan 92 22:59:27 GMT
Sender: news@cs.arizona.edu
Lines: 23

In article  <1992Jan24.182738.7804@spss.com> Mark Rosenfelder writes:
]In article <11828@optima.cs.arizona.edu> gudeman@cs.arizona.edu (David Gudeman) writes:
]>No it isn't a good point.  "Repeated runs" are not part of the
]>experiement.  If you want to experiment today and again tomorrow, then
]>you have to come back tomorrow and start at the point where the
]>conversation left off.  Even if that point is "good bye", it will
]>still have a history of what has happened before.
]
]This prohibition of repeated runs seems to have no motivation besides 
]to allow the table-lookup machine.  If I had an intelligent algorithm in
]hand, I'd have no objection to repeated runs, to running multiple instances
]of the program, etc.  

If you are going to model memory, then you need to save state.  It
doesn't matter whether the program is a direct table-lookup or a
rule-base simulation of a table lookup (read "algorithm").  If you
algorithm always starts out in the same state (no memory or the past),
what's to keep it from having the same problem as the table-lookup
program?
--
					David Gudeman
gudeman@cs.arizona.edu
noao!arizona!gudeman


