On Wed, Feb 26, 2020 at 10:38 AM Alexander Gabriel <[email protected]> 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. 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]. To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/CAHrUA348_32UVPXNmYcFNm%3D%3DEhdABHRcwxH_QXWGus_eoz7P3g%40mail.gmail.com.
