On Thu, Apr 17, 2008 at 2:42 PM, Mark Waser <[EMAIL PROTECTED]> wrote: > > > Really, work on the AtomTable has been a small percentage of work on > > the Novamente Cognition Engine ... and, the code running the AtomTable is > > now pretty much the same as it was in 2001 (though it was tweaked to make > it > > 64-bit compatible, back in 2004 ... and there has been ongoing bug-removal > > as well...). > > > > And . . . and . . . and . . . :-) It's far more than you're > admitting to yourself. :-)
That's simply not true, but I know of no way to convince you. The AtomTable work was full-time work for a two guys for a few months in 2001, and since then it's been occasional part-time tweaking by two people who have been full-time engaged on other projects. > > We wrote some new wrappers for the AtomTable > > last year (based on STL containers), but that didn't affect the > > internals, just the API. > > > > Which is what everything should have been designed around anyways -- so > effectively, last year was a major "breaking" change that affected *all* the > software written to the old API. Yes, but calls to the AT were already well-encapsulated within the code, so changing from the old API to the new has not been a big deal. > Absolutely. That's what I'm pushing for. Could you please, please publish > the 2007 AtomTable API? That's actually far, far more important than the > code behind it. Please, please . . . . publish the spec today . . . . > pretty please with a cherry on top? It'll be done as part of the initial OpenCog release, which will be pretty soon now ... I don't have a date yet though... > > However, I'm not convinced this would be a good idea. There are a lot of > > useful specialized indices in the AtomTable, and replicating all this in > some > > other graph DB would wind up being a lot of work ... and we could use that > > time/effort on other stuff instead.... > > > > Which (pardon me, but . . . ) clearly shows that you're not a professional > software engineer I'm not but many other members of the Novamente team are > My contention is that you all should be > *a lot* further along than you are. You have more talent than anyone else > but are moving at a truly glacial pace. 90% of Novamente LLC's efforts historically have gone into various AI consulting projects that pay the bills. Now, about 60% is going into consulting projects, and 40% is going into the virtual pet brain project We have very rarely had funding to pay folks to work on AGI, so we've worked on it in bits and pieces here and there... Sad, but true... > I understand that you believe that > this is primarily due to other reasons but *I am telling you* that A LOT of > it is also your own fault due to your own software development choices. You're wrong, but arguing the point over and over isn't getting us anywhere. > Worse, fundamentally, currently, you're locking *everyone* into *your* > implementation of the atom table. Well, that will not be the case in OpenCog. The OpenCog architecture will be such that other containers could be inserted if desired. >Why not let someone else decide whether > or not it is worth their time and effort to implement those specialized > indices on another graph DB of their choice? If you would just open up the > API and maybe accept some good enhancements (or, maybe even, if necessary, > some changes) to it? Yes, that's going to happen within OpenCog. > > Using a relational DB rather than a graph DB is not appropriate for the > NCE > > design, however. > > > > Incorrect. If the API is identical and the speed is identical, whether it > is a relational db or a graph db *behind the scenes* is irrelevant. Design > to your API -- *NOT* to the underlying technology. You keep making this > mistake. The speed will not be identical for an important subset of queries, because of intrinsic limitations of the B-tree datastructures used inside RDB's. We discussed this before. > Seriously -- I think that you're really going to be surprised at how fast > OpenCog might take off if you'd just relax some control and concentrate on > the specifications and the API rather than the implementation issues that > you're currently wasting time on. I am optimistic about the development speedup we'll see from OpenCog, but not for the reason you cite. Rather, I think that by opening it up in an intelligent way, we're simply going to get a lot more people involved, contributing their code, their time, and their ideas. This will accelerate things considerably, if all goes well. I repeat that NO implementation time has been spent on the AtomTable internals for quite some time now. A few weeks was spent on the API last year, by one person. I'm not sure why you want to keep exaggerating the time put into that component, when after all you weren't involved in its development at all (and I didn't even know you when the bulk of that development was being done!!) I don't care if, in OpenCog, someone replaces the AtomTable internals with something better. The API and the vocabulary of node and link types is far more important from an AI perspective than the AT internals. The main issue with the current AT internals is that they don't come with any automated approach to persistence. The AT is a RAM-only data structure. If AT internals were replaced with something that handled persistence as well, that would be great. But it would need to be flexible enough to handle complex indices generated automatically based on "frequent subgraph mining", plus caching to disk based on AI-driven forgetting mechanisms, etc. I have no reason to believe this isn't possible, and it may be a good idea ... what I keep rejecting is your false statement that the development of the AT took up a huge amount of work, or is taking ANY work at the moment. -- Ben G ------------------------------------------- agi Archives: http://www.listbox.com/member/archive/303/=now RSS Feed: http://www.listbox.com/member/archive/rss/303/ Modify Your Subscription: http://www.listbox.com/member/?member_id=8660244&id_secret=101455710-f059c4 Powered by Listbox: http://www.listbox.com
