From: Ben Goertzel (firstname.lastname@example.org)
Date: Sun Jul 29 2001 - 23:56:37 MDT
> Ben Goertzel wrote:
> > From what I understand about Eli's approach, the problem of
> getting to phase
> > two modification isn't broken down into parts in the same way
> as I propose
> > to do.
> Actually, it pretty much is. The point where we disagree is about how
> hard it is to get to what you call "phase one". The reason why "phase
> one" takes Flare or something like it is that initially the AI will be
> extremely stupid and the alterations to the code will be more like
> mutations and less like general reasoning. General reasoning would work
> about equally well with Flare, C++, or assembly. The usefulness of
> relatively "stupid" action is *extremely* dependent on programming
> language. Thus, Flare is needed so that we can build a stupid AI.
This is a very good conversation. We are getting finally to the crux of
The role that you want Flare to play, in Webmind is played by "schema" --
our representation of procedures in terms of nodes and links.
Schema, in Webmind, are effectively programs, and the subset of KNOW used to
represent schema is effectively a programming language, although humans will
rarely write programs in it.
Essentially, in Webmind we are inserting an additional level into the
picture, as compared to your view of things.
Diagrammatically, the comparison goes like this:
WM core Computer OS
schema framework Flare
particular collection of schema AI program
The schema framework is designed to be learnable, designed so that WM
cognition can easily modify existing schema and learn new ones.
The step to phase 2 self-modification is the consideration of the WM core
itself as a big bad schema...
The schema framework is "annotative" and has all the other nice properties
you'd like Flare's internals to have, and more.
In effect, instead of making a new programming language running on the
standard OS, we're creating a new "virtual OS", the Webmind core, and then
making a new programming language (the schema framework) running on this
[Is it really a virtual OS? Sure. It does equivalent things to memory
management (loading and saving of nodes/links), scheduling of activities,
communication between processes, etc.)
Is it easier to make a virtual OS than to make a new programming language?
I think so. But I'm not 100% sure. Both are very hard. Our first attempt
to make the virtual OS fucked up -- it was elegant but not efficient enough,
because of Java's inefficient memory management and because of its
agent-system architecture. Our second attempt seems pretty damn good right
now, but it's the result of several years of learning on our part. It sure
didn't come easy.
We underestimated the difficult of the task of making this "virtual OS" work
with adequate efficiency for real AI, as opposed to just working for simple
example cases. If you indeed are underestimating the difficulty of the
task of making a robust, efficient Flare, then you are making an error very
closely parallel to the one we made. But even if you are making such an
underestimation error, I'm sure you can overcome it with a combination of
cleverness, inspiration and stubbornness, as are we.
All in all, I'm not sure that the Flare approach and the schema-learning
approach are conceptually that different. They seems to me to represent
different software-architectural approaches to the same high-level
-- Ben G
This archive was generated by hypermail 2.1.5 : Wed Jul 17 2013 - 04:00:37 MDT