Pattern matcher disconnected components error thrown with Abduction rule

[eddiemonroe]

Grounding variable "$C" in the abduction rule leads the pattern matcher to throw an error that the bindlink consists of multiple disconnected components.

Here's the grounded abduction rule bindlink (with VariableNode C replaced by ConceptNode X:)

(BindLink (av 0 0 0)
   (VariableList (av 0 0 0)
      (VariableNode "$A")
      (VariableNode "$B")
   )
   (ImplicationLink
      (AndLink
         (InheritanceLink
            (VariableNode "$A")
            (ConceptNode "X")
         )
         (InheritanceLink
            (VariableNode "$B")
            (ConceptNode "X")
         )
      )
      (ExecutionOutputLink
         (GroundedSchemaNode "scm: pln-formula-abduction")
         (ListLink
            (InheritanceLink
               (VariableNode "$A")
               (VariableNode "$B")
            )
            (InheritanceLink
               (VariableNode "$A")
               (ConceptNode "X")
            )
            (InheritanceLink
               (VariableNode "$B")
               (ConceptNode "X")
            )
            (VariableNode "$A")
            (VariableNode "$B")
            (ConceptNode "X")))))

And here's the error: ERROR: In procedure cog-fc-em: BindLink consists of multiple disconnected components! (/home/eddie/opencog/atomspace/opencog/query/PatternMatch.cc:323)

Note that this error is thrown in the forward chainer, but is not thrown through use of (cog-bind). This is because cog-bind leads to bindlink->imply() being called with the check_connectivity argument set to false, so with cog-bind checking for connected components doesn't occur. In the forward chainer check_connectivity gets set to the default of true, and the error is thrown.

[linas]

Please double-check.

1) you are supposed to use pln-bindlink with pln, which explicitly avoids this check. Also, in the last week, I removed this check, as I started realizing it was a futile error message that everyone would happily ignore.

[eddiemonroe]

Yep, using pln_bindlink did the trick. Thanks!

If you removed the check tho, I wonder why the error was still happening... I guess this matters because if someone does a similarly structured non-pln rule they will get the same error.

[linas]

I removed the check only 2-3-4 days ago. If you haven't pulled and rebuilt since then, you wouldn't have it. The message was supposed to make people stop and think "gee I should not write disconnected graphs", but in fact there seem to be useful, plausible reasons to do this, even outside of PLN.

[eddiemonroe]

Am using the latest from the opencog and atomspace repos.

Perhaps changing default of check_connectivity param from true to false would do the trick in:

    bool imply(PatternMatchCallback&, bool check_connectivity=true);

in opencog/atoms/bind/Binklink.h:56

Yes, I understand the message, but the problem is that the check_connectivity function is mislabeling a connected graph as disconnected.

[eddiemonroe]

Just noticed there are two BindLink.h files. Perhaps that is the cause of issues or confusion?

opencog/atoms/bind/BindLink.h and opencog/query/BindLink.h

[linas]

Dang, I know I changed a connectivity default from true to false, somewhere, but I can't find where. I needed this for some new code... I even disabled the unit test that tests for this: DisconnectedUTest ... this is bizarre, because the master branch does not have these changes in it. WTF ... investigating.

I also changed the implementation of cog-bind-single to take an extra argument, and that code is not in the master branch either. This is very confusing. Did someone revert a big batch of changes? Did I manage to discard a whole pile of my own code, before I committed it? Did I accidentally revert my own changes?

I will rename one of the the BindLink.h files immediately. Figuring out the rest is ...

[linas]

Re: connectivity

Currently, there are two senses of connectivity in play. A pair of clauses are connected if: 1) the clauses share a common atom 2) the clauses share a common variable

your post above is connected in the sense of 1) but not 2)

Its the sense of 2) that causes heart-ache, e.g. when someone asks is $x < $y ? and then the pattern matcher needs to try all possible $x and $y which results in combinatoric explosion, and is thus these kinds of queries were meant to be discouraged by the connectivity check.

[linas]

closing, I beleive this was resolved a long time ago ...