Hi Mark,
Actually, we seriously considered using an enterprise DB for Novamente,
back when we were planning the original architecture. We decided not
to, for a number of particular technical reasons that it really isn't
appropriate or sensible to go into on this list.... But anyway, we did
not consider it a stupid idea a priori....
If there were a graph DB with the quality and flexibility of, say, an
Oracle relational DB, we might well have wound up using it instead of
brewing our own. But there wasn't when we started the NM project, and
there still isn't.
We also looked at object databases...
-- Ben
Mark Waser wrote:
I think you're exaggerating the issue. Porting the NM code from
32->64 bit was a pain but not a huge deal, certainly a trivial % of
the total work done on the project.
A man-month is a healthy chunk of time/effort (in a field that is
starved for it); however, if it were the only instance, I would agree
with you. Yet, then you turn around and also acknowledge . . . .
the advantage of an enterprise DB would be that you'd avoid some of
the work involved in making NM a distributed system --- work we know
how to do, but haven't done yet, because it's time-consuming...
and I think that there are a whole bunch more of similar cases that
add up and add up and add up. Did you have to write code to load and
save from memory to disk (both for swapping and semi-permanent
purposes)? Are you confident that you know and have all the tricks
necessary to scale up that enterprise Dabs already have (effectively
for free to you)? And what about concurrency? Is your architecture
designed *from the ground up* to allow controlled parallel,
simultaneous operation?
I want to repeat that I think that y'all have done amazing work. I
just think that you've missed out on some opportunities to focus even
more on what matters instead of re-inventing some wheels.
----- Original Message ----- From: "Ben Goertzel" <[EMAIL PROTECTED]>
To: <agi@v2.listbox.com>
Sent: Tuesday, February 20, 2007 6:34 PM
Subject: **SPAM** Re: **SPAM** Re: [agi] Development Environments for
AI (a few non-religious comments!)
>> Also, why would 32 -> 64 bit be a problem, provided you planned for
it in advance?
Name all the large, long-term projects that you know of that
*haven't* gotten bitten by something like this. Now, name all of
the large, long-term projects that you know of that HAVE gotten
bitten repeatedly by the state of the art moving past something that
they have custom programmed and can't easily integrate. If the
second number isn't a lot larger than the first, you're not living
in my world. :-)
I think you're exaggerating the issue. Porting the NM code from
32->64 bit was a pain but not a huge deal, certainly a trivial % of
the total work done on the project.
I do not think an enterprise DB would serve well for Novamente. 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.
However, the advantage of an enterprise DB would be that you'd avoid
some of the work involved in making NM a distributed system --- work
we know how to do, but haven't done yet, because it's time-consuming...
-- Ben
-----
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
-----
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
