backward chaining, IdenticalLink and NotLink seemingly misbehaving, strange occurrences of VariableLinks in chaining results

45 views
Skip to first unread message

Alexander Gabriel

unread,
Feb 26, 2020, 5:48:44 AM2/26/20
to opencog
Hello all!

Thank you again for all your support last I time I asked.
In the meantime I made quite some progress on my project, but now I'm again at a point where I could use your expertise.

I know most of you are more comfortable on the scheme side of things, so I converted my current problem sandbox for your convenience.

The below code creates 3 concepts, establishes very basic inheritance and runs a couple of reasoning experiments over inheritance and identity (which you'll have to uncomment individually as some return errors).
The goal is to get back one set/list of alice and bob with properly annotated truth values [(Not (stv 1.0 1.0) (Identical (stv 0.0 1.0) alice bob)) as part of its output], but none of the other weird results.
(Please disregard the pointlessness of this toy example, in my real application the identity comparison is needed)

I added notes to most lines of the code, saying what effect they have, and what effects I expect instead.

My main questions are:
  • How can I get the backward chainer to evaluate the IdenticalLink on its own?
  • How can I get the backward chainer to assign a proper truth value to the NotLink?
  • How can I change the fuzzy-conjunction role to still be fuzzy but not cause VariableLinks to be returned by the backward chainer? ...and why is that happening anyway?

(to run this, you'll have to adjust the load-from-path paths...I haven't figured out yet if there is a way to include these in a relative fashion that works across installations.) 
(use-modules (opencog) (opencog logger) (opencog exec) (opencog ure))
(define rbs (Concept "foo"))
(ure-set-maximum-iterations rbs 30)


; NOTE: If I use this (instead of the true-conjunction rule) the backward chainer returns 3 results, 2 of which still include VariableNodes. What keeps this from happening in the true-conjunction rule is a term I think is a check for a minimum truth value.
; (load-from-path "/home/rasberry/git/pln/opencog/pln/rules/propositional/fuzzy-conjunction-introduction.scm")
; (Member (DefinedSchema "fuzzy-conjunction-introduction-3ary-rule") rbs)




; NOTE: If I use this, the backward chainer returns only one result, as expected.
(load-from-path "/home/rasberry/git/pln/opencog/pln/rules/propositional/crisp-conjunction-introduction.scm")
(Member (DefinedSchema "true-conjunction-introduction-3ary-rule") rbs)




; NOTE: I extended the typelist in this file to include the IdenticalLink, but it still doesnt set the proper truth value for the NotLink when backward chaining.
(load-from-path "/home/rasberry/git/pln/opencog/pln/rules/wip/negation-introduction.scm")
(Member (DefinedSchema "negation-introduction-rule") rbs)


(cog-logger-set-level! (cog-ure-logger) "debug")
(cog-logger-set-stdout! (cog-ure-logger) #t)


(define human (Concept "human"))
(define alice (Concept "alice"))
(define bob (Concept "bob"))


; NOTE: If I set this explicitly, I can see that the NotLink doesnt get the proper (stv 1.0 1.0) assigned even if the chainer would figure that the two are different, why cant it? cog-evaluate! is able to.
; (Identical (stv 0.0 1.0) alice bob)


(Inheritance (stv 1.0 1.0) alice human)
(Inheritance (stv 1.0 1.0) bob human)


(define variables (VariableList
   
(TypedVariable
       
(Variable "person1")
       
(Type "ConceptNode"))
   
(TypedVariable
       
(Variable "person2")
       
(Type "ConceptNode"))))


(define target (Not (Identical
                           
(Variable "person1")
                           
(Variable "person2") )))


; NOTE: This is non-groundable for some reason and thusly fails. Id expect it to return a set of tuples that fullfill the query (Not (stv 1.0 1.0) (Identical (stv 0.0 1.0) alice bob)). Why does it fail?
; (cog-bc rbs target #:vardecl variables)


; NOTE: This works fine and evaluates to (stv 1.0 1.0) as expected, with or without the inclusion of the negation-introduction-rule.
; (cog-evaluate! target)



(define target (And (Not (Identical
                           
(Variable "person1")
                           
(Variable "person2") ))
                   
(Inheritance (Variable "person1") human)
                   
(Inheritance (Variable "person2") human)))


; NOTE: This returns very strange results including VariableNodes (Thus violating the TypedVariable definition) for some reason. How can I get this to only return grounded results? If I use the true-conjunction rule instead it returns the expected output.
(cog-bc rbs target #:vardecl variables)


; this throws an "Either incorrect or not implemented yet." error. Why?
; (cog-evaluate! target)

Thank you so much!
Best regards,
Alex

inheritance+identity.scm

Linas Vepstas

unread,
Feb 26, 2020, 10:51:21 AM2/26/20
to opencog, Nil Geisweiller
Hi Alex,

You might need @Nil Geisweiller  to give you the full, complete reply, as I'm just not that good with the URE.  But I think I can help clarify a few issues.

I didn't test, but I think that maybe your bug goes away if you make the target into this:

(And (Present (Variable "person1"))  (Present (Variable "person2"))
    (Not (Indentical (Variable "person1") (Variable "person2"))))

which basically says: "the variable 'person1' must be grounded by something that is present in the current atomspace at this moment in time. ... and also person2, and the groundings are not by the same atom" .

I call this a bug because the pattern matcher should have implicitly assumed this, without you having to explicitly say "present". I'll see if I can fix this bug "real soon now".

The other one, the throw on (cog-evaluate! target), that's an interesting one. So, if you read  the error message very carefully, it is saying that it does not know how to evaluate (Inheritance  (Variable "person1")  (ConceptNode "human")) ... which makes sense, because how would you evaluate that, anyway?  I find it interesting because we could "fix" this in an interesting manner:  if  cog-evaluate! gets something that has (free) variables in it, it should implicitly assume a SatsifactionLink. For your example, this works:  (cog-evaluate! (Satisfaction target)) -- that is, there does exist in the atomspace at least one grounding for the variables such that all clauses are satisfied.

I'm pondering whether or not making this kind of implicit-satisfaction is a good idea or not. It's certanly .. an interesting thought.

--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/605d9bc0-21be-4b5d-af9b-315034e83562%40googlegroups.com.


--
cassette tapes - analog TV - film cameras - you

Alexander Gabriel

unread,
Feb 26, 2020, 11:38:02 AM2/26/20
to opencog


Am Mittwoch, 26. Februar 2020 15:51:21 UTC schrieb linas:
Hi Alex,

You might need ...@Nil Geisweiller  to give you the full, complete reply, as I'm just not that good with the URE.  But I think I can help clarify a few issues.

I didn't test, but I think that maybe your bug goes away if you make the target into this:

(And (Present (Variable "person1"))  (Present (Variable "person2"))
    (Not (Indentical (Variable "person1") (Variable "person2"))))

which basically says: "the variable 'person1' must be grounded by something that is present in the current atomspace at this moment in time. ... and also person2, and the groundings are not by the same atom" .

Nice, thank you! Yes adding the PresentLinks to the target reduced the number of results that came with the fuzzy-conjuction rule to one and the one is the right one, alice and bob. Unfortunately, the IdenticalLink still doesn't get a non-default truth value automatically and if I pre-define it as described in the problem statement above, the NotLink also still doesn't play game and stays at default. Hopefully @Nil Geisweiller (or anyone else) has an idea on how to solve that one.

 (SetLink
 
(AndLink
   
(InheritanceLink (stv 1.000000 1.000000)
     
(ConceptNode "bob") ; [510da4194021b685][1]
     
(ConceptNode "human") ; [61b8bd8c84744a4d][1]
   
) ; [84ecb7fcf35adfdf][1]
   
(PresentLink
     
(ConceptNode "bob") ; [510da4194021b685][1]
   
) ; [c8aee4e806a8b606][1]
   
(InheritanceLink (stv 1.000000 1.000000)
     
(ConceptNode "alice") ; [6edb97fb269f42cf][1]
     
(ConceptNode "human") ; [61b8bd8c84744a4d][1]
   
) ; [f38e20568bbc0db3][1]
   
(NotLink
     
(IdenticalLink
       
(ConceptNode "bob") ; [510da4194021b685][1]
       
(ConceptNode "alice") ; [6edb97fb269f42cf][1]
     
) ; [9f4a3813ae99a91d][1]
   
) ; [f4f3e04ea1b33133][1]
   
(PresentLink
     
(ConceptNode "alice") ; [6edb97fb269f42cf][1]
   
) ; [fad3b63524d57e2d][1]
 
) ; [84c85ed40fe08dfd][1]
) ; [de5b9063ff45cdff][1]







 
I call this a bug because the pattern matcher should have implicitly assumed this, without you having to explicitly say "present". I'll see if I can fix this bug "real soon now".

I agree, why would someone be querying for things not present (accept with a combination of (NotLink (PresentLink someTarget)) ). Thanks for putting that on your todo list :) 

The other one, the throw on (cog-evaluate! target), that's an interesting one. So, if you read  the error message very carefully, it is saying that it does not know how to evaluate (Inheritance  (Variable "person1")  (ConceptNode "human")) ... which makes sense, because how would you evaluate that, anyway?  I find it interesting because we could "fix" this in an interesting manner:  if  cog-evaluate! gets something that has (free) variables in it, it should implicitly assume a SatsifactionLink. For your example, this works:  (cog-evaluate! (Satisfaction target)) -- that is, there does exist in the atomspace at least one grounding for the variables such that all clauses are satisfied.

What I found especially interesting (or rather confusing now that I know more) is that it had no problem with the target not including the InheritanceLinks and then complained about those instead of the ungrounded variables. I'm not sure that assuming an implicit SatisfactionLink is cleaner than giving a helpful ("We can't handle this, because of ungrounded variables. Have you considered wrapping in a SatisfactionLink or other binding mechanism?") error message. The later part would be more cumbersome for people I guess, but they might learn something on the way...and it avoids people thinking it'll assume this while it's assuming that...Whatever solution, whatever is happening should be as transparent as possible I think.

Best,
Alex

Linas Vepstas

unread,
Feb 26, 2020, 12:40:36 PM2/26/20
to opencog
On Wed, Feb 26, 2020 at 10:38 AM Alexander Gabriel <goo...@4d6.de> wrote:


Am Mittwoch, 26. Februar 2020 15:51:21 UTC schrieb linas:
Hi Alex,

You might need ...@Nil Geisweiller  to give you the full, complete reply, as I'm just not that good with the URE.  But I think I can help clarify a few issues.

I didn't test, but I think that maybe your bug goes away if you make the target into this:

(And (Present (Variable "person1"))  (Present (Variable "person2"))
    (Not (Indentical (Variable "person1") (Variable "person2"))))

which basically says: "the variable 'person1' must be grounded by something that is present in the current atomspace at this moment in time. ... and also person2, and the groundings are not by the same atom" .

Nice, thank you! Yes adding the PresentLinks to the target reduced the number of results that came with the fuzzy-conjuction rule to one and the one is the right one, alice and bob. Unfortunately, the IdenticalLink still doesn't get a non-default truth value automatically and if I pre-define it as described in the problem statement above, the NotLink also still doesn't play game and stays at default. Hopefully @Nil Geisweiller (or anyone else) has an idea on how to solve that one.

It might be a bug?  The rule-engine is built on top of the pattern matcher.  The pattern matcher never alters truth values, and almost never looks at them, either. Its mostly about determining if some pattern is present/absent in the atomspace, and whether it satisfies various constraints. Sometimes some of the constraints require looking at truth values.  In the case of Not Indentical, truth is computed, as a crisp true/false, but it is not recorded; its only used to accept/reject the match.

 
I call this a bug because the pattern matcher should have implicitly assumed this, without you having to explicitly say "present". I'll see if I can fix this bug "real soon now".

I agree, why would someone be querying for things not present (accept with a combination of (NotLink (PresentLink someTarget)) ). Thanks for putting that on your todo list :) 

Well, originally it was there because it seemed more-likely that people were simply designing bad searches, and so we wanted to warn them "o hey, you must have forgotten something here".  But this has recurred so frequently that changing the defaults seemed like the right thing to do.


The other one, the throw on (cog-evaluate! target), that's an interesting one. So, if you read  the error message very carefully, it is saying that it does not know how to evaluate (Inheritance  (Variable "person1")  (ConceptNode "human")) ... which makes sense, because how would you evaluate that, anyway?  I find it interesting because we could "fix" this in an interesting manner:  if  cog-evaluate! gets something that has (free) variables in it, it should implicitly assume a SatsifactionLink. For your example, this works:  (cog-evaluate! (Satisfaction target)) -- that is, there does exist in the atomspace at least one grounding for the variables such that all clauses are satisfied.

The above is now described in  https://github.com/opencog/atomspace/issues/2515

What I found especially interesting (or rather confusing now that I know more) is that it had no problem with the target not including the InheritanceLinks and then complained about those instead of the ungrounded variables. I'm not sure that assuming an implicit SatisfactionLink is cleaner than giving a helpful ("We can't handle this, because of ungrounded variables. Have you considered wrapping in a SatisfactionLink or other binding mechanism?") error message. The later part would be more cumbersome for people I guess, but they might learn something on the way...and it avoids people thinking it'll assume this while it's assuming that...Whatever solution, whatever is happening should be as transparent as possible I think.

Could you add this comment, or variant thereof into 
https://github.com/opencog/atomspace/issues/2515 ? The hard part then becomes converting the rather opaque error message into something human-readable.  Which I guess we can do with a try... catch ...

BTW, for all of these errors, if you hit them in your code, and you want to ignore them on purpose, you can wrap the trouble area with try... catch... and then have a no-op for the catch.  (well, in scheme, it's not called try...catch... but its the same idea)

-- Linas

Message has been deleted

Nil Geisweiller

unread,
Feb 26, 2020, 10:56:15 PM2/26/20
to ope...@googlegroups.com
On 2/26/20 7:40 PM, Linas Vepstas wrote:> It might be a bug?  The
rule-engine is built on top of the pattern
> matcher.  The pattern matcher never alters truth values, and almost
> never looks at them, either. Its mostly about determining if some
> pattern is present/absent in the atomspace, and whether it satisfies
> various constraints. Sometimes some of the constraints require looking
> at truth values.  In the case of Not Indentical, truth is computed, as a
> crisp true/false, but it is not recorded; its only used to accept/reject
> the match.

I would have to look at it more carefully (later as I'm busy these
days), but I'm almost sure that's the problem. The PLN formulae updates
the TV of the conclusion based on the TV stored on the premises.

It would be cool if the URE could handle seamlessly fleeting values
though, that's just not how the URE have been used so far.

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/CAHrUA348_32UVPXNmYcFNm%3D%3DEhdABHRcwxH_QXWGus_eoz7P3g%40mail.gmail.com
> <https://groups.google.com/d/msgid/opencog/CAHrUA348_32UVPXNmYcFNm%3D%3DEhdABHRcwxH_QXWGus_eoz7P3g%40mail.gmail.com?utm_medium=email&utm_source=footer>.

Alexander Gabriel

unread,
Feb 29, 2020, 11:26:47 AM2/29/20
to opencog
I would have to look at it more carefully (later as I'm busy these
days), but I'm almost sure that's the problem. The PLN formulae updates
the TV of the conclusion based on the TV stored on the premises.

It would be cool if the URE could handle seamlessly fleeting values
though, that's just not how the URE have been used so far.

Hi Nil,
I looked at this phenomenon in more detail and it seems to be limited to virtual links,
if that makes any sense. Those are created with 0-confidence values as they carry default truth values
and the NotLink has a precondition to only accept >0 confidence terms. I tried to replace that condition,
but my attempts haven't yet resulted in success.

Best,
Alex

Reply all
Reply to author
Forward
0 new messages