Mark Waser wrote:
:-) I think that you don't realize that .NET in the SQL engine has all the advantages of standard .NET on Windows (i.e. it *isn't* true that everything has goes through a SQL funnel). If you can do a .NET port to Windows, that port will run inside the SQL engine with zero modification.
OK ... but if an RDB is not the right data container to use, then what advantage is there in running your C# code (including e.g. your graph DB) in in a SQL engine???
----- Original Message ----- From: "Ben Goertzel" <[EMAIL PROTECTED]> To: <agi@v2.listbox.com> Sent: Thursday, February 22, 2007 11:28 AMSubject: **SPAM** Re: [agi] Development Environments for AI (a few non-religious comments!)Mark Waser wrote:That just wouldn't work at all for the Novamente design.Is the problem translating from C++ to C# or something else?Translating NM to C# would not be particularly problematic, though we would likely end up using unsafe code blocks in some places to make execution sufficiently rapid in the face of complex GC demands. It would certainly be a lot of work, though, and we don't have any motivation to do so.AWindows port may be in the works, but that's a vastly simpler thing, of course. We have one key AI developer who has a peculiar fondness for VC++ and wants to do NM development in that environment.While there might not be a good point to writing Novamente in the .NET framework in the SQL engine of a database server, I don't get why it wouldn't work at all.So long as the SQL engine is Turing complete (which it is, I believe), it would work, if you set computational efficiency aside. However, my strong feeling is that it would be many orders of magnitude slower than the current implementation, which is not all that fast (for algorithmic rather than implementational reasons).This was concluded in 2001 by NM team members who have a lot more experience with RDB's than I do.RDB's obviously have major strengths, but they are not good for every application. As Eugen pointed out, they are not adequate for BLAST type gene sequence searches, nor for large-scale text information retrieval ... and nor for graph data structures that are rapidly evolving and need to support complex queries rapidly...-- Ben -- Ben----- Original Message ----- From: "Ben Goertzel" <[EMAIL PROTECTED]> To: <agi@v2.listbox.com> Sent: Wednesday, February 21, 2007 8:13 PMSubject: **SPAM** Re: [agi] Development Environments for AI (a few non-religious comments!)Mark Waser wrote:So from the below, can I take it that you're a big proponent of the .NET framework since database access is built into the framework *AND* the framework is embedded in the database? The "crazy like a fox" way to build an AGI may very well be to write it in the .NET framework in the SQL engine of a database server.That just wouldn't work at all for the Novamente design.If you have an AGI design that will work reasonably efficiently that way, then go for it. But I am dubious, at the moment ;-)ben----- Original Message ----- *From:* David Clark <mailto:[EMAIL PROTECTED]> *To:* agi@v2.listbox.com <mailto:agi@v2.listbox.com> *Sent:* Wednesday, February 21, 2007 2:27 PM *Subject:* **SPAM** Re: [agi] Development Environments for AI (a few non-religious comments!) Unless the database is built into the language then using a database, outside the AGI, will never work. The data and code connection must be within the same development system. The overhead of sending, parsing, optimizing the query, getting the data, preparing the result set, sending it back to the originalprogram, and then putting the result into useful variables is justtoo much. There are alternatives that can give an extremely fast dataaccess, full language and other qualities necessary to creating anAGI out there. MySQL is not only slow, but has no language capable of creating anything. Lisp, Python, C++ etc don't have the necessary power tools to create much of anything without starting everything from scratch. Some manipulations for any large project (AGI) can be done in memory but without a scalable and flexible way of storing and retrieving large amounts of data from disk, no AGI is going to be built using conventional computers any time soon. David Clark ----- Original Message ----- *From:* Mark Waser <mailto:[EMAIL PROTECTED]> *To:* agi@v2.listbox.com <mailto:agi@v2.listbox.com> *Sent:* Wednesday, February 21, 2007 9:36 AM *Subject:* Re: [agi] Development Environments for AI (a few non-religious comments!) >> Incidentally, for those things (scalable write/search/read of large data sets) which existing database engines do well, which one would you recommend?Hmmm . . . . am I dumb enough to incite a database holy war? .. . . . Yeah, I am.Let me phrase it this way . . . . I have extensive experience with MySQL, Microsoft SQL Server, Oracle, and PostgreSQL. MySQL is simplest and free. PostgreSQL is awesome and freethough the tools aren't quite as friendly as Microsoft and it doesn't scale up quite as far as Microsoft yet -- though it probably scales further than anyone on this list really needs. Microsoft has the best tools and the easiest integration with many things. Oracle scales further but it'stools are not as good and it has some really odd capability holes.Or . . . . Never sneer at MySQL if someone wants it and it fulfills your requirements (though it won't cut it for AGI fairly quickly). If you're a LAMP/*nix aficionado and hateMicrosoft, go PostgreSQL. If you're a Microsoftie, it's not abad way to go and has many advantages. But don't use Oracle, the scaling advantage is *NOT* worth the costs (money, time, effort, and frustration).------------------------------------------------------------------------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----- 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
----- 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
