Ah! Thank you Anatoly! Now we are making progress.
On Wed, May 26, 2021 at 12:32 PM Anatoly Belikov <[email protected]> wrote: > There is some collision in terminology. > The classical planning problem(like blockworld) is defined by a tuple <S, > s0, S_goal, A, f>, where S is set of states, s0 - initial state, S_goal - > set of goal states, A - set of actions, f - state transition function, f > accepts a state and an action and outputs a state. The task is to find a > sequence of (state, action) pairs leading from the initial state to the > goal state. > Yes, that seems like a good definition. I believe that many problems are similar, if not the same: e.g. theorem-proving, where `f` consists of axioms and inference rules. The intent was that the URE would be able to able to solve these kinds of problems, using an API that is close to the above. Crisp solvers such as the Potsdam ASP solver are good at this (well, you'd have to write a bunch of code to convert the above form into ASP, which is a good exercise, but is not basic research). The task w.r.t. the atomspace is how to represent S, A, f using Atomspace structures, in some compact reasonable, flexible way. For blocksworld, the size of S is literally astronomical, so `f` cannot be a lookup table in the literal sense. Rather, it has to be encoded to accept only that tiny fraction of the grand-total S that we are working with. Unlike FSM states in planning have structure which enables informed search. > And there are too many states, if we work in a boolean domain like > blockworld then there are 2^(bit-length of the state), we can't build FSM > for such problems. > Yes, absolutely. I did not mean to imply this. I was attempting to say that the representation of the state transition function used in one demo/example should be similar to, or the same as the representation used in other demos/examples, and both of those should align with whatever the URE would accept as valid. (FWIW, The OpenPsi codebase has a representation for `f`, but it has changed several times. The OpenPsi codebase solves the same kinds of problems as the URE, but using a radically different approach. It's actually quite elegant and interesting... It would be nice if it used the same representation.) > So I meant to use ContextLinks to represent elements of S. While state > transition rules in Michel's example are represented by BindLinks. There is > one BindLink for each action, which is unlike the definition, maybe it > would be better to have one BindLink for the computation of the next state, > but I don't see a simple way to write it in pure atomese either. So I > suggest working with ListValue for states + EvaluationLinks with grounded > predicates. > Two remarks. First remark 1) BindLink is an "active" link, and not a "knowledge representation" link. So, for example, implication, if(p) then q; can be presented with the ImplicationLink P Q. That's it -- nothing happens, because ImplicationLinks don't "do anything". You can also represent it as BindLink P Q which is "equivalent" to ImplicationLink for static knowledge representation. The difference is that you can actually execute BindLink, and it will change the contents of the atomspace. The need to execute it has, over time, forced a complicated and sometimes-crufty syntax onto it: You must use VariableNodes, You must use PresentLinks, etc. etc. ImplicationLink does not have any of these arcane requirements. So, I still haven't glanced at Michele's code (maybe I should?), but what I am trying to say is that maybe one should not use BindLinks unless the intent is to actually run them. If the goal is to represent state transitions, then maybe ImplicationLink or ContextLink or something else is enough. Second remark: I don't see a simple way to write it in pure atomese > Ah! Well, this is exactly what experimentation is for. Try it, see what happens, and if it doesn't work, try figuring out why not. I can take a shot at a "pure Atomese" representation, but right now, I still don't quite understand what the issue is. You want .. what ... some way of specifying the "classical planning problem" in a fairly generic fashion, such that it works with this blocksworld thing? Can we do this by email? I don't want to sit by my lonesome, come up with something, write a dissertation on it, and then have no one pay attention or read it or care. So a one-step-at-a-time communal activity? --linas > For the reference: Lipovetzky, N. (2012). Structure and inference in > classical planning. > > ср, 26 мая 2021 г. в 20:16, Linas Vepstas <[email protected]>: > >> >> >> On Wed, May 26, 2021 at 5:08 AM Anatoly Belikov <[email protected]> >> wrote: >> >>> It was my suggestion to represent search states with ContexLinks, >>> somehow like that: >>> >> >> Did you mean "represent state transition rules"? A state transition rule >> has the form "if (lots of preconditions) then (a move to state1 is allowed)" >> >> I don't recall if we have any preferred or recommended way of writing >> those. There is a sequence of four state-machine demos, each building on >> the last: >> >> >> https://github.com/opencog/atomspace/blob/master/examples/pattern-matcher/fsm-basic.scm >> >> https://github.com/opencog/atomspace/blob/master/examples/pattern-matcher/fsm-full.scm >> >> https://github.com/opencog/atomspace/blob/master/examples/pattern-matcher/fsm-mealy.scm >> >> https://github.com/opencog/atomspace/blob/master/examples/pattern-matcher/markov-chain.scm >> >> I notice that the last three use ContextLink to represent state >> transition rules. This might be an abuse or misuse of ContextLinks. >> Certainly, the wiki page for them https://wiki.opencog.org/w/ContextLink >> suggests something very different. >> >> The four examples above were written before StateLink was invented, and >> before Values. They should be reviewed, and maybe re-written or >> modernized. Anatoly, would you care to do this? Maybe Michele could be a >> guinea pig, and tell us what's wrong or unclear about these demos? >> >> The nice thing about StateLink is that it is atomic: There can only ever >> be one; there are never accidentally two or zero, and it is thread-safe: >> even if multiple threads are all setting the state at the same time, there >> will always be just one. >> >> The "ugly thing" about StateLink is that its an Atom, and thus the >> fastest rate of change is limited by AtomSpace insertion, deletion, which >> is in the ballpark of 50K/second, depending on how old your CPU is and what >> language you are using (c++/python/scheme). Value changes are much much >> faster, I think in the 200K/second or 500K/second range. >> >> Certainly, the basic blocksworld can be represented as a kind of stateful >> system, and the goal of the URE would then be to find a sequence of moves >> to get from some position to another. We really should have a documented, >> maintained example for the "recommended way of doing this". Ideally, it >> would use the same kind of rule-style as the above four examples, so that >> all the demos are consistent. >> >> I have no clue why the URE is misbehaving.... is it being used >> incorrectly, or is it broken? Do I need to personally look at this? >> >> --linas >> >> >> >>> (ContexLink >>> (ConceptNode "state1") >>> (AndLink ( >>> (ConceptNode "state0") ; previous state >>> EvaluationLink (stv 0 1) >>> (PredicateNode "not-free") >>> (ConceptNode "block5"))) ; and so on, >>> here are all valid combinations of predicates and it's arguments like in >>> c++ planners i am familiar with. >>> >>> Now I believe it makes sense to represent the state using values, maybe >>> just with LinkValue and accessor functions. >>> The research direction might be the integration of heuristic function >>> into URE for selection of the next state to expand. >>> >> >>> ср, 26 мая 2021 г. в 01:39, Linas Vepstas <[email protected]>: >>> >>>> Let me balance my earlier theoretical remarks with some clarifications. >>>> >>>> -- Bindlinks are more-or-less pure crisp-logic things. Any single one >>>> gives a pure, crisp true/false result, and you can certainly write solvers >>>> with them. >>>> >>>> -- The PLN rules are ways of assembling them into inference trees with >>>> non-crisp probabilistic results. >>>> >>>> -- Anatoly's idea sounds like a good one to me. Anything you can do to >>>> limit the search space is always a good thing. Things like >>>> >>>> (PresentLink >>>> (InheritanceLink >>>> (VariableNode "?ob") >>>> (ConceptNode "object"))) >>>> >>>> can vastly speed the search by limiting it only to those ?ob's that are >>>> actually objects, instead of trying everything under the sun. This is very >>>> useful in intermediate steps, to avoid combinatoric explosion. >>>> >>>> -- I have no clue what ContextLinks are good for. That's a PLN thing. >>>> >>>> Linas. >>>> >>>> >>>> >>>> On Tue, May 25, 2021 at 10:11 AM Michele Thiella < >>>> [email protected]> wrote: >>>> >>>>> For now I have only added the ContentLinks and the rules to work with >>>>> to solve the BC of the blocksworld problem >>>>> (for example the put-down and unstack rules are missing). >>>>> >>>>> It is true that I do not take into account a full state when I do an >>>>> action. >>>>> This would make sense in a general case, so that any action that is >>>>> added is correct regardless of the others, because it is based only on the >>>>> state. >>>>> >>>>> Instead, the correctness of my current structure lies in the last >>>>> bindlink, the one that corresponds to the complete inference tree that >>>>> solves my goal. >>>>> The conditions for replacing VariableNodes with ConceptNodes are >>>>> accumulated among the various rules used in the tree. >>>>> So at the end the blocks will be stacked correctly and the result will >>>>> correspond to the probabilistic permutations of the n blocks on the table >>>>> taken at X (= number of blocks in my column) >>>>> >>>>> For now it works (except for this RAM problem), but the unstack and >>>>> put-down rules are not there, because they are actually not needed for >>>>> correct planning. >>>>> >>>>> I feel like I'm a bit cheating. >>>>> If the correct idea is to use a state it will be good to rewrite the >>>>> rules. >>>>> >>>>> Although, I didn't quite understand what the problem with my structure >>>>> is. >>>>> If I do BC I can't have partial solutions so I just need the final >>>>> bindlink to contain all the necessary conditions, I don't need them to be >>>>> verified for every rule. >>>>> >>>>> Certainly I have not explained well, perhaps because I have not >>>>> understood the matter well. >>>>> >>>>> Michele >>>>> Il giorno martedì 25 maggio 2021 alle 16:11:37 UTC+2 [email protected] >>>>> ha scritto: >>>>> >>>>>> You introduced ContextLinks, but it doesn't provide full state for >>>>>> each action. For example in pickup you create (EvaluationLink >>>>>> (PredicateNode "not-clear") (VariableNode "?ob")) for some object "?ob", >>>>>> but there are probably other objects that are not free. In c++ we can >>>>>> represent a state by boolean array. When applying some action we would >>>>>> copy >>>>>> the bit-vector of the previous state and modify some bits. You can >>>>>> emulate >>>>>> this behaviour by using ConceptNodes for states. You can store values of >>>>>> all boolean variables as properties of ConceptNode. You will have to >>>>>> rewrite preconditions to call to python or scheme function: >>>>>> >>>>>> ; precondition of pickup-action >>>>>> (AndLink >>>>>> (PresentLink >>>>>> (InheritanceLink >>>>>> (VariableNode "?state") >>>>>> (ConceptNode "state"))) >>>>>> (PresentLink >>>>>> (InheritanceLink >>>>>> (VariableNode "?ob") >>>>>> (ConceptNode "object"))) >>>>>> (EvaluationLink >>>>>> (GroundedPredicateNode "py: can_pickup"), >>>>>> ListLink( >>>>>> (VariableNode "?state") >>>>>> (VariableNode "?ob") >>>>>> ) >>>>>> ) >>>>>> >>>>>> in can_pickup you check if passed (state, object) pair satisfies the >>>>>> precondition. >>>>>> >>>>>> In ExectionOutputLink you can create a new ConceptNode for a new >>>>>> state by copying all the properties from the previous state with >>>>>> necessary >>>>>> changes. >>>>>> >>>>>> >>>>>> пн, 24 мая 2021 г. в 20:27, Michele Thiella <[email protected]>: >>>>>> >>>>>>> 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> >>>>>>> . >>>>>>> >>>>>> -- >>>>> 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/b0effc4c-a09e-4f55-a00c-a4e16bb17f24n%40googlegroups.com >>>>> <https://groups.google.com/d/msgid/opencog/b0effc4c-a09e-4f55-a00c-a4e16bb17f24n%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/CAHrUA37r38daLXGaN%2BJmYmm0KgDkacnV7a60pE%3D%2BE0M5DY7s4g%40mail.gmail.com >>>> <https://groups.google.com/d/msgid/opencog/CAHrUA37r38daLXGaN%2BJmYmm0KgDkacnV7a60pE%3D%2BE0M5DY7s4g%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-sWotMa6CPpMiUDMywDS0P-4FDji75YnNoS6M3jwoznyQ%40mail.gmail.com >>> <https://groups.google.com/d/msgid/opencog/CAFj%2Bw-sWotMa6CPpMiUDMywDS0P-4FDji75YnNoS6M3jwoznyQ%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/CAHrUA374OfZazwhmFjXseh0PRGN5NBwB1-6C6BdXLqkxx5gCtw%40mail.gmail.com >> <https://groups.google.com/d/msgid/opencog/CAHrUA374OfZazwhmFjXseh0PRGN5NBwB1-6C6BdXLqkxx5gCtw%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-tffYSK9cr9-en7EDqqmDi83nS%3DVRbfksRA1gf%3D00aopg%40mail.gmail.com > <https://groups.google.com/d/msgid/opencog/CAFj%2Bw-tffYSK9cr9-en7EDqqmDi83nS%3DVRbfksRA1gf%3D00aopg%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/CAHrUA37Bv25PypOkDem8tTA6N3pj0um3iiA3W21LRLMdRbcwyw%40mail.gmail.com.
