>> I'm inclined to think that on a semantic level they should also use the same 
>> internal representation

Hmmm, the dictionary definition of semantic is "of, pertaining to, or arising 
from the different meanings of words or other symbols" -- which I take to be 
the *meaning* or *communication* level which certainly can be different from 
the *working* level.  How does what you're saying differ from what I'm saying?

>> Sure, for efficiency e.g. vision processing code might want to use vector of 
>> floats _implementation_, but that should be a compiler flag to be added 
>> after you've written and profiled a working prototype - the code should be 
>> written in terms of the logical representation.

Uh huh.  So your vision processing "code" is something like a description which 
then compiles down to the most efficient implementation.  Sounds to me like a 
descriptive communication level with a magical compiler that translates it to a 
machine-code internal representation.

>> I think if you start actually designing each module around a hand-tweaked 
>> internal representation, you'll end up spending your whole life on one 
>> narrow AI application

I think that if I convince someone/everybody else to throw a standard 
communication layer on top of *their* hand-tweaked internal representation, 
I'll do just fine, thank you very much.

>> The trick is to get to the next level of productivity, and I think using a 
>> consistent across-the-board logical representation 

Yes.  And I'm pushing for that at the *communication* level (where it clearly 
is possible) instead of at the *internal working* level (where I contend that 
it is clearly *not* possible -- or, at least, not feasible).

>> I'm skeptical, but it's hard to be sure of a "can't", so if you want to go 
>> that route - then go ahead and prove me wrong. 

Which is what I'm working towards.  But how are *you* progressing on converging 
on a canonical format?  Do you believe that logical representation is 
sufficient for describing vision processing well enough that a compiler can 
then create functioning vision code?
  ----- Original Message ----- 
  From: Russell Wallace 
  To: [email protected] 
  Sent: Tuesday, March 13, 2007 2:46 PM
  Subject: Re: [agi] Logical representation


  On 3/13/07, Mark Waser <[EMAIL PROTECTED]> wrote:

    Do the many modules have to have one canonical format for representing 
content -- or do they have to have one canonical format for *communicating* 
content?

    I think that you need to resign yourself to the fact that many of the 
modules are going to have *very* different internal representations.

  I'm inclined to think that on a semantic level they should also use the same 
internal representation. Sure, for efficiency e.g. vision processing code might 
want to use vector of floats _implementation_, but that should be a compiler 
flag to be added after you've written and profiled a working prototype - the 
code should be written in terms of the logical representation. I think if you 
start actually designing each module around a hand-tweaked internal 
representation, you'll end up spending your whole life on one narrow AI 
application. This isn't just theory - spending one's whole life on one narrow 
AI application is exactly what people currently do. The trick is to get to the 
next level of productivity, and I think using a consistent across-the-board 
logical representation is a key part of that. 



    The brain co-evolved with language.  I suspect that the easiest minimal 
canonical communicating format is going to be something pretty close to an even 
more rigorously syntactically defined Simple English ( 
http://en.wikipedia.org/wiki/Wikipedia:Simple_English_Wikipedia).

  I'm skeptical, but it's hard to be sure of a "can't", so if you want to go 
that route - then go ahead and prove me wrong. 



------------------------------------------------------------------------------
  This list is sponsored by AGIRI: http://www.agiri.org/email
  To unsubscribe or change your options, please go to:
  http://v2.listbox.com/member/?list_id=303 

-----
This list is sponsored by AGIRI: http://www.agiri.org/email
To unsubscribe or change your options, please go to:
http://v2.listbox.com/member/?list_id=303

Reply via email to