On Wed, Mar 14, 2018 at 8:29 PM, Ben Goertzel <[email protected]> wrote:
> Let me preface this by noting that I am really psyched we are having this > sort of discussion ;) ... > I agree with Ben; and have nothing to add to his replies. So below is a different slant on things. > > > - Let's imagine I know 10000 people, and I'm asked if I know a family in > > which the difference in ages of two children is larger than 15 years (a > wife > > is taller than a husband more than by 20 cm, or whatever you want). Such > > dataset and query are essentially the same as in our example with video > > frames and bounding boxes, and PM behavior will be the same. Should > > information about these people be stored in the long-term memory? Sure. > > Should we use space-server to deal with this query? I guess, no. By what > > means should this query be answered? > Umm, except you don't know that many people. Lets reduce it to the number of people you actually know. Personally, I would not be able to answer that question, not without a lot of work. I would have to spend a lot of time trying to think of everyone I know -- that alone could take hours or more. Then I would have to imagine their ages or heights. Try to imagine how much 20 centimeters is, in ordinary social situations. Find a ruler, stare at it for a while. Try to imagine those two people standing next to one another, mentally painting a ruler next to them. If you wanted an accurate answer it would take me a day. Its not a question that any normal human can answer. And forget the 10 thousand number. No human can do that, not from memory. The correct answer is: use a mental prosthesis. Write a database, populate the database with statistics about 10000 people, and perform an SQL query on it. Bingo. Fast. Easy. So the real question is: How does AGI go about building a database? How can we teach opencog about databases and about programming, that, when faced with such a question, it would be able to surf the net, evaluate competing sql products, pick one, download it, read the API documentation, write some code, stuff it with info about 10000 people, write an SQL query, and then provide the answer? *That* is what I want opencog to be able to do. Again, the real question is: how is opencog going to learn about relational algebras and what SQL is and how to use it? How to surf the net? How is it going to learn how to normalize database tables? That's the problem we have to solve. > So this is an arithmetic query, rather than a spatial query -- Certainly for a handful of special cases, (such as this) we could write special-case code. Size, age, nearness/distance relations are all important. So is next-to, behind, is-a-part-of. We need code to handle all those cases fairly quickly, fairly effectively. > > > - I'm asked, "Do you remember a scene in any film, in which a planet was > > inside a luggage locker"? My brain says: "Yeah, I remember!". You must be watching some crazy films! > But if I'm > > asked: "Do you remember a scene in a film, in which there was a flower > pot > > more than 30 cm above a bed?"... Huh, maybe, I need to think... My brain > > will not go into a loop for 10 billion years. Perhaps you intended to talk about the pattern matcher, but that is perfectly silly. Don't build a system like that. This is a solvable problem, and the solution is actually quite easy. Computer engineers have been solving this particular problem since the invention of computers. Its not a valid complaint. > > > You can say: just don't use PM for such queries. Why not? For certain kinds of basic prepositional queries, such as taller, closer, larger, next-to, above, behind, is-a-part-of, is related-to -- we need a good, effective query system for those, Currently, the pattern matcher cannot do many or even most of these, but the engineering needed to make it effective is not hard. The needed changes, improvements, enhancements are straight-forward. Its a red herring, to argue about NP-completeness. AGI-wise, this is NOT where the hard problem lies. It is work that we need to do for opencog, but that's the easy part. Some clever systems programmers, with a bit of scientific guidance, could assemble a reasonable practical system. Self-driving cars already do a lot./most of this kind of stuff, in real time(!) Even though driving a car, as a task, is NP-complete! This ain't rocket science. Its not where the hard part lies. > > My gut reaction is it's perhaps often better to think about PLN > backward chainer (which uses the > URE which uses the PM)..... I.e. often, instead of thinking about > custom callbacks to the PM, > one can think about custom domain-specific inference rules to use within > PLN... > This is more interesting. Nil and I were talking, and I believe that a very reasonable approach would be to approximate PLN by a fast crisp-logic chainer, and then compute probabilities by sampling over crisp-logic inputs to the chainer. Yes, this is combinatorial, but fast boolean solver exist and can crank through the alternatives quite quickly. Taking the average of these would provide a reasonable approximation to have PLN+attention-allocation is trying to do. Its a different algo, though. Its a simpler special-case of probabililisic programming, something I thought Alexy was good at. ... Creating a fast crisp solver that takes averages over the same kinds of inputs that the URE backward chainer takes ... its a non-trivial engineering task, requires a lot of code .. but, again . its an engineering task. It seems fairly straight-foreward. There are various interesting science questions in there, but it seems doable. But, again, this is also not where the hard problem of AGI lies. --linas -- cassette tapes - analog TV - film cameras - you -- You received this message because you are subscribed to the Google Groups "opencog" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/opencog. To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/CAHrUA34tU2T2mS1Bs71QR2GVo3aU7HAHkrwY59oGOsGedLBPDA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
