Pattern matcher fails on a query involving disjunction of virtual clauses
ngeiswei opened this issue · 6 comments
The following query
;; Modules
(use-modules (opencog))
(use-modules (opencog exec))
;; Functions
(define (bool->tv b)
(stv (if b 1 0) 1))
(define (tv->bool tv)
(equal? (stv 1 1) tv))
(define (true? A)
(bool->tv (tv->bool (cog-tv A))))
(define (always-true)
(stv 1 1))
;; KB
(Inheritance (stv 1 1)
(Concept "human")
(Concept "person"))
;; Query
(define query
(Get
(TypedVariable
(Variable "$A")
(Type "ConceptNode"))
(And
(Or
(Evaluation
(GroundedPredicate "scm: true?")
(Evaluation
(Predicate "P")
(List
(Concept "dog")
(Variable "$A"))))
(Evaluation
(GroundedPredicate "scm: always-true")
(List)))
(Inheritance
(Variable "$A")
(Concept "person"))))
)
(cog-execute! query)returns an empty match, while it should return human. If one adds a Present link around (Inheritance (Variable "$A") (Concept "person")), then it works as expected. Also if one removes the virtual disjunction (Or ...) or its first disjunct (Evaluation (GroundedPredicate "scm: true?") ... it works too.
I found that bug while trying to debug opencog/ure#120. Possibly, if that bug is fixed then opencog/ure#120 will be fixed as well.
FYI, I'm creating a utest for that I'm gonna push soon.
Hi Nil! Thanks! I will look at this, then. With luck, it'll only take a few hours.
@ngeiswei FYI, Completely unrelated to this bug report, but .. while I have your attention, I want to tell you about a new feature. Deep stacks of Atomspaces now work "correctly", "normally" "as expected". This means that a deleted atom in one layer really does behave as if it is deleted in that layer, even if it is present in others. Also, incoming sets now behave correctly: for a given atom in a given layer, the incoming set only includes the top-most copy of any given atom (some years ago, you had complained that incoming sets acted weird, returning multiple copies of an atom, including the deep ones, that should have been hidden. This is now fixed.) You can create multiple branching structures and also create atomspaces that are set-unions of the deeper underlying atomspaces. -- in other words, arbitrary DAG's. Very crudely, each layer can be thought of as if it were a git changeset.
I'm using this to store the "inference trails" in the learning codebase: At each step of learning, I create a new atomspace layer, adjust assorted truth values, add or delete some atoms, and then do it again. I plan to go several thousand layers deep, to have multiple branches, and to be able to compare atomspace contents across different branches (to see where inferences diverge). Can save and restore to rocksdb.
It's code complete, has unit tests, and there are no known bugs. But its fresh code, so hasn't been stressed very much, yet.
Also: AtomSpaces now inherit from class Atom. This makes them into a kind of weird, giant mutable SetLink-like thingy. If you try to put AtomSpaces into Links... it sort-of kind-of works, but there will probably be weirdnesses. Doing this is "not supported" mostly because its weird and I haven't figured out why this would be a good idea or what it might be used for. But if, for some reason, you've always wanted to do this, then we could hash out the details to make this work correctly and be properly supported.