Re: [agi] Development Environments for AI (a few non-religious comments!)
On Feb 21, 2007, at 6:09 AM, Eugen Leitl wrote: On Wed, Feb 21, 2007 at 08:59:51AM -0500, Mark Waser wrote: do well. What are the special requirements/functionalities of the indices that you believe that enterprise DBs are not *optimized* to handle? Relational databases are designed to do well at about anything, sans further tuning. Because of this relational databases perform very poorly for selected applications, many of them trivial, some complex, which are typically much better handled by custom code. An example of where enterprise DBs fall flat onto their indices is e.g. a multithreaded similiarity search on 5 million molecules. There are tons of other examples. This is a point that a great many people are obtuse to, and it is valid far beyond databases. Relational databases in particular have very narrowly optimized use cases; see the huge tradeoffs between row- oriented versus column-oriented physical structure of the same data for an example. In short: The only index/search/retrieval patterns that are scalable are those that are meaningfully reducible to a B-tree i.e. topologies that are collapsible into a zero-dimensional object on a one- dimensional line. By scalable I am referring to all three algorithmic dimensions: time, space, and concurrency. Unfortunately, there are many, many data types and spaces that collapse very poorly (or not at all) into a usable B-tree analogue. This is an enormous theoretical problem, and most people who work in software are oblivious to its existence. There is no scalable algorithm to represent e.g. spatio-temporal data. Whoever devises such an algorithm stands to make a great deal of money and/or fame, as it is *the* technological bottleneck for ubiquitous geospatial and other applications. A related problem is geospatial routing (a space I've been doing some important work in on the side), which is semi-dependent on the solution to that problem. Cheers, J. Andrew Rogers - 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/?member_id=231415user_secret=fabd7936
Re: [agi] Development Environments for AI (a few non-religious comments!)
Hey Ben, Thanks for explaining so clearly. I do understand graph databases and their querying challenges. :-) What I've not heard about is the successful application of indexes to these problems given that indexes in this case (as far as I know) are dependent upon the relationship between entities rather than just upon the indexed entity itself (which is also why location points are slightly difficult though soluble because they are only two dimensional while space-time becomes rapidly nastier as you add another dimension). Are you actually creating and maintaining indexes or are you just calculating index values for a single use and then discarding them? Mark - Original Message - From: Ben Goertzel [EMAIL PROTECTED] To: agi@v2.listbox.com Sent: Wednesday, February 21, 2007 7:51 PM Subject: **SPAM** Re: [agi] Development Environments for AI (a few non-religious comments!) 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. Wow. You've floored me given that indexes are key to what enterprise DBs do well. What are the special requirements/functionalities of the indices that you believe that enterprise DBs are not *optimized* to handle? Look at the literature regarding graph databases for some general background in this area... e.g. here is a random presentation on graph DB's... www.ciw.cl/material/irw-2005/2005-irw-gutierrez.pdf Novamente's internal AtomTable is a customized, in-RAM hypergraph DB, with much relationship to prior graph DB's.. Another example, beyond standard graph DB stuff, is efficient lookup of spatiotemporal entities based on which space, time or spacetime points they are near to ... -- Ben - 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 - 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
Re: [agi] Development Environments for AI (a few non-religious comments!)
That just wouldn't work at all for the Novamente design. Is the problem translating from C++ to C# or something else? 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. - Original Message - From: Ben Goertzel [EMAIL PROTECTED] To: agi@v2.listbox.com Sent: Wednesday, February 21, 2007 8:13 PM Subject: **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 original program, and then putting the result into useful variables is just too much. There are alternatives that can give an extremely fast data access, full language and other qualities necessary to creating an AGI 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 free though 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's tools 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 hate Microsoft, go PostgreSQL. If you're a Microsoftie, it's not a bad 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
Re: [agi] Development Environments for AI (a few non-religious comments!)
Mark Waser wrote: Hey Ben, Thanks for explaining so clearly. I do understand graph databases and their querying challenges. :-) What I've not heard about is the successful application of indexes to these problems given that indexes in this case (as far as I know) are dependent upon the relationship between entities rather than just upon the indexed entity itself (which is also why location points are slightly difficult though soluble because they are only two dimensional while space-time becomes rapidly nastier as you add another dimension). Are you actually creating and maintaining indexes Yep... or are you just calculating index values for a single use and then discarding them? Mark - Original Message - From: Ben Goertzel [EMAIL PROTECTED] To: agi@v2.listbox.com Sent: Wednesday, February 21, 2007 7:51 PM Subject: **SPAM** Re: [agi] Development Environments for AI (a few non-religious comments!) 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. Wow. You've floored me given that indexes are key to what enterprise DBs do well. What are the special requirements/functionalities of the indices that you believe that enterprise DBs are not *optimized* to handle? Look at the literature regarding graph databases for some general background in this area... e.g. here is a random presentation on graph DB's... www.ciw.cl/material/irw-2005/2005-irw-gutierrez.pdf Novamente's internal AtomTable is a customized, in-RAM hypergraph DB, with much relationship to prior graph DB's.. Another example, beyond standard graph DB stuff, is efficient lookup of spatiotemporal entities based on which space, time or spacetime points they are near to ... -- Ben - 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 - 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
Re: [agi] Development Environments for AI (a few non-religious comments!)
That was mean:-) . . . . Could you provide some details? Isn't that really cutting edge stuff? - Original Message - From: Ben Goertzel [EMAIL PROTECTED] To: agi@v2.listbox.com Sent: Thursday, February 22, 2007 11:20 AM Subject: **SPAM** Re: [agi] Development Environments for AI (a few non-religious comments!) Mark Waser wrote: Hey Ben, Thanks for explaining so clearly. I do understand graph databases and their querying challenges. :-) What I've not heard about is the successful application of indexes to these problems given that indexes in this case (as far as I know) are dependent upon the relationship between entities rather than just upon the indexed entity itself (which is also why location points are slightly difficult though soluble because they are only two dimensional while space-time becomes rapidly nastier as you add another dimension). Are you actually creating and maintaining indexes Yep... or are you just calculating index values for a single use and then discarding them? Mark - Original Message - From: Ben Goertzel [EMAIL PROTECTED] To: agi@v2.listbox.com Sent: Wednesday, February 21, 2007 7:51 PM Subject: **SPAM** Re: [agi] Development Environments for AI (a few non-religious comments!) 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. Wow. You've floored me given that indexes are key to what enterprise DBs do well. What are the special requirements/functionalities of the indices that you believe that enterprise DBs are not *optimized* to handle? Look at the literature regarding graph databases for some general background in this area... e.g. here is a random presentation on graph DB's... www.ciw.cl/material/irw-2005/2005-irw-gutierrez.pdf Novamente's internal AtomTable is a customized, in-RAM hypergraph DB, with much relationship to prior graph DB's.. Another example, beyond standard graph DB stuff, is efficient lookup of spatiotemporal entities based on which space, time or spacetime points they are near to ... -- Ben - 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 - 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
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 PM Subject: **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 original program, and then putting the result into useful variables is just too much. There are alternatives that can give an extremely fast data access, full language and other qualities necessary to creating an AGI 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 free though 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's tools 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
Re: [agi] Development Environments for AI (a few non-religious comments!)
:-) 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. - Original Message - From: Ben Goertzel [EMAIL PROTECTED] To: agi@v2.listbox.com Sent: Thursday, February 22, 2007 11:28 AM Subject: **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 PM Subject: **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 original program, and then putting the result into useful variables is just too much. There are alternatives that can give an extremely fast data access, full language and other qualities necessary to creating an AGI 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
Re: [agi] Development Environments for AI (a few non-religious comments!)
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 AM Subject: **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 PM Subject: **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 original program, and then putting the result into useful variables is just too much. There are alternatives that can give an extremely fast data access, full language and other qualities necessary to creating an AGI 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
Re: [agi] Development Environments for AI (a few non-religious comments!)
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??? Two answers. 1. My previous comment of While there might not be a good point to writing Novamente in the .NET framework in the SQL engine of a database server . . . AND 2. Because there are a lot of ancillary functions that would either benefit from having the RDB immediately available or not have to be written because the RDB is immediately available. - Original Message - From: Ben Goertzel [EMAIL PROTECTED] To: agi@v2.listbox.com Sent: Thursday, February 22, 2007 1:19 PM Subject: **SPAM** Re: [agi] Development Environments for AI (a few non-religious comments!) 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 AM Subject: **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 PM Subject: **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 original program, and then putting the result into useful variables is just too much. There are alternatives that can give an extremely fast data access, full language and other qualities necessary to creating an AGI 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
Re: [agi] Development Environments for AI (a few non-religious comments!)
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. Wow. You've floored me given that indexes are key to what enterprise DBs do well. What are the special requirements/functionalities of the indices that you believe that enterprise DBs are not *optimized* to handle? - 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
Re: [agi] Development Environments for AI (a few non-religious comments!)
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
Re: [agi] Development Environments for AI (a few non-religious comments!)
Wow. You've floored me given that indexes are key to what enterprise DBs do well. What are the special requirements/functionalities of the indices that you believe that enterprise DBs are not *optimized* to handle? Is there any AGI project which uses so called enterprise DBs intensively? If not, I guess the burden of proof is on you... Ricardo - 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
Re: **SPAM** Re: [agi] Development Environments for AI (a few non-religious comments!)
On 2/21/07, Eugen Leitl [EMAIL PROTECTED] wrote: The language thread has been reasonably abstruse already, but proposing doing AI by stored procedures in relational databases backed by ~10 ms access time devices... Hey, why not tapes? I think you could implement a reasonably competent Turing machine with an Ultrium tape library. Why not implementing it on that? You can't beat the costs per bit. As to 10^23 words/s, well... I'm working on an AI driven by water wheel and memory stored as rubber ducks floating in a pond. The current problems I'm faced with is maintaining accurate tracking of regional rainfall (for both the wheel and the pond) as well as minimizing wind effects on the ducks on the pond. I'm surprised anyone has such strong opinions about what absolutely will not work considering that we do not have evidence of what absolutely will work. Clearly there are conceivable tasks that would sub-optimal to do in a commercial database. Isn't the whole idea of modular development that the performance failure of a DB can be managed after the consumer of that data shows significant promise? Or do we have to assume that AI developers should write every module from scratch? I wouldn't want to spend considerable effort building a rigid or formal knowledge base because I'd feel that I should stick with it in order to justify its cost even after it appeared that the engine (brain?) might be better with a different KB. Since there is still no agreed-upon right way to do A[G]I, doesn't it make sense to be able to rapidly try as many different potential solutions as possible in order to assess each method's promise? - 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
Re: [agi] Development Environments for AI (a few non-religious comments!)
On 2/21/07, Mark Waser [EMAIL PROTECTED] wrote: 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? Incidentally, for those things (scalable write/search/read of large data sets) which existing database engines do well, which one would you recommend? For example, I remember hearing years ago that MySQL should be avoided other than for read-only operation due to lacking adequate transaction handling, but I've also heard it's improved a great deal in the meantime, is that the case? - 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
RE: [agi] Development Environments for AI (a few non-religious comments!)
Human vision article of interest: http://www.technologyreview.com/Infotech/18210/ seems to me they heisted alot of concepts from Hawkins for this application. RE: the database versus custom data handlingI think for certain apps, DB's are fine, but for AGI and the associated amount of data, a custom system is a must. A person can write a b-tree file management system that can scale to tens of thousands of low-cost pc's and be lightning fast. This is exactly the way Google looks up search results and they do NOT use a DB. Cheers, --Kevin _ From: Russell Wallace [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 21, 2007 9:34 AM To: agi@v2.listbox.com Subject: Re: [agi] Development Environments for AI (a few non-religious comments!) On 2/21/07, Mark Waser [EMAIL PROTECTED] wrote: 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? Incidentally, for those things (scalable write/search/read of large data sets) which existing database engines do well, which one would you recommend? For example, I remember hearing years ago that MySQL should be avoided other than for read-only operation due to lacking adequate transaction handling, but I've also heard it's improved a great deal in the meantime, is that the case? _ 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
Re: [agi] Development Environments for AI (a few non-religious comments!)
On any given machine, indexing code quickly reaches it's maximum speed. Enterprise DB's are much slower because they have to be concerned with much more than just simple indexing. I know for a fact that my indexes are as fast or faster than any widely used software DB on the same hardware. Optimization on DB's is done at a higher level than an index in any case. David Clark - Original Message - From: Mark Waser [EMAIL PROTECTED] To: agi@v2.listbox.com Sent: Wednesday, February 21, 2007 6:59 AM Subject: Re: [agi] Development Environments for AI (a few non-religious comments!) 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. Wow. You've floored me given that indexes are key to what enterprise DBs do well. What are the special requirements/functionalities of the indices that you believe that enterprise DBs are not *optimized* to handle? - 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
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 original program, and then putting the result into useful variables is just too much. There are alternatives that can give an extremely fast data access, full language and other qualities necessary to creating an AGI 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 To: 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 free though 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's tools 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 hate Microsoft, go PostgreSQL. If you're a Microsoftie, it's not a bad 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
Re: [agi] Development Environments for AI (a few non-religious comments!)
Optimization on DB's is done at a higher level than an index in any case. And with that statement, you prove that you don't know what you're talking about . . . . Optimization on commercial DBs is done at all levels and anywhere possible. - - - - - And by the way, while I would believe that your indexes could be as fast or faster than any equivalent commercial DB software on small datastores, I don't believe that they can scale up to the necessary sizes for AGI *and* remain faster (or even close assuming that you could even handle the scaling up). There are always trade-offs. Enterprise DBs have accepted unimportant slowdowns at small scales to optimize for scaling to much larger sizes. And the kid on the bicycle can get down the street long before the airline pilot even starts the engines. - Original Message - From: David Clark [EMAIL PROTECTED] To: agi@v2.listbox.com Sent: Wednesday, February 21, 2007 2:04 PM Subject: **SPAM** Re: [agi] Development Environments for AI (a few non-religious comments!) On any given machine, indexing code quickly reaches it's maximum speed. Enterprise DB's are much slower because they have to be concerned with much more than just simple indexing. I know for a fact that my indexes are as fast or faster than any widely used software DB on the same hardware. Optimization on DB's is done at a higher level than an index in any case. David Clark - Original Message - From: Mark Waser [EMAIL PROTECTED] To: agi@v2.listbox.com Sent: Wednesday, February 21, 2007 6:59 AM Subject: Re: [agi] Development Environments for AI (a few non-religious comments!) 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. Wow. You've floored me given that indexes are key to what enterprise DBs do well. What are the special requirements/functionalities of the indices that you believe that enterprise DBs are not *optimized* to handle? - 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
Re: [agi] Development Environments for AI (a few non-religious comments!)
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. - Original Message - From: David Clark To: 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 original program, and then putting the result into useful variables is just too much. There are alternatives that can give an extremely fast data access, full language and other qualities necessary to creating an AGI 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 To: 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 free though 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's tools 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 hate Microsoft, go PostgreSQL. If you're a Microsoftie, it's not a bad 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
Re: [agi] Development Environments for AI (a few non-religious comments!)
You are a very ignorant person Mr Mark Waser. How do you know what I know or don't from a few sentences in an email? Have you designed and programmed a commercial database programming language that sold over 30,000 copies around the world? If you have points to make, then make them without the flames! David Clark PS Would you call millions of records and hundreds of gigs of disk space small? How about looking for a random string in 16,000 emails (over 100 meg of emails) in 1 second. Slow? - Original Message - From: Mark Waser [EMAIL PROTECTED] To: agi@v2.listbox.com Sent: Wednesday, February 21, 2007 12:36 PM Subject: Re: [agi] Development Environments for AI (a few non-religious comments!) Optimization on DB's is done at a higher level than an index in any case. And with that statement, you prove that you don't know what you're talking about . . . . Optimization on commercial DBs is done at all levels and anywhere possible. - - - - - And by the way, while I would believe that your indexes could be as fast or faster than any equivalent commercial DB software on small datastores, I don't believe that they can scale up to the necessary sizes for AGI *and* remain faster (or even close assuming that you could even handle the scaling up). There are always trade-offs. Enterprise DBs have accepted unimportant slowdowns at small scales to optimize for scaling to much larger sizes. And the kid on the bicycle can get down the street long before the airline pilot even starts the engines. - 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
Re: [agi] Development Environments for AI (a few non-religious comments!)
How do you know what I know or don't from a few sentences in an email? Huh? When people make a simple, clear, and blatantly incorrect statement, don't you feel pretty sure that they don't know what they're talking about? If you wanted to retract or amend your statement that Optimization on DB's is done at a higher level than an index in any case, I might be tempted to change my mind. But blustering on about *off-topic* experience only diminishes your credibility. Just because you have written database software and didn't do optimization at the index level (very hard to believe), doesn't mean that others haven't (unless you're claiming that you know everyone's software inside out -- in which case, I'd just laugh at you since I do know some of the people involved and do know that they do indeed do index level optimization). And pointing to a specific, blatantly incorrect statement and dismissing it with half a sentence is hardly a flame . . . . - Original Message - From: David Clark [EMAIL PROTECTED] To: agi@v2.listbox.com Sent: Wednesday, February 21, 2007 3:18 PM Subject: **SPAM** Re: [agi] Development Environments for AI (a few non-religious comments!) You are a very ignorant person Mr Mark Waser. How do you know what I know or don't from a few sentences in an email? Have you designed and programmed a commercial database programming language that sold over 30,000 copies around the world? If you have points to make, then make them without the flames! David Clark PS Would you call millions of records and hundreds of gigs of disk space small? How about looking for a random string in 16,000 emails (over 100 meg of emails) in 1 second. Slow? - Original Message - From: Mark Waser [EMAIL PROTECTED] To: agi@v2.listbox.com Sent: Wednesday, February 21, 2007 12:36 PM Subject: Re: [agi] Development Environments for AI (a few non-religious comments!) Optimization on DB's is done at a higher level than an index in any case. And with that statement, you prove that you don't know what you're talking about . . . . Optimization on commercial DBs is done at all levels and anywhere possible. - - - - - And by the way, while I would believe that your indexes could be as fast or faster than any equivalent commercial DB software on small datastores, I don't believe that they can scale up to the necessary sizes for AGI *and* remain faster (or even close assuming that you could even handle the scaling up). There are always trade-offs. Enterprise DBs have accepted unimportant slowdowns at small scales to optimize for scaling to much larger sizes. And the kid on the bicycle can get down the street long before the airline pilot even starts the engines. - 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
Re: [agi] Development Environments for AI (a few non-religious comments!)
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
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 original program, and then putting the result into useful variables is just too much. There are alternatives that can give an extremely fast data access, full language and other qualities necessary to creating an AGI 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 free though 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's tools 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 hate Microsoft, go PostgreSQL. If you're a Microsoftie, it's not a bad 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
Re: [agi] Development Environments for AI (a few non-religious comments!)
Chuck Esterbrook wrote: On 2/19/07, Richard Loosemore [EMAIL PROTECTED] wrote: Wow, I leave off email for two days and a 55-message Religious War breaks out! ;-) I promise this is nothing to do with languages I do or do not like (i.e. it is non-religious...). As many people pointed out, programming language matters a good deal less that what you are going to use it for. In my case I am very clear about what I want to do, and it is very different from conventional AI. My own goals are to build an entire software development environment, as I said earlier, and the main reasons for this are: 1) I am working on a conceptual framework for developing a *class* of AI systems [NB: a class of systems, not just one system], and the best way to express a framework is by instantiating that framework in the form of a tool that allows systems within that framework to be constructed easily. Can't comment on this one as it's too high level for me to do so. 2) My intention is to do systematic experiments to investigate the behavior of systems within that class, so I need some way to easily do this systematic experimentation. I want, for example, to construct a particular mechanism and then look at the behavior of many variants of that mechanism. So, for example, a concept-learning mechanism that involves a parameter governing the number of daughter concepts that are grabbed in an abstraction event ... and I might be intersted in how the mechanism behaves when the number of daughters is 2, 3, 4, 5, or some random number in the vicinity of one of those). I need a tool that will let me quickly set up such simulation experiments without having to touch any low level code. I've done this for financial analysis and genetic algorithm projects that had parameters that could be varied. It can be glued on to just about any system. Define your parameters by name, type, required-or-not and optionally (when applicable) min and max. Then provide some code that reads the parameter definitions and does (at least) the following: * complains about violations (missing value, value of out range) * interprets looping values like a (start, stop, step) for numeric parameters or an (a, b, c) for enums or strings * executes the program with each combination of values, storing the parameter sets with the results The inputs could be done via a text file that is parsed and interpreted. And/or a web or gui form could be generated from the defs. My real point is that you don't really need a new dev env for this. I take your point, though what I did above was try to give the simplest example I can think of. Certainly, all the facilities that I have in mind (wrt automated tests) could just be implemented as add-ons to something else. No doubt about it. But the list of facilities does start to get quite large and complex, when you go into the detail, so there needs to be some way to organize them all in one tightly-knit context. After a while, it kind of adds up to an environment. Here are some of the other things that would need to be automated: 1) I want the system to allow a user to point to any structural component (within limits) and say vary this. So then the system would look at the definition of that structural component and try to come up with suggestions for ways to make variations. These would be suggested to the user, who would then select the ones they wanted to try. You could probably imagine the complexity involved if the user couldn't do this, and instead had to look into the parametric definitions for structural aspects of the system that were represented graphically, then try to manually figure out a way to make sensible variations. This is what you might call a meta-automation level, because the process of *choosing* an automated test run is itself being automated. Quick example: the space within which elements (my term for the active processes that represent symbols, or concepts) interact with one another, is structured in such a way that there can be bottlenecks where different groups of elements (say, phonemes and graphemes) are forced to interact in a way that does not allow full connectivity. This would show up in graphical form as two blob-like zones with a narrow bridge between them. The user should be able to select the perimeter line that goes around the two blobs and bridge, and see the handles that define the shape. Then say, of the handles in the vicinity of the bottleneck show me some variations on this. Then the system gives a set of example variations, with the bottleneck constricted or dilated. The important thing is that the user should never have to figure out where in the code the parameters are that would allow those variations to happen: they should just be able to think, suggest and act. 2) Same as above, but you would want to ask the system for monte carlo runs in which it could only select random examples from a space of variations,
Re: [agi] Development Environments for AI (a few non-religious comments!)
My real point is that you don't really need a new dev env for this. Richard is talking about some *substantial* architecture here -- not just a development environment but a *lot* of core library routines (as you later speculate) and functionality that is either currently spread across many disparate non-communicating research platforms or doesn't even exist yet. A tool that will quickly set up such simulation experiments without having to touch any low level code first requires all that low-level code to be written/ported to a common development and testing environment -- which, in itself, requires a design/specification of a development and testing environment that can even support all the proposed code. If you've got a small app with all of the specifications set, it's easy to write a testing harness. What we're talking about here though is an environment that can 1) store and retrieve via a variety of different mechanisms an immense quantity of data, 2) store and retrieve vast amounts of knowledge in a variety of different formats (and cross-translating between formats as necessary), 3) build knowledge out of data through a variety of different mechanisms (probably written in a *wide* variety of programming language families including LISP, Prolog, and the functional programming languages (OCaml, Haskell, etc.), 4) allow for the tracking of context in all of the preceding operations, etc., etc., etc. Realistically, you'll have an AGI before the environment is completed . . . . Personally, I'd start with a commercial extensible development environment and a commercial enterprise class datastore and start designing and developing from there. The one thing that I always hammer on Novamente for is their decision to build their datastore from scratch. They do awesome research on discovery and learning but they've bled and continue to bleed a lot of manpower and time on interacting with a custom, non-enterprise class data *core*. Imagine if they had a development environment like Richard is proposing . . . . (and plugged all of their BOA, MOSES, etc. into it) . . . . - Original Message - From: Chuck Esterbrook [EMAIL PROTECTED] To: agi@v2.listbox.com Sent: Tuesday, February 20, 2007 1:40 AM Subject: **SPAM** Re: [agi] Development Environments for AI (a few non-religious comments!) On 2/19/07, Richard Loosemore [EMAIL PROTECTED] wrote: Wow, I leave off email for two days and a 55-message Religious War breaks out! ;-) I promise this is nothing to do with languages I do or do not like (i.e. it is non-religious...). As many people pointed out, programming language matters a good deal less that what you are going to use it for. In my case I am very clear about what I want to do, and it is very different from conventional AI. My own goals are to build an entire software development environment, as I said earlier, and the main reasons for this are: 1) I am working on a conceptual framework for developing a *class* of AI systems [NB: a class of systems, not just one system], and the best way to express a framework is by instantiating that framework in the form of a tool that allows systems within that framework to be constructed easily. Can't comment on this one as it's too high level for me to do so. 2) My intention is to do systematic experiments to investigate the behavior of systems within that class, so I need some way to easily do this systematic experimentation. I want, for example, to construct a particular mechanism and then look at the behavior of many variants of that mechanism. So, for example, a concept-learning mechanism that involves a parameter governing the number of daughter concepts that are grabbed in an abstraction event ... and I might be intersted in how the mechanism behaves when the number of daughters is 2, 3, 4, 5, or some random number in the vicinity of one of those). I need a tool that will let me quickly set up such simulation experiments without having to touch any low level code. I've done this for financial analysis and genetic algorithm projects that had parameters that could be varied. It can be glued on to just about any system. Define your parameters by name, type, required-or-not and optionally (when applicable) min and max. Then provide some code that reads the parameter definitions and does (at least) the following: * complains about violations (missing value, value of out range) * interprets looping values like a (start, stop, step) for numeric parameters or an (a, b, c) for enums or strings * executes the program with each combination of values, storing the parameter sets with the results The inputs could be done via a text file that is parsed and interpreted. And/or a web or gui form could be generated from the defs. My real point is that you don't really need a new dev env for this. 3) One reason that is almost tangential to AI itself, though related: I believe that conventional
Re: [agi] Development Environments for AI (a few non-religious comments!)
On 2/20/07, Mark Waser [EMAIL PROTECTED] wrote: Realistically, you'll have an AGI before the environment is completed . . . . I think you slightly underestimate the difficulty of creating AGI ;) Personally, I'd start with a commercial extensible development environment and a commercial enterprise class datastore and start designing and developing from there. The one thing that I always hammer on Novamente for is their decision to build their datastore from scratch. I'm still curious about what advantages you see commercial database systems having for AI work? - 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
Re: **SPAM** Re: [agi] Development Environments for AI (a few non-religious comments!)
I think you slightly underestimate the difficulty of creating AGI ;) I think that you grossly underestimate the magnitude of what is being proposed because the tag development environment has been attached to it.:-) Realistically, the development environment is both the AGI's DNA *and* it's womb/environment/nutrients. I'm still curious about what advantages you see commercial database systems having for AI work? An AGI is going to want to store, retrieve, and update an immense amount of data and knowledge based upon a wide array of criteria. Many, many really smart people have spent many, many man-years designing heavy-duty, fault-tolerant systems that do exactly that (with many other capabilities besides -- you know, little things like triggers, back-up, set-based operations, etc., etc.). What possible advantage do you see in not leveraging all that capability? Note that I'm not talking about a stupid architecture where you hammer yourself flat with nine million, small database calls. I block move chunks of data in and out and would move anything that uses more than a certain amount of data into the database itself and operate on it there. - Original Message - From: Russell Wallace To: agi@v2.listbox.com Sent: Tuesday, February 20, 2007 3:31 PM Subject: **SPAM** Re: [agi] Development Environments for AI (a few non-religious comments!) On 2/20/07, Mark Waser [EMAIL PROTECTED] wrote: Realistically, you'll have an AGI before the environment is completed . . . . I think you slightly underestimate the difficulty of creating AGI ;) Personally, I'd start with a commercial extensible development environment and a commercial enterprise class datastore and start designing and developing from there. The one thing that I always hammer on Novamente for is their decision to build their datastore from scratch. I'm still curious about what advantages you see commercial database systems having for AI work? -- 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
Re: **SPAM** Re: [agi] Development Environments for AI (a few non-religious comments!)
On 2/20/07, Mark Waser [EMAIL PROTECTED] wrote: I think that you grossly underestimate the magnitude of what is being proposed because the tag development environment has been attached to it.:-) *grin* No, I think it's a big project, at least the version I have in mind (on my to-do list for if and when I get the chance to spend a few years on it) - bigger than some people's estimates for full AGI. I still think actual AGI will be much much harder. Note that I'm not talking about a stupid architecture where you hammer yourself flat with nine million, small database calls. I block move chunks of data in and out and would move anything that uses more than a certain amount of data into the database itself and operate on it there. How do you propose to operate on data while it's stored in the database? Commercial data processing usually performs no significant computation, just storing and retrieving data, and DBs typically provide facilities for doing that; but AI needs to perform heavy computation, don't you need to have your working set in your processes' memory for that? - 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
Re: [agi] Development Environments for AI (a few non-religious comments!)
On 2/20/07, Ben Goertzel [EMAIL PROTECTED] wrote: Novamente works fine on 64-bit machines -- but it took nearly a man-month of work to 64-bit-ify the code, which was done back in 2004... I guess I stand corrected on that one! - 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
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
Re: [agi] Development Environments for AI (a few non-religious comments!)
On 2/20/07, Richard Loosemore [EMAIL PROTECTED] wrote: ... It helps to remember that my target users are cognitive scientists who want to be able to stay in a high-level thought mode (fancy way of saying that my users ain't gonna be hackers). Now I see why it would be a dev env, both from the examples and the target audience. Thanks, -Chuck - 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
Re: [agi] Development Environments for AI (a few non-religious comments!)
Richard Loosemore wrote: There is a restriction in my case that enables me to get away without having to solve the general problem. I am curious to know what that restriction is? Offlist would be welcomed. Thanks Anna:) On 2/19/07, Richard Loosemore [EMAIL PROTECTED] wrote: Wow, I leave off email for two days and a 55-message Religious War breaks out! ;-) I promise this is nothing to do with languages I do or do not like (i.e. it is non-religious...). As many people pointed out, programming language matters a good deal less that what you are going to use it for. In my case I am very clear about what I want to do, and it is very different from conventional AI. My own goals are to build an entire software development environment, as I said earlier, and the main reasons for this are: 1) I am working on a conceptual framework for developing a *class* of AI systems [NB: a class of systems, not just one system], and the best way to express a framework is by instantiating that framework in the form of a tool that allows systems within that framework to be constructed easily. 2) My intention is to do systematic experiments to investigate the behavior of systems within that class, so I need some way to easily do this systematic experimentation. I want, for example, to construct a particular mechanism and then look at the behavior of many variants of that mechanism. So, for example, a concept-learning mechanism that involves a parameter governing the number of daughter concepts that are grabbed in an abstraction event ... and I might be intersted in how the mechanism behaves when the number of daughters is 2, 3, 4, 5, or some random number in the vicinity of one of those). I need a tool that will let me quickly set up such simulation experiments without having to touch any low level code. 3) One reason that is almost tangential to AI itself, though related: I believe that conventional environments and languages are built by people who think like engineers, and do not have a good understanding of how a mind works when it is trying to comprehend the enormous complexity of computational systems. [I know, I said that in combative language: but try not to flame me just because I said it assertively ;-)]. So I am trying to use psychological principles to make the process of system design and programming into a task that does not constantly trap the designer/programmer into the most stupid of errors. I have a number of ideas in this respect, but since I am talking to some people about funding this project right now, I'd rather not go into detail. 4) I need particular primitives that are simply not available in conventional languages. The biggest example is a facility for massive asymmetric parallelism that is not going to fall flat on its face all the time (with deadlocks and livelocks). I realise that everyone and their grandmother would like to do massive parallel programming without all the usuall headaches, and that the general problem is horrendous... but I can actually solve the problem in my context because I do not have to create a general solution to the problem. There is a restriction in my case that enables me to get away without having to solve the general problem. Again, apologies for coyness: possible patent pending and all that. 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 - 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
Re: [agi] Development Environments for AI (a few non-religious comments!)
On 2/19/07, Richard Loosemore [EMAIL PROTECTED] wrote: Wow, I leave off email for two days and a 55-message Religious War breaks out! ;-) I promise this is nothing to do with languages I do or do not like (i.e. it is non-religious...). As many people pointed out, programming language matters a good deal less that what you are going to use it for. In my case I am very clear about what I want to do, and it is very different from conventional AI. My own goals are to build an entire software development environment, as I said earlier, and the main reasons for this are: 1) I am working on a conceptual framework for developing a *class* of AI systems [NB: a class of systems, not just one system], and the best way to express a framework is by instantiating that framework in the form of a tool that allows systems within that framework to be constructed easily. Can't comment on this one as it's too high level for me to do so. 2) My intention is to do systematic experiments to investigate the behavior of systems within that class, so I need some way to easily do this systematic experimentation. I want, for example, to construct a particular mechanism and then look at the behavior of many variants of that mechanism. So, for example, a concept-learning mechanism that involves a parameter governing the number of daughter concepts that are grabbed in an abstraction event ... and I might be intersted in how the mechanism behaves when the number of daughters is 2, 3, 4, 5, or some random number in the vicinity of one of those). I need a tool that will let me quickly set up such simulation experiments without having to touch any low level code. I've done this for financial analysis and genetic algorithm projects that had parameters that could be varied. It can be glued on to just about any system. Define your parameters by name, type, required-or-not and optionally (when applicable) min and max. Then provide some code that reads the parameter definitions and does (at least) the following: * complains about violations (missing value, value of out range) * interprets looping values like a (start, stop, step) for numeric parameters or an (a, b, c) for enums or strings * executes the program with each combination of values, storing the parameter sets with the results The inputs could be done via a text file that is parsed and interpreted. And/or a web or gui form could be generated from the defs. My real point is that you don't really need a new dev env for this. 3) One reason that is almost tangential to AI itself, though related: I believe that conventional environments and languages are built by people who think like engineers, and do not have a good understanding of how a mind works when it is trying to comprehend the enormous complexity of computational systems. [I know, I said that in combative language: but try not to flame me just because I said it assertively ;-)]. So I am trying to use psychological principles to make the process of system design and programming into a task that does not constantly trap the designer/programmer into the most stupid of errors. I have a number of ideas in this respect, but since I am talking to some people about funding this project right now, I'd rather not go into detail. This is the most interesting point in your list. Too bad we can't get the details yet. :-) I don't know what such an environment would look like, but I don't see why it couldn't exist. Developers have to keep a lot of stuff in their head as they work on a project and I'm positive that current IDEs aren't doing as much as they could to help visualize, manage and develop a project. Not nearly as much as they could! I sincerely wish you luck as I'd like to take such an environment for a drive. 4) I need particular primitives that are simply not available in conventional languages. The biggest example is a facility for massive asymmetric parallelism that is not going to fall flat on its face all the time (with deadlocks and livelocks). I realise that everyone and their grandmother would like to do massive parallel programming without all the usuall headaches, and that the general problem is horrendous... but I can actually solve the problem in my context because I do not have to create a general solution to the problem. There is a restriction in my case that enables me to get away without having to solve the general problem. Again, apologies for coyness: possible patent pending and all that. That feels likes something that can be done via a library, although I appreciate that some things can only be done at the language level or are simply best done there. (And perhaps at the environment level or some mix of all of these.) Feel free to keep us informed of any technical and business developments... -Chuck - 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
