From newshub.ccs.yorku.ca!ists!helios.physics.utoronto.ca!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!spool.mu.edu!yale.edu!qt.cs.utexas.edu!cs.utexas.edu!sol.acs.unt.edu!mips.mitek.com!spssig!markrose Tue Jan 28 12:17:36 EST 1992
Article 3135 of comp.ai.philosophy:
Path: newshub.ccs.yorku.ca!ists!helios.physics.utoronto.ca!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!spool.mu.edu!yale.edu!qt.cs.utexas.edu!cs.utexas.edu!sol.acs.unt.edu!mips.mitek.com!spssig!markrose

>From: markrose@spss.com (Mark Rosenfelder)
Newsgroups: comp.ai.philosophy
Subject: Re: Table-lookup Chinese speaker
Message-ID: <1992Jan25.010015.39312@spss.com>
Date: 25 Jan 92 01:00:15 GMT
References: <11869@optima.cs.arizona.edu>
Organization: SPSS, Inc.
Lines: 15
Nntp-Posting-Host: spssrs7.spss.com

In article <11869@optima.cs.arizona.edu> gudeman@cs.arizona.edu (David Gudeman) writes:
>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?

It's not so hard to get a program to vary in behavior between runs.
The programmer's problem is usually the opposite one-- getting the
damn thing to behave consistently.

Perhaps it's an aesthetic point.  Subtle variation in repetitions of the
same basic situation seems "lifelike" to me; precise recapitulation seems
"mechanical."


