Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!leah!rpi!liszt.cs.rpi.edu!weltyc
From: weltyc@cs.rpi.edu (Christopher A. Welty)
Newsgroups: comp.ai
Subject: Re: Simulation and Understanding (was Re: Simulation verus reality)
Message-ID: <1274@rpi.edu>
Date: 14 Apr 89 17:29:52 GMT
References: <827@htsa.uucp> <5790@watdcsu.waterloo.edu> <5106@cs.Buffalo.EDU> <1259@rpi.edu> <5254@cs.Buffalo.EDU>
Sender: usenet@rpi.edu
Organization: RPI Computer Science Dept.
Lines: 42

In article <5254@cs.Buffalo.EDU> lammens@sunybcs.UUCP (Jo Lammens) writes:
>
>I would not want to imply that [simulation and understanding] are the
>same. But I do think that 
>in order to simulate, there has to be understanding. 

Perhaps.  I just wanted to make sure people weren't confusing the two.
I didn't say you could simulate without understanding, nor did I say
that understanding the low level is all you need for simulation.  I
also did not intend to open up the conenctionism debate (looks like I
didn't do much of what I intended).

How about this as an explanation of what I'm advocating:  For a
simulation to be exactly accurate, the simulation must be at all
levels.  If you want to simulate a computer you need to simulate each
level.  Just as you need to know how transistors go together to build
a computer chip, so you would need to know how the simulated
transistors go together to build a simulated computer chip, but you
can't just simulate the computer chip.  Of course, I'm not saying you
CAN'T get 90% of the functionality into a simulated system without
modelling the lower levels, and in fact the quite awesome comutational
expense of what I claim would be a complete simulation is probably not
worth that extra 10% in most cases (and the brain may even be one of
these cases, who needs computers that can suffer from amnesia, anyway?).

>>Typically `high level'
>>descriptions of functional groups of low level objects are mere
>>generalizations of the function of the group, and thus only
>>incorporate the default knowledge of that function.

By this I mean that abstractions typically leave out specifics in
favor of more general knowledge (defaults).  While these abstractions
may capture a large portion of knowledge (or functionality) of a
system, because they are abstractions there will be missing things.
You can always add missing things when you note they are missing, this is
not the same, as it requires someone to point out that something is
missing, and there may be a lot (perhaps infinite?) of these special
cases (exceptions) that exist (but only happen rarely).


Christopher Welty  ---  Asst. Director, RPI CS Labs | "Porsche:  Fahren in
weltyc@cs.rpi.edu             ...!njin!nyser!weltyc |  seiner schoensten Form"