Backward Chainer performance difference problem

[Alexander Gabriel]

Hi guys!

I've run into a performance problem.

When I run the backward chainer with this query:

(GetLink 

  (VariableList 

    (TypedVariableLink (VariableNode "picker") (TypeNode "ConceptNode")) 

    (TypedVariableLink (VariableNode "human") (TypeNode "ConceptNode")) 

    (TypedVariableLink (VariableNode "place1") (TypeNode "ConceptNode")) 

    (TypedVariableLink (VariableNode "origin") (TypeNode "ConceptNode")) 

    (TypedVariableLink (VariableNode "destination") (TypeNode "ConceptNode"))) 

  (AndLink 

    (InheritanceLink (VariableNode "picker") (VariableNode "human")) 

    (StateLink (ListLink (VariableNode "picker") (PredicateNode "called robot")) (ConceptNode "FALSE"))

    (StateLink (ListLink (VariableNode "picker") (PredicateNode "seen_picking")) (ConceptNode "FALSE"))

    (StateLink (ListLink (VariableNode "picker") (PredicateNode "movement")) (ConceptNode "APPROACHING")) 

    (StateLink (VariableNode "picker") (VariableNode "place1"))

    (EvaluationLink (PredicateNode "leads_to") (ListLink (VariableNode "place1") (VariableNode "origin")))

    (StateLink (ConceptNode "Thorvald_001") (VariableNode "origin"))

    (EvaluationLink (PredicateNode "leads_to") (ListLink (VariableNode "origin") (VariableNode "destination"))) 

  )

)

It takes only 0.004 seconds on my database.

But if I run the same query without the encompassing GetLink

  (AndLink 

    (InheritanceLink (VariableNode "picker") (VariableNode "human")) 

    (StateLink (ListLink (VariableNode "picker") (PredicateNode "called robot")) (ConceptNode "FALSE"))

    (StateLink (ListLink (VariableNode "picker") (PredicateNode "seen_picking")) (ConceptNode "FALSE"))

    (StateLink (ListLink (VariableNode "picker") (PredicateNode "movement")) (ConceptNode "APPROACHING")) 

    (StateLink (VariableNode "picker") (VariableNode "place1"))

    (EvaluationLink (PredicateNode "leads_to") (ListLink (VariableNode "place1") (VariableNode "origin")))

    (StateLink (ConceptNode "Thorvald_001") (VariableNode "origin"))

    (EvaluationLink (PredicateNode "leads_to") (ListLink (VariableNode "origin") (VariableNode "destination"))) 

  )

It takes a whooping 5 seconds. No idea why.

My intuition is that this is a bug. I assume we have to solve whatever is in the outgoing set of the GetLink in order to return the result for the GetLink and so the outgoing set can be computed in less than 0.004 seconds.

Anyway, it seems I have to forgo the use of the GetLink because I have to add another condition

(AbsentLink (StateLink (VariableNode "person2"), (VariableNode "destination")))

to make sure that there is nobody at the destination and the waypoint is free. And adding this only works if I don't use the wrapping GetLink, my guess is that adding the GetLink doesn't give any results because there is no grounding for (VariableNode "person2") if there is nobody at the waypoint.

The 5 seconds are way too long for my application though.

Is there a way to exclude a variable from being considered by the GetLink? I tried to exclude it from the GetLink's VariableList, but that didn't work.

Thanks for your help!

Best regards,

Alex

[Linas Vepstas]

Nil needs to examine/explain that one, I don't know.

My intuition is that this is a bug. I assume we have to solve whatever is in the outgoing set of the GetLink in order to return the result for the GetLink and so the outgoing set can be computed in less than 0.004 seconds.

The pattern matcher simply performs a graph-traversal, filling in the blanks. If you had a million humans in your DB, it might take longer (not a million times longer, but ... longer).

Anyway, it seems I have to forgo the use of the GetLink because I have to add another condition

(AbsentLink (StateLink (VariableNode "person2"), (VariableNode "destination")))

to make sure that there is nobody at the destination and the waypoint is free. And adding this only works if I don't use the wrapping GetLink, my guess is that adding the GetLink doesn't give any results because there is no grounding for (VariableNode "person2") if there is nobody at the waypoint.

Oh, that's interesting. My knee-jerk reaction is that GetLink should have worked with AbsentLink, but I'm also certain there is no unit test for this, and so am not surprised there's a bug.  This has an obvious solution: Get should not report variables that can't be grounded. Open a bug report; I'll look at it the next few days. This is fixable; and its not that hard.

The 5 seconds are way too long for my application though.

That is a distinct issue with the backward chainer: again, that one is for Nil to follow through on.

Is there a way to exclude a variable from being considered by the GetLink? I tried to exclude it from the GetLink's VariableList, but that didn't work.

Open a bug report (against atomspace). If you can cut-paste a full example into the bug report, that would be best. 

-- linas

Thanks for your help!

Best regards,

Alex

--
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 opencog+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/41de6c82-bf49-4dc0-bc3f-9773ac3973ad%40googlegroups.com.

--

cassette tapes - analog TV - film cameras - you

[Nil Geisweiller]

Hi Alex,

If that get link is the target of your query, then you're merely asking
the backward chainer to infer the TV of a constant term (that get link).
I doubt that is what you are after.

> |
>
> It takes only 0.004 seconds on my database.

Yeah, it likely doesn't find any rule that it can apply on that target,
and thus abort after all failing unifications.

>
> But if I run the same query without the encompassing GetLink
> |
>   (AndLink
>     (InheritanceLink (VariableNode "picker") (VariableNode "human"))
>     (StateLink (ListLink (VariableNode "picker") (PredicateNode "called
> robot")) (ConceptNode "FALSE"))
>     (StateLink (ListLink (VariableNode "picker") (PredicateNode
> "seen_picking")) (ConceptNode "FALSE"))
>     (StateLink (ListLink (VariableNode "picker") (PredicateNode
> "movement")) (ConceptNode "APPROACHING"))
>     (StateLink (VariableNode "picker") (VariableNode "place1"))
>     (EvaluationLink (PredicateNode "leads_to") (ListLink (VariableNode
> "place1") (VariableNode "origin")))
>     (StateLink (ConceptNode "Thorvald_001") (VariableNode "origin"))
>     (EvaluationLink (PredicateNode "leads_to") (ListLink (VariableNode
> "origin") (VariableNode "destination")))
>   )
> |

Ah, it's a completely different query, one where the backward chainer
tries to find assignments of the free variables of a closed term.

> Anyway, it seems I have to forgo the use of the GetLink because I have
> to add another condition
> |
> (AbsentLink (StateLink (VariableNode "person2"), (VariableNode
> "destination")))
> |

The backward chainer does not support as of today targets containing
virtual links. I have some ideas of how to at least partially support it
but it hasn't been implemented yet.

> The 5 seconds are way too long for my application though.

If you add a type declaration (I believe the python bindings allow you
that), it should speed up the reasoning as well.

> Is there a way to exclude a variable from being considered by the
> GetLink? I tried to exclude it from the GetLink's VariableList, but that
> didn't work.

If such variable is not in the variable declaration it will be treated
as constant (if that's what you want).

Nil

>
> Thanks for your help!
>
> Best regards,
> Alex
>

> --
> 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 opencog+u...@googlegroups.com

> <mailto:opencog+u...@googlegroups.com>.

> To view this discussion on the web visit
> https://groups.google.com/d/msgid/opencog/41de6c82-bf49-4dc0-bc3f-9773ac3973ad%40googlegroups.com

> <https://groups.google.com/d/msgid/opencog/41de6c82-bf49-4dc0-bc3f-9773ac3973ad%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Alexander Gabriel]

So what happens is the pattern matcher fills the blanks according to what it can do and the chainer than reports the TV of that result. Yes, that doesn't scale to what I intend to do.

 

The backward chainer does not support as of today targets containing
virtual links. I have some ideas of how to at least partially support it
but it hasn't been implemented yet.

Oh, that wasn't obvious to me. But it explains many of the problems I had with truth value assignment I guess.

 

If you add a type declaration (I believe the python bindings allow you
that), it should speed up the reasoning as well.

What to do you mean? Create a new Atom type as a subtype of ConceptNode? I haven't seen a way on how to do that..

TypedVariables I already have as you can see.

 

> Is there a way to exclude a variable from being considered by the
> GetLink? I tried to exclude it from the GetLink's VariableList, but that
> didn't work.

If such variable is not in the variable declaration it will be treated
as constant (if that's what you want).

 Which Variable declaration do you mean? The GetLink's? The BackwardChainer's?

If I exclude it from both I get:

terminate called after throwing an instance of 'opencog::InvalidParamException'

  what():  The variable (VariableNode "person2") does not appear (unquoted) in any clause! (/home/rasberry/git/atomspace/opencog/atoms/pattern/PatternLink.cc:508)

Aborted (core dumped)

If I exclude it from the GetLink I get:

Results:

(SetLink (SetLink (ListLink (ConceptNode "alice") (ConceptNode "place1") (ConceptNode "place3")) (ListLink (ConceptNode "alice") (ConceptNode "place1") (ConceptNode "place2"))))

Details:

--------------------------

Result Truth: (stv 1.000000 0.000000)

Result:

(ListLink (ConceptNode "alice") (ConceptNode "place1") (ConceptNode "place3"))

------------------------

Result Truth: (stv 1.000000 0.000000)

Result:

(ListLink (ConceptNode "alice") (ConceptNode "place1") (ConceptNode "place2"))

Which is wrong as it should only report place3 since there is a person present at place2.

If I exclude it only from the chainer I get:

Results:

(SetLink)

Which is wrong as it should report place3 where there is no person present.

Best,

Alex

[Nil Geisweiller]

On 3/2/20 11:27 AM, Alexander Gabriel wrote:
> So what happens is the pattern matcher fills the blanks according to
> what it can do and the chainer than reports the TV of that result. Yes,
> that doesn't scale to what I intend to do.

No, it typically doesn't need to execute the link it is doing inference
on, rather it runs inference trees constructed from inference rules that
produces the target, including updating its TV. Whether this is fast or
slow depends on the inference trees, not so much the target.

> If you add a type declaration (I believe the python bindings allow you
> that), it should speed up the reasoning as well.
>
>
> What to do you mean? Create a new Atom type as a subtype of ConceptNode?
> I haven't seen a way on how to do that..
> TypedVariables I already have as you can see.

In case there's some confusion to clear up, maybe read the following

https://wiki.opencog.org/w/Unified_rule_engine
https://wiki.opencog.org/w/URE_Configuration

and go through some examples here

https://github.com/opencog/ure/tree/master//examples/ure

for instance the frog example show an example of variable declaration in
a backward chainer query

https://github.com/opencog/ure/tree/master/examples/ure/frog#backward-chainer

Unfortunately no example is provided in python.

Nil

> --
> 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 opencog+u...@googlegroups.com
> <mailto:opencog+u...@googlegroups.com>.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/opencog/f7de287a-e2db-43d6-90c4-01649842f08d%40googlegroups.com
> <https://groups.google.com/d/msgid/opencog/f7de287a-e2db-43d6-90c4-01649842f08d%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Alexander Gabriel]

No, it typically doesn't need to execute the link it is doing inference
on, rather it runs inference trees constructed from inference rules that
produces the target, including updating its TV. Whether this is fast or
slow depends on the inference trees, not so much the target.  

I'm not sure I understand, don't the inference trees result from the interaction between the target and the rulebase?

 

 

>     If you add a type declaration (I believe the python bindings allow you
>     that), it should speed up the reasoning as well.

 

Most of the atoms I add are ConceptNodes (200-300 at the moment and almost all of them are places), so restricting chaining to those doesn't help me much. In any case I'm already doing that.

 

for instance the frog example show an example of variable declaration in
a backward chainer query

https://github.com/opencog/ure/tree/master/examples/ure/frog#backward-chainer

Yes, that's the same kind of variable declaration that I use above. The VariableList from the GetLink I also give to the backward chainer.

What happens for different variations of variable declarations provided for the getlink and the backward chainer, I've detailed in the last post.

Best,

Alex

[Linas Vepstas]

On Mon, Mar 2, 2020 at 3:27 AM Alexander Gabriel <goo...@4d6.de> wrote:

If I exclude it from both I get:

terminate called after throwing an instance of 'opencog::InvalidParamException'

  what():  The variable (VariableNode "person2") does not appear (unquoted) in any clause! (/home/rasberry/git/atomspace/opencog/atoms/pattern/PatternLink.cc:508)

Aborted (core dumped)

This is a bug -- an exception should never end with a core dump; the system should just report the exception and return to the python command line (or, alternately, run the python exception handler, if any) . Could you please report this as a bug?

-- linas

[Alexander Gabriel]

If I exclude it from both I get:

terminate called after throwing an instance of 'opencog::InvalidParamException'

  what():  The variable (VariableNode "person2") does not appear (unquoted) in any clause! (/home/rasberry/git/atomspace/opencog/atoms/pattern/PatternLink.cc:508)

Aborted (core dumped)

This is a bug -- an exception should never end with a core dump; the system should just report the exception and return to the python command line (or, alternately, run the python exception handler, if any) . Could you please report this as a bug?

Hi Linas, 

My guess is that any exception thrown in C will end in a python core dump. At least I haven't encountered any python Exceptions that I can remember.

Best, 

Alex

[Linas Vepstas]

On Mon, Mar 2, 2020 at 3:27 AM Alexander Gabriel <goo...@4d6.de> wrote:

So what happens is the pattern matcher fills the blanks according to what it

... according to what it can find in the current atomspace. If nothing can be found, it returns the empty set.

 

Yes, that doesn't scale to what I intend to do.

I'd like to know why you think that. (what you are trying to do). I'm interested in understanding and solving scaling problems.

 

Ah, it's a completely different query, one where the backward chainer
tries to find assignments of the free variables of a closed term.

This was unclear to me, so let me clarify, (... and Nil should correct me where I'm wrong.)

Suppose that the pattern matcher finds zero solutions to the original query -- there is no combination of human/picker/place1/origin/destination in the *current* atomspace that satisfies that pattern. In this case, the backward chainer then examines the set of rules that it has, to determine, if possible, whether there is a sequence of deductions (a sequence of rule applications) that provide suitable Atoms that allow your pattern to be satisfied.  For example, the current AtomSpace might not contain any humans at all, but perhaps there is a way to infer that someone is human.  Or a better example: there is no (Evaluation (Predicate "leads to") origin destination) but perhaps the backward chainer can find a sequence of multiple steps that lead from origin to destination -- it can find a path -- that eventually leads to a satisfaction of all of your terms.

The problem with path-finding, is, of course, that it's a hard problem: there can be a combinatorial explosion, and thus an explosion of CPU time.  There are algorithms that, for example, know all about 2D space, and make use of 2D geometry to find a good path. The backward chainer has no clue that it's exploring a 2D space, so it's search for a path is a bit more blind. Perhaps there's a way of making it clever, e.g. taking the A*-search rules and turning them into a PLN formula, and maybe that would work... but this discussion is not yet at this level.

--linas

--

[Linas Vepstas]

Python most definitely has exceptions:

https://wiki.python.org/moin/HandlingExceptions

The C++ exception should have been converted into a python exception.

-- linas

--

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 opencog+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/1f0e3123-3108-4fbc-b770-4fc4289ee2f2%40googlegroups.com.

[Alexander Gabriel]

Am Montag, 2. März 2020 14:37:12 UTC schrieb linas:

 

Yes, that doesn't scale to what I intend to do.

I'd like to know why you think that. (what you are trying to do). I'm interested in understanding and solving scaling problems.

The robot needs to make sure it can reach the human co-worker. For that it needs a path of waypoints which are interlinked and it needs to make sure that for any node on that path there is nobody.

Deriving the path from one node to another is an inference problem, solved by iteratively connecting neighours until a connection is established.

I guess I could do this using the forward chainer, but given 200 waypoints, that would create a gigantic number of links between node pairs.

So I'd prefer doing it using the backward chainer, but since the task involves checking virtual links which isn't supported by the chainer, it seems I'm out of luck.

 

 

Ah, it's a completely different query, one where the backward chainer
tries to find assignments of the free variables of a closed term.

This was unclear to me, so let me clarify, (... and Nil should correct me where I'm wrong.)

Suppose that the pattern matcher finds zero solutions to the original query -- there is no combination of human/picker/place1/origin/destination in the *current* atomspace that satisfies that pattern. In this case, the backward chainer then examines the set of rules that it has, to determine, if possible, whether there is a sequence of deductions (a sequence of rule applications) that provide suitable Atoms that allow your pattern to be satisfied.  For example, the current AtomSpace might not contain any humans at all, but perhaps there is a way to infer that someone is human.  Or a better example: there is no (Evaluation (Predicate "leads to") origin destination) but perhaps the backward chainer can find a sequence of multiple steps that lead from origin to destination -- it can find a path -- that eventually leads to a satisfaction of all of your terms.

The problem with path-finding, is, of course, that it's a hard problem: there can be a combinatorial explosion, and thus an explosion of CPU time.  There are algorithms that, for example, know all about 2D space, and make use of 2D geometry to find a good path. The backward chainer has no clue that it's exploring a 2D space, so it's search for a path is a bit more blind. Perhaps there's a way of making it clever, e.g. taking the A*-search rules and turning them into a PLN formula, and maybe that would work... but this discussion is not yet at this level.

The distance (in waypoints) between the robot and the picker is usually small, so iteratively applying a simple implication rule should produce the path in just a couple of steps with the number depending on how the chainer does this, fewer if it balances both terms, longer if it focusses on one.

But in the aforementioned example this is not taking place as there is no such rule for 'leads_to' links (only for 'linked' links). So I'm at a loss why the query takes so long. There isn't much chaining to be done as far as I can see.

Best,

Alex

[Linas Vepstas]

Ah!

OK, well then some quick concluding remarks:

-- Yes, the 5-second thing sounds like a bug; to keep the conversation focused, its probably best to open a bug report against the URE, and track that.

-- Using the chainer to solve 2D/3D motion planning problems is at, or just a bit past what we can currently do with the chainer.  No one has attempted to solve this kind of problem before with the chainer, and there are surely bugs and optimizations that this will expose. But it is a worthy undertaking.

-- By contrast, there is a system, called "answer set programming" (ASP), that can solve generic constraint-satisfaction problems in a blazingly fast way. But I don't really know how well it can handle a 200-waypoint problem.  Depends on how it's encoded, I suppose...

-- ASP works with crisp true/false values; this allows for strong, brutal trimming of impossible solutions, using the Davis-Putnam DPLL algo. The URE cannot trim and cut away like this, so is at a sharp disadvantage. We've argued about better ways to do URE, e.g. by applying Morse theory, but no one has done this yet.  (in Morse theory, you would create a cutoff c, and then round all truth values > c to 1.0 and all truth values < c to 0.0. Start with c=0.99 and then run ASP and see if there is a solution. If no solution, then set c=0.98 and try again. The idea is that running ASP 100 times might still be faster than brute-force uncertain-inference chaining.)

-- If we had 5 clones of Nil, then one of them could go through the ASP examples and port them to the chainer, and make them work well. (btw, I recommend the uni-potsdam ASP solver, if you mess with it) 

-- So, if you just need a motion planner that works (as opposed to messing with the theory of it) then, as a practical solution, I would recommend just grabbing something off the shelf and wiring it in, ad hoc.

-- In opencog-land, we have this vague vision that the "space server" is a specialized component that understands 3D space, and has a collection of hard-coded custom algos for working with 3D space (and, at the same time, interfacing with the atomspace and natural language, e.g. using words like "near", "far", "come", "go"). At this time, it is neglected. (it compiles and passes unit tests, but doesn't really do anything "useful")

Linas.

--

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 opencog+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/21007978-a855-45b0-9c52-b0dab0c023e3%40googlegroups.com.

[Alexander Gabriel]

Am Montag, 2. März 2020 16:55:02 UTC schrieb linas:

Ah!

-- So, if you just need a motion planner that works (as opposed to messing with the theory of it) then, as a practical solution, I would recommend just grabbing something off the shelf and wiring it in, ad hoc.

Yes, I'm aware of ASP (and several other approaches) that do specific things very fast. But most of them can't handle uncertainty or can't handle variables, both of which we make use of in this project (e.g. robot perception and its interpretation of human behaviour introducing uncertainty)..and I'm not looking for a solution where I have to keep around n knowledge bases to make n different software packages happy just because they tend to be excellent at a specific niche. (I already have to integrate too many for comfort)

If path planning turns out to be too slow, I'd rather apply some abstraction (from waypoints to hubs and spokes).

What I'd also like to try is some 'smart' (in the smartphone sense) chaining, where we try to evaluate the easy parts first and use those to constrain the harder parts, and where we allow for more finely-grained scoping (e.g. "only dogs qualify for this variable, we only have two dogs, don't consider 500 waypoints here").

Best,

Alex

[Nil Geisweiller]

On 3/2/20 12:57 PM, Alexander Gabriel wrote:
>
> No, it typically doesn't need to execute the link it is doing inference
> on, rather it runs inference trees constructed from inference rules
> that
> produces the target, including updating its TV. Whether this is fast or
> slow depends on the inference trees, not so much the target.
>
>
> I'm not sure I understand, don't the inference trees result from the
> interaction between the target and the rulebase?

Yes, but that's a static interaction. Basically, in the case of backward
chaining, the target is syntactically unified with the conclusion of
some rule, then some simple inference tree like

premise_1
...
premises_n

|-

target

is created, then one of the premises is syntactically unified with
another rule to create a bigger inference tree, etc.

Every time an inference tree is created it is executed, and results are
collected, and returned the user at the end.

Nil

>
>
> >     If you add a type declaration (I believe the python bindings
> allow you
> >     that), it should speed up the reasoning as well.
>
> Most of the atoms I add are ConceptNodes (200-300 at the moment and
> almost all of them are places), so restricting chaining to those doesn't
> help me much. In any case I'm already doing that.
>
>
> for instance the frog example show an example of variable
> declaration in
> a backward chainer query
>
> https://github.com/opencog/ure/tree/master/examples/ure/frog#backward-chainer
> <https://github.com/opencog/ure/tree/master/examples/ure/frog#backward-chainer>
>
>
> Yes, that's the same kind of variable declaration that I use above. The
> VariableList from the GetLink I also give to the backward chainer.
> What happens for different variations of variable declarations provided
> for the getlink and the backward chainer, I've detailed in the last post.
>
> Best,
> Alex
>

> --
> 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 opencog+u...@googlegroups.com
> <mailto:opencog+u...@googlegroups.com>.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/opencog/2cf3a540-b069-4bbf-810b-066c2ecd2051%40googlegroups.com
> <https://groups.google.com/d/msgid/opencog/2cf3a540-b069-4bbf-810b-066c2ecd2051%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Nil Geisweiller]

On 3/2/20 4:36 PM, Linas Vepstas wrote:
> Suppose that the pattern matcher finds zero solutions to the original
> query -- there is no combination of
> human/picker/place1/origin/destination in the *current* atomspace that
> satisfies that pattern. In this case, the backward chainer then examines
> the set of rules that it has, to determine, if possible, whether there
> is a sequence of deductions (a sequence of rule applications) that
> provide suitable Atoms that allow your pattern to be satisfied.  For
> example, the current AtomSpace might not contain any humans at all, but
> perhaps there is a way to infer that someone is human.  Or a better
> example: there is no (Evaluation (Predicate "leads to") origin
> destination) but perhaps the backward chainer can find a sequence of
> multiple steps that lead from origin to destination -- it can find a
> path -- that eventually leads to a satisfaction of all of your terms.

Exactly.

> The problem with path-finding, is, of course, that it's a hard problem:
> there can be a combinatorial explosion, and thus an explosion of CPU
> time.  There are algorithms that, for example, know all about 2D space,
> and make use of 2D geometry to find a good path. The backward chainer
> has no clue that it's exploring a 2D space, so it's search for a path is
> a bit more blind.

Correct.

Nil

> Perhaps there's a way of making it clever, e.g. taking
> the A*-search rules and turning them into a PLN formula, and maybe that
> would work... but this discussion is not yet at this level.
>
> --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 opencog+u...@googlegroups.com
> <mailto:opencog+u...@googlegroups.com>.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/opencog/CAHrUA35gUeZhOLzDpYtDSrFXCAXSk8ueVEL5DRw2WRsRZuDxgQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/opencog/CAHrUA35gUeZhOLzDpYtDSrFXCAXSk8ueVEL5DRw2WRsRZuDxgQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.

[Alexander Gabriel]

Every time an inference tree is created it is executed, and results are
collected, and returned the user at the end.

I see,

in that context, should this example take so long?

 https://github.com/opencog/ure/issues/67

Best,

Alex

[Linas Vepstas]

Thank you Nil,

short remarks: -- what you explain below, is it clearly written up in some README and/or wiki page? If not, can I get you to do that?

Does the chainer stop, soon as it finds some solution, or does it continue up until some user-specified depth?

A related but unrelated FYI remark... for the language learning project, we need to be able to create "random languages", for testing purposes: create a random syntax, then create random sentences, then see if the learner can accurately learn the random syntax.

For generating speech, we need to do something similar, but instead use a fixed (English language) syntax, and include fixed words (e.g. "pizza", "verb-to-eat", and "Ben") and generate a syntactically-valid sentence that includes those words.

I'm planning to start a new git-repo "real soon now" that will provide code for above. The funny thing is -- the algo to accomplish this sounds a lot like the backward chainer. But with my usual twist -- the rules are not rules with variables in them, they are the "jigsaw puzzle pieces" with connectors in them.  Assembly continues until there are no more unconnected jigsaw-puzzle tabs.  Instead of unification and beta-reduction, one connects together "connectors".

I think it would be interesting to clarify, via direct examples, if somehow the jigsaw-puzzle-piece concept can be mapped into URE rules, and if the backward chainer could be used to perform this generation.  I mean, I know everyone has lots to do, but ... this should be done...

--linas

To unsubscribe from this group and stop receiving emails from it, send an email to opencog+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/0d653f73-d85a-b01a-226e-3e4daf14aa98%40gmail.com.

[Nil Geisweiller]

On 3/4/20 9:02 PM, Linas Vepstas wrote:
> short remarks: -- what you explain below, is it clearly written up in
> some README and/or wiki page? If not, can I get you to do that?

https://wiki.opencog.org/w/Unified_rule_engine

Nil