Matt, On 12/9/08, Matt Mahoney <[EMAIL PROTECTED]> wrote:
> No, I don't believe that Dr. Eliza knows nothing about normal health, or > that Cyc knows nothing about illness. > Of course you are right. In Dr. Eliza's case, it is quick to ask questions to establish subsystem normalcy to eliminate candidate problems. Further, Cyc already has long lists of malfunctions for every subsystem. However, Dr. Eliza can't do anything with normalcy other than dismissing certain specific abnormalities, and Cyc can't do much of anything with an abnormality other than parroting information out about it when asked. Now, it you want either of these programs to really USE their knowledge structure to do much more than just checking something off or parroting something out, then you quickly see the distinction that I was pointing out. Steve Richfield > ------------------------------ > *From:* Steve Richfield <[EMAIL PROTECTED]> > *To:* [email protected] > *Sent:* Tuesday, December 9, 2008 3:21:18 PM > *Subject:* Re: [agi] Machine Knowledge and Inverse Machine Knowledge... > > Matt, > > It appears that either you completely missed the point in my earlier post, > that > > Knowledge + Inverse Knowledge ~= Understanding (hopefully) > > > There are few things in the world that are known SO well that from direct > knowledge thereof that you can directly infer all potential modes of > failure. Especially with things that have been engineered (or divinely > created), or evolved (vs accidental creations like mountains), the failures > tend to come in the FLAWS in the understanding of their creators. > > Alternatively, it is possible to encode just the flaws, which tend to > spread via cause and effect chains and easily step out of the apparent > structure. A really good example is where a designer with a particular > misunderstanding of something produces a design that is prone to certain > sorts of failures in many subsystems. Of course, these failures are the next > step in the cause and effect chain that started with his flawed education > and have nothing at all to do with the interrelationships of the systems > that are failing. > > Continuing... > > On 12/9/08, Matt Mahoney <[EMAIL PROTECTED]> wrote: >> >> Steve, the difference between Cyc and Dr. Eliza is that Cyc has much >> more knowledge. Cyc has millions of rules. The OpenCyc download is hundreds >> of MB compressed. Several months ago you posted the database file for Dr. >> Eliza. I recall it was a few hundred rules and I think under 1 MB. >> > > You have inadvertently made my point, that in areas of "inverse knowledge" > that OpenCyc with its hundreds of MBs of data still falls short of Dr. Eliza > with <<1% of that knowledge. Similarly, Dr. Eliza's structure would prohibit > it from being able to answer even simple questions regardless of the size of > its KB. This is because OpenCyc is generally concerned with how things work, > rather than how they fail, while Dr. Eliza comes at this from the other end. > > Both of these databases are far too small for AGI because neither has >> solved the learning problem. >> > > ... Which was exactly my point when I referenced the quadrillion dollars > you mentioned. If you want to be able to do interesting things for only ~$1M > or so, no problem IF you stick to an appropriate corner of the knowledge (as > Dr. Eliza does). However, if come out of the corners, then be prepared to > throw your $1Q at it. > > Note here that I am NOT disputing your ~$1Q, but rather I am using it to > show that the approach is inefficient, especially if some REALLY valuable > parts of what it might bring, namely, the solutions to many of the most > difficult problems, can come pretty cheaply, ESPECIALLY if you get your > proposal working.. > > Are we on the same page now? > > Steve Richfield > >> ------------------------------ >> *From:* Steve Richfield <[EMAIL PROTECTED]> >> *To:* [email protected] >> *Sent:* Tuesday, December 9, 2008 3:06:08 AM >> *Subject:* [agi] Machine Knowledge and Inverse Machine Knowledge... >> >> Larry Lefkowitz, Stephen Reed, et al, >> >> First, Thanks Steve for your pointer to Larry Lefkowitz, and thanks Larry >> for so much time and effort in trying to relate our two approaches.. >> >> After discussions with Larry Lefkowitz of Cycorp, I have had a bit of an >> epiphany regarding machine knowledge that I would like to share for all to >> comment on... >> >> First, it wasn't as though there were points of incompatibility between >> Cycorp's idea of machine knowledge and that used in DrEliza.com, but rather, >> there were no apparent points of connection. How could two related things be >> so completely different, especially when both are driven by the real world? >> >> Then it struck me. Cycorp and others here on this forum seek to represent >> the structures of real world domains in a machine, whereas Dr. Eliza seeks >> only to represent the structure of the malfunctions within structures, while >> making no attempt whatever to represent the structures in which those >> malfunctions occur, as though those malfunctions have their very own >> structure, as they truly do. This seems a bit like simulating the "holes" in >> a semiconductor. >> >> OF COURSE there were no points of connection. >> >> Larry pointed out the limitations in my approach - which I already knew, >> namely, Dr. Eliza will NEVER EVER understand normal operation when all it >> has to go on are *AB*normalities. >> >> Similarly, I pointed out that Cycorp's approach had the inverse problem, >> in that it would probably take the quadrillion dollars that Matt Mahoney >> keeps talking about to ever understand malfunctions starting from the wrong >> side (as seen from Dr. Eliza's viewpoint) of things. >> >> In short, I see both of these as being quite valid but completely >> incompatible approaches, that accomplish very different things via very >> different methods. Each could move toward the other's capabilities given >> infinite resources, but only a madman (like Matt Mahoney?) would ever throw >> money at such folly. >> >> Back to my reason for contacting Cycorp - to see if some sort of web >> standard to represent metadata could be hammered out. Neither Larry nor I >> could see how Dr. Eliza's approach could be adapted to Cycorp, and further, >> this is aside from Cycorp's present interests. Hence, I am on my own here. >> >> Hence, it is my present viewpoint that I should proceed with my present >> standard to accompany the only semi-commercial program that models * >> malfunctions* rather than the real world, somewhat akin to the original >> Eliza program. However, I should prominently label the standard and >> appropriate fields therein appropriately so that there is no future >> confusion between machine knowledge and Dr. Eliza's sort of inverse machine >> knowledge. >> >> Any thoughts? >> >> Steve Richfield >> >> ------------------------------ >> *agi* | Archives <https://www.listbox.com/member/archive/303/=now> >> <https://www.listbox.com/member/archive/rss/303/> | >> Modify<https://www.listbox.com/member/?&;>Your Subscription >> <http://www.listbox.com/> >> ------------------------------ >> *agi* | Archives <https://www.listbox.com/member/archive/303/=now> >> <https://www.listbox.com/member/archive/rss/303/> | >> Modify<https://www.listbox.com/member/?&;>Your Subscription >> <http://www.listbox.com/> >> > > ------------------------------ > *agi* | Archives <https://www.listbox.com/member/archive/303/=now> > <https://www.listbox.com/member/archive/rss/303/> | > Modify<https://www.listbox.com/member/?&;>Your Subscription > <http://www.listbox.com/> > ------------------------------ > *agi* | Archives <https://www.listbox.com/member/archive/303/=now> > <https://www.listbox.com/member/archive/rss/303/> | > Modify<https://www.listbox.com/member/?&;>Your Subscription > <http://www.listbox.com/> > ------------------------------------------- agi Archives: https://www.listbox.com/member/archive/303/=now RSS Feed: https://www.listbox.com/member/archive/rss/303/ Modify Your Subscription: https://www.listbox.com/member/?member_id=8660244&id_secret=120640061-aded06 Powered by Listbox: http://www.listbox.com
