OK, Some AI theory, below. Maybe Ben, who has driven a lot of this, can pipe up to clarify. Maybe Matt Ikle might have something to add.
On Mon, May 24, 2021 at 1:23 PM Michele Thiella <[email protected]> wrote: > Great I really needed some monitoring! I'll take a look at these numbers! > > Another thing I forgot: is there a way to get the inference tree related > to a solution obtained from BC? > The C++ code contains "BIT" structures, which hold the inference tree. I don't know how to access it. I saw that there was a scheme code somewhere but I didn't understand how it > worked. Thank you > > PS. Blocksword Problem (very briefly) = some blocks on table, 4 action > (pick-up, put-down, stack: block 1 above block 2, unstack: pick-up block 1 > which is above block 2), objective: to build a tower of blocks > OK. So this exposes a subtle issue in AI. So, 1970's-onward GOFAI used crisp-logic, true-false values to determine the satisfiability of any given inference, deduction, rule. etc. Somewhere along the way, it was realized that this is not enough, and that one needed something like "fuzzy logic" or "Bayesian probability" or even "non-montonic reasoning" or stuff like that, to obtain suitable inferences in many real-world situations. Ben's PLN (Probabilistic Logic Networks) was proposed in that context, in that environment. It consists of a collection of rules, generally resembling those of conventional predicate logic (as found in textbooks, wikipedia pages, etc.) except that they are modified to incorporate probability, generally resembling those of Bayesian statistics, (again, as found in conventional textbooks) plus an extra parameter, the "confidence", to model/control the spread of uncertainty. The grand dream here is that this is enough to handle real-world logic and real-world reasoning. The technical difficulty here is combinatoric explosion: tracking probabilities means having to track many many more possibilities during inference: gazillions of inference trees. Devices like "attention allocation" and even "openpsi" are invented to limit and control the search space. (Aside: you asked about "scheme" -- the inference rules are encoded in scheme. The actual inference engine is written in C++. The software engineering goal was to separate the mechanics of inference from the specific weights, formulas, inputs, outputs of the rules. That's why the inference tree is in C++, not in scheme.) How well does this work out in real life? Well, I claim that blocks-world exposes some fundamental failings, mismatches, mis-understandings of a probabilistic approach. One is "obvious": for perfect blocks-world physics, say, minecraft, where blocks stack perfectly and never fall down, you don't need probabilistic reasoning. In this sense, using PLN to solve blocksworld problems is grossly inefficient and inappropriate. A crisp logic solver and motion planner should be enough. God knows, there must be a zillion of these: this is firmly entrenched in mainstream textbook GOFAI. As to whether any of them are on github, are maintained, and actually work.. I would not be surprised if the answer is zero. (such code is difficult to maintain, yet not commercially $$$ interesting. So no one does it.) In the real world, you cannot stack blocks arbitrarily highy: you can't stack them evenly. They are not perfect cubes. There's friction and wind gusts and grains of sand. Towers loose balance and fall down. So, how well does probabilistic reasoning handle this situation? Well, but it doesn't. The generic stacking problem is still best addressed via crisp-logic motion planning. The physics of imperfect cubes becomes a mechanical engineering problem: what is the best way to model non-parallel cub faces? off-center stacking? a center of mass that is not at the center? Wobbliness due to non-flat faces? You can't just say "probability" or "fuzzy logic" and get any kind of reasonable answer. You really are dealing with a mechanical engineering problem, here. PLN is not a mechanical-engineering solver. Consider the stacking of even one cube on top another. The result depends on how slippery the faces are, and the local direction of gravity. You can't stack cubes on the side of a hill. I'm grasping for something that is hard to put into words. The "axes of representation" of probability do not line up with the "axes of mechanical motion". Although one might be able to say that "if two blocks are stacked with a center-of-mass offset of x, then the probability of falling over is p", this statement is not composable: you can't say "ah ha, therefore, the probability for stacking two blocks is (some formula involving p)" Non-composable statements cannot be used in inference chains. Yet, mechanical engineering (or, at least, mechanical reasoning) is very much about inference chains. You could say: "we've got the wrong inference rules" -- the inference rules should be about inclined planes and levers, pulleys and ropes (blocks and girders and i-beams...). Walking this path, one very quickly reinvents the history of CAD/CAM software. We know where that goes and its not really AI. So what is PLN good for? I honestly don't know. I know that it can solve a collection of toy probabilistic inference models, but I am not aware of any real-world inference problems that can be mapped into that. I am trying to grasp ahold of an idea here, but none of my words above directly grab it. There is a certain grammar of reasoning. This grammar is crisp. For mechanical engineering, this grammar can be attached to differential equations. The combination of this can be replaced by rules-of-thumb, which are "crisp", while always concluding with "it depends". To conclude: 1) you should study all the usual crisp-logic reasoning and motion-planning and constraint-satisfaction algorithms. This provides an important background. For blocks-world, you might want to find and employ (or construct) a crisp-logic motion planner. 2) You should study probability and machine learning. This is also important. If/when you get past the above, I invite you (or anyone else) to join me in the exploration of how to extract inference rules from observations. I have an inkling of how to do this. I am trying to do it in the github project https:://github.com/opencog/learn but it is extremely difficult. The goal of the project would be to (for example) extract the rules of mechanical engineering by playing with blocks. The discovery of the rules of thumb of stacking imperfect blocks. --linas > > Michele > Il giorno lunedì 24 maggio 2021 alle 20:08:04 UTC+2 linas ha scritto: > >> I know nothing about the blocksworld problem, so I cannot help directly. >> Indirectly, you can use (cog-report-counts) to monitor the number of atoms >> in the atomspace -- I typically see an average of about 1KB or 2KB per >> atom. So, a few GB is enough for millions of atoms, normally. This will >> give you a hint of what might be going on there. >> >> The only "problem" is that URE uses some temporary atomspaces; those are >> not included in the count. The URE also mallocs structures that are not >> part of the atomspace. >> >> There is a third but unlikely issue -- guile garbage collection not >> running often enough. Take a look at (gc-stats) to get info, and (gc) to >> manually run garbage collection. It's unlikely this is a problem, but there >> were issues with older guile-- say, version 2.0. I'm hoping you are on >> version 3.0, or at least version 2.2. >> >> Perhaps @Nil Geisweiller can help with URE ram issues. >> >> --linas >> >> On Mon, May 24, 2021 at 11:27 AM Michele Thiella <[email protected]> >> wrote: >> >>> Hello everyone, >>> >>> Finally, I was able to pass the first planning test for the blocksword >>> problem, using ContextLinks. >>> (For now, it has some ad-hoc things/rules and others that are missing) >>> >>> But, as long as I look for a column of 3 blocks everything is fine and >>> the times for the BC are very short, >>> while when I look for a column of 4 or more I go into RAM overflow. >>> Unfortunately, I'm on Linux on an external sdd and the Swap area is >>> there. >>> Consequently, with a goal of 4 blocks, I use more than 8 Giga (I only >>> have 8) and it starts swapping but the time gets longer and I can't finish >>> the execution. >>> >>> Would anyone be able to run the test_pickup_stack.scm file? and share me >>> the log file? >>> it's in my repo: https://github.com/raschild6/blocksworld_problem >>> Thanks a lot in advance! >>> (There should be no errors, just do (load >>> "path/to/file/test_pickup_stack.scm") in the telnet shell. Report me if >>> there is something wrong, thanks!) >>> >>> I'm playing with the URE parameters to see if I can optimize the >>> inference. >>> (extra question) is there a URE parameter to terminate at the first BC >>> solution found? >>> >>> Michele >>> >>> -- >>> >> 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 view this discussion on the web visit >>> https://groups.google.com/d/msgid/opencog/4f5a4761-3ad7-4d6c-87d6-f5bb1f16f993n%40googlegroups.com >>> <https://groups.google.com/d/msgid/opencog/4f5a4761-3ad7-4d6c-87d6-f5bb1f16f993n%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >> >> >> -- >> Patrick: Are they laughing at us? >> Sponge Bob: No, Patrick, they are laughing next to us. >> >> >> -- > 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 view this discussion on the web visit > https://groups.google.com/d/msgid/opencog/bcebe289-87a8-4290-8ea3-66644ae8b30fn%40googlegroups.com > <https://groups.google.com/d/msgid/opencog/bcebe289-87a8-4290-8ea3-66644ae8b30fn%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- Patrick: Are they laughing at us? Sponge Bob: No, Patrick, they are laughing next to us. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/opencog/CAHrUA34nqJEJ7x1zT9eUx0rxAbtDsZL-2Mp5n_OY_BOzRrnHgg%40mail.gmail.com.
