On Wed, Apr 28, 2021 at 5:17 AM Anatoly Belikov <[email protected]> wrote:
> Planning in my example didn't work due to certain assumptions being made > in URE. So let's say URE comes up with a nested bindlink like that: > > (ExecutionOutputLink(stack c a) > ... > (ExecutionOutputLink(stack a b) > (ExecutionOutputLink (pickup a) ) ) > > When it evaluates (stack c a) all atoms introduced by(stack a b) and > (pickup a) are present in the atomspace. So preconditions of stacking c on > a are not satisfied(a is both being 'held' and not 'held'). Probably there > is a simple workaround like placing all new facts into separate > ContextLink. Such simple planning problems are more naturally expressed in > new opencog-hyperon, > Could you explain (with enough detail) how it is more natural? I am very much interested in allowing natural expressivity in the atomspace. > so I lost the motivation for turning URE into a planner. > It is not at all obvious that the URE is a suitable platform for being a planner, anyway -- certainly, I would not have recommended that course of action. Planning can be viewed as a form of a constraint satisfaction problem, and the best constraint satisfaction solver that I know of is ASP, and specifically, the Potsdam solver. It is ideal for solving anything with crisp-boolean constraints. It does have some callbacks that should allow it to work with "fuzzy" constraints, but I have never tried these. I would like to advocate that, for planning and for constraint satisfaction, that the Potsdam solver should be integrated so that it can work with declarative data in the AtomSpace. This would make it "kind of like" the URE, but really quite different in many ways. I don't think that writing a new planner, either in Hyperion or in the atomspace, is a good idea. You will almost certainly create something that is 1000x slower than the best solvers available today. I want to illustrate this with a story. In the 1980's, electronic circuit simulation (i.e. chip design rule verification) was done using backward/forward chaining, similar to what the URE does. This was a very established technique, a multi-billion dollar industry with half-a-dozen vendors and another half-a-dozen in-house, proprietary solutions. In the late 80's, early 1990's, new planners and verifiers were created using SAT solvers. For chips of that era (about 500K transistors) the SAT solvers and the backward/forward chainers were about equal in performance. For chips with 2M transistors, the SAT solvers were 2x or 4x faster than the backward-forward chainers. For chips with >5M transistors, SAT was 10x, 20x faster than backward/forward, and the established chip-planner and verification houses were going bankrupt, because all of their customers had transitioned to the new SAT solver technology. This is a multi-billion dollar lesson in technology, and you ignore it at your own peril. Trying to reinvent your own planner is perhaps a good homework exercise to learn basic principles, but it is not sound software engineering. I very strongly advise against it. Now, PLN is a bit different. It was intended to work with probabilities, instead of crisp true/false values. This does make the problem harder. However, I think there are plenty of clever things one can do, without resorting to backward-forward chaining. Examples include: * Given some inputs and rules, assign random crisp true/false values to them (according to a probability distribution), and use ASP to solve the problem. Repeat 100 times, and take the average. The desired result is that average. * Most probabilistic problems can be split into two parts: one that is "almost crisp t/f" (the hard constraints) and the fuzzy, soft constraints. Use ASP to solve the crisp parts, and explore the fuzzy/soft parts systematically. Now, what I say above is "easy to say" but is "hard to do" -- implementing what I suggest is a large project. But then, in software, nothing is free. facebook and google and amazon employ thousands of engineers because writing good software is hard. Imagining that you can create a new planner out of thin air in a few months is not a realistic dream. Don't repeat history; learn from it. -- Linas Besides all planners rely on heuristics to guide the search, so even if you > will make URE work on this particular small example you'll have to do some > more work to integrate them in URE. > > > > ср, 28 апр. 2021 г. в 12:38, Michele Thiella <[email protected]>: > >> Hello Nil, hello Linas and hello everyone, >> >> First of all, Nil, I have spoken to my supervisors and unfortunately I >> will not be able to develop your ROCCA project. >> I'll try to follow the developments, since you explained to me how the >> code works (thanks again). >> >> Instead, I focus on solving the blocksworld problem (and then expand the >> project by adding communication) >> So, I'm studying how URE inference works. >> My test repository can be found here: >> https://github.com/raschild6/blocksworld_problem >> >> I don't understand what I'm doing wrong .. >> >> - Why the backward chaining fails to resolve the goal? >> - Also, I think I don't quite understand how fuzzy conjunction >> introduction and elemination rules work. >> >> I have other questions related to the URE log but for now I would like to >> understand these. >> >> (I don't know if it's better to open a new conversation) >> Thanks again for your help, sorry for the inconvenience! >> >> 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/2680e980-547d-46e2-8404-d272a25d2659n%40googlegroups.com >> <https://groups.google.com/d/msgid/opencog/2680e980-547d-46e2-8404-d272a25d2659n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- > 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/CAFj%2Bw-tCpU-iRkAjUxEk_EbKHovCq84p%2B%3D0B6EQuiNggF5D16Q%40mail.gmail.com > <https://groups.google.com/d/msgid/opencog/CAFj%2Bw-tCpU-iRkAjUxEk_EbKHovCq84p%2B%3D0B6EQuiNggF5D16Q%40mail.gmail.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/CAHrUA35OTMSf65_M9zOtCjjS9R432HfdbgYU8Q8uOjmxT05g0Q%40mail.gmail.com.
