Mark Waser wrote:
I am pretty confident that the specialized indices we use (implemented
directly in C++) are significantly faster than implementing comparable
indices in an enterprise DB would be.
I'm not sure what discussion of databases has anything to do with AGI.
The discussion started with a development environment to build AGI. One
of the salient points was that many teams have reinvented the wheel by
developing a custom "datastore" that has no necessary requirements that
couldn't have been fulfilled by a commercial off-the-shelf
relatively-cheap (and more important, standardized and more
feature-packed) product.
My point is emphatically not that *everything* should be done in
relational DBs (insulting that you would even think I was so foolish . .
. . :-) but that it is silly to re-invent the wheel and waste time (and
lose features) when you don't have to.
My original point is that you need an architecture where you can
*easily* integrate as much COTS and special-purpose code as possible.
The AGI community is in nine million separate silos with code that will
never interoperate. That's why we need a development environment that
will enable us to work together regardless of what our specialties (and
biases) are.
I am glad you got the discussion back to its roots, because I was about
to make a similar point.
What is needed in a development environment is a way to manage huge
amounts of knowledge in ways that can be used across large numbers of
different types of experimental runs.
The environment is supposed to allow people to explore vast numbers of
different architectures and algorithms (albeit within one general
conceptual framework), so what we need is:
(1) Generality - minimal commitment to particular ways of
representing the knowledge, but a flexible enough format to allow on
user to pour the data into many different architectural vessels.
(2) Common standards - a system that allows many different
experimenters, who focus on different AGI issues, to swap data AND
architectural designs quickly and easily.
From that point of view, it makes sense to go with a COTS database
standard.
Richard Loosemore.
-----
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
