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
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.
See issue https://github.com/opencog/atomspace/issues/2516 which is now
patched in https://github.com/opencog/atomspace/pull/2517
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
--
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 [email protected]
<mailto:[email protected]>.
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>.
--
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/789c21c9-3590-706c-09b2-acb3958ad0c7%40gmail.com.
