From newshub.ccs.yorku.ca!ists!helios.physics.utoronto.ca!news-server.ecf!utgpu!cs.utexas.edu!wupost!uunet!mcsun!uknet!edcastle!aiai!jeff Tue Mar 24 09:58:13 EST 1992
Article 4683 of comp.ai.philosophy:
Path: newshub.ccs.yorku.ca!ists!helios.physics.utoronto.ca!news-server.ecf!utgpu!cs.utexas.edu!wupost!uunet!mcsun!uknet!edcastle!aiai!jeff
>From: jeff@aiai.ed.ac.uk (Jeff Dalton)
Newsgroups: comp.ai.philosophy
Subject: Re: Intelligence Testing
Message-ID: <6478@skye.ed.ac.uk>
Date: 23 Mar 92 19:41:38 GMT
References: <1992Feb22.171652.5827@oracorp.com> <6255@skye.ed.ac.uk> <1992Feb27.230822.14739@ida.liu.se>
Sender: news@aiai.ed.ac.uk
Organization: AIAI, University of Edinburgh, Scotland
Lines: 72

In article <1992Feb27.230822.14739@ida.liu.se> c89ponga@odalix.ida.liu.se (Pontus Gagge) writes:
>jeff@aiai.ed.ac.uk (Jeff Dalton) writes (in response to daryl@oracorp.com):
>
>[Further table-lookup discussion omitted]
>
>>There's really nothing mysterious about this.  Suppose we had a 
>>C compiler that looked up the object code in a huge table.  Now
>>someone comes along and (without knowing how it works) asks
>>whether it's executing a graph-coloring register allocation
>>algorithm.  
>
>>I say: no it's just looking things up in a table.  The interesting
>>register allocation algorithm might have been involved in making the
>>table, but it's not doing anything like that now, when compiling the
>>program.
>
>>Then you come along and say: But wait!  The data is enormously
>>complex!  I believe this compiler is running register allocation
>>algorithms as complex as those in any compiler.
>
>>And then you say I have to convince you that nothing of the sort
>>is going on.
>
>>I must say I find that approach rather bizarre.
>
>This is yet another variation on the theme of "implementation".
>This table-lookup does implement the graph-colouring; however,
>it does so in an unusual manner. 

For one thing, I didn't say it did graph colouring or indeed any
other particular register allocation algorithm.  So you're quite
wrong to say it does graph colouring.  But ok, let's suppose graph
colouring was used to create the tables, and that non-memoized
colouring algorithm G was used for this purpose.  The table lookup
is not using G.

(BTW, I would apprectiate it if the pro-AI side would agree on a single
definition of "interpretation".)

Fortunately there are at least two senses in which the table lookup
is not doing G.

  1. It doesn't carry out any steps of the colouring algorithm.

  2. It has the time complexity of table lookup rather than that
     of graph colouring.

Moreover, all that's in the data is a table of inputs and outputs.

In effect, what I'm talking about is a fully "memoized" version of
graph colouring (or of compiling).  To say this is the same as
the original algorithm is just wrong.

>This has all been hashed out previously,

What is this?  The official bit of net.rhetoric for early '92?

What you mean is "something like this was discussed before and I think
my side won".

> but really, if you
>establish the table by using a graph-colouring algorithm; 
>then there is a bijection from the table entries to states
>of the algorithm. 

This sounds like the kind of thing that, if true, can be proved.
Would anyone like to try?  I think it's just false.  There are far
more states than table entries.  There's (at best) a bijection from
table entires to complete paths through the algorithm, not to all the
states on all the paths.

-- jd


