> > Could you explain (with enough detail) how it is more natural? I am very > much interested in allowing natural expressivity in the atomspace. >
Here is an example https://github.com/trueagi-io/hyperon/blob/0534d9590e8e0bc25967d6810bd525b415e2d19f/python/tests/test_minecraft.py#L80-L101. The task here is to craft wooden-pickaxe in minecraft, but just see how Vitaly introduces "if" into the knowledge base: (= (if True $then $else) $then) > (= (if False $then $else) $else) ср, 28 апр. 2021 г. в 21:37, Linas Vepstas <[email protected]>: > > > 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 > <https://groups.google.com/d/msgid/opencog/CAHrUA35OTMSf65_M9zOtCjjS9R432HfdbgYU8Q8uOjmxT05g0Q%40mail.gmail.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-txCaEGWAAfeXpfNTvfWtoTphwZi4JMcjWS%3Dmz%3DmgmeKA%40mail.gmail.com.
