>
>> 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.
>

Yes, it seems like a bug. The NotLink does get a truth value (the correct 
one assigned, if it's at the the top level of the query, if it's 
encompassed in an AndLink for example, it doesn't get a truth_value 
assigned.


(use-modules (opencog) (opencog logger) (opencog exec) (opencog ure))
(define rbs (Concept "foo"))
(ure-set-maximum-iterations rbs 30)


(load-from-path 
"/home/rasberry/git/pln/opencog/pln/rules/propositional/crisp-conjunction-introduction.scm")
(Member (DefinedSchema "true-conjunction-introduction-3ary-rule") rbs)

(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 alice (Concept "alice"))
(define bob (Concept "bob"))
(Identical (stv 0.0 1.0) alice bob)
(Evaluation (stv 1.0 1.0) (Predicate "tall") alice)
(Evaluation (stv 0.0 1.0) (Predicate "small") alice)
(Evaluation (stv 0.0 1.0) (Predicate "tall") bob)
(Evaluation (stv 1.0 1.0) (Predicate "small") bob)

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


; NOTE: Here the NotLink doesnt work
; (define target (And (Evaluation (Predicate "small") (Variable "person1"))
;                     (Not (Identical (Variable "person1") (Variable 
"person2")))
;                     (Evaluation (Predicate "tall") (Variable "person2"))))
;
; (cog-bc rbs target #:vardecl variables)

; NOTE: Here it doesn't either
; (define target (And (Evaluation (Predicate "tall") (Variable "person1"))
;                     (Not (Evaluation (Predicate "small") (Variable 
"person1")))))
;
; (cog-bc rbs target #:vardecl variables)


; NOTE: But here it does
(define target (Not (Evaluation (Predicate "small") (Variable "person1"))))

(cog-bc rbs target #:vardecl variables)





 

>
>> 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 ...
>

Yes, I'll do so.
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 [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/opencog/e2135ddd-dd74-4f7c-8f8b-5bd0220232b3%40googlegroups.com.

Attachment: notlink-works-at-top-level.scm
Description: Binary data

Reply via email to