On Wed, Feb 26, 2020 at 12:47 PM Alexander Gabriel <[email protected]> wrote:
> > > Am Mittwoch, 26. Februar 2020 18:22:29 UTC schrieb linas: >> >> Hi Alex, >> >> The answer: yes, or rather no, and there's a bug in your example. >> >> The URE is built on top of the pattern matcher, and as mentioned earlier, >> the pattern matcher never alters truth values, and rarely looks at them, as >> it is only concerned with the presence/absence of patterns in the >> atomspace. As a URE user, you are welcome to write rules that examine >> truth values, and alter them in any way that you want. (I assume that one >> can also write URE rules that manipulate Values in general, but this may be >> cutting-edge, missing functions and utilities...) (see also >> /examples/atomspace/formulas.scm which presents the recommended way of >> handling these kinds of computations.) >> > > But my goal wasn't to alter the value, just to have it looked up. But you > know that already ;) > Well, but I didn't... If you ask me, we should remove the assumption of the default truth value > upon atom creation. > This is archaic; there's an idea that, if you ask for a truth value, you should get at least something, instead of throwing an error. Anyway, if I recall, the default is not actually stored; its merely returned if there isn't already some other truth value. So basically, if you get the default TV, that means there is no TV... Truth value definition should mean truth value changing, and not defining > it should just create a pattern that one can feed to the system to query > the truth values of a complex pattern. Unless there is another way to make > a grounded complex query that I'm not aware of. (In which case please point > me in the right direction ;) > Well, but of course there is! Just use the pattern matcher directly! (which you are already doing, in half of your examples). You are using the pattern matcher directly, whenever you say (cog-execute! (BindLink ...)) or (cog-execute! (GetLink ...)) That code path never goes through the URE, never looks at any rules. The URE is for chaining rules together in sequence -- think of it as a kind-of A-star search through the space of rules. By contrast, the pattern-matcher (GetLink, BindLink) is a single-step, in a user-specified step direction. You can even trigger truth-value rewrites with the pattern-matcher, several different ways, with the recommended best-practice being in /examples/atomspace/formulas.scm > >> The bug is here: >> (define target (And (State (List (Variable "person") hungry) true) >> (State (List alice thirsty) true))) >> >> When you entered that, you just changed Alice's state. You didn't mean >> to, but atoms are globally-unique, and a StateLink can only have one state, >> so when the evaluator first sees that, it changes Alice's state, >> irrespective of it being wrapped up in the AndLink. >> >> To add insult to injury, the pattern matcher completely ignores the >> second StateLink, because it has no variables in it, and thus is trivially >> present in the atomspace. I guess that the URE can still examine it, and do >> something with it's truth value, depending on which rule got triggered. >> > > If I could get my wish of definable patterns to query complex truth > states, I'd expect the matcher to go collect those truth values. As it is > now, I'd expect it to throw an error and tell people that they're changing > the KB state. Silently changing the KB state as well as silently assuming > the truth value of the grounded atoms is default (regardless of what it's > defined to be) seems like the worst choice. > OK, it sounds like you are frustrated, and for that I am sorry. StateLink is by definition both stateful and "silent" and I don't really see any other way: some pop-up "Are you sure? Abort, retry, ignore." The pattern matcher ignores truth values because that's just modular design. If you want to do something with truth values, that is an additional layer built on top of the core function. There are several reasons for this, besides modularity. One is the the lack of historical agreement about what the correct formulas are. Specifically, there was a battle: Pei Wang's NARS vs. Ben Goertzel's PLN. Which one has the correct rules? Maybe a third way? Maybe truth values should be truth-intervals? Maybe they should be histogrammed approximations to probability distributions learned from large datasets? Who knows? Untangling basic search from valuations is one way to allow freedom for exploring different theories of valuation. FWIW, this distinction is made in textbook classical logic, too. One distinguishes P^Q from the possible assignments of T or F to P, Q. The different possible assignments are called "valuations". This distinction leads to the difference between "syntactic" and "semantic" truth (single-turnstile vs double-turnstile). So, for example, for "syntactic truth", you assign T,F values to symbols, then evaluate the and-or-not expressions, turning the crank until evaluation terminates. For "semantic truth", you do NOT assign T,F values; you perform all manipulations abstractly, using rules of introduction and rules of retirement (and/or Hilbert-system style deductions). Sometimes syntactic and semantic truth are the same, and sometimes they are not, these are the various satisfiability/unsatisfiability theorems of Skolem and Godel and etc. e.g. the upward and downward theorems of Lowenheim-Skolem. Untangling truth from the symbols that might carry some truth value is what makes logic so rich. This email is too long, but also be aware of probability: thanks to Kolmogorov, we know that "and", "or", "not" corresponds to set-intersection, set-union and set-complement, in a very precise way. So, the truth formulas for AndLink, OrLink: should they be ... ? boolean? set-intersection? maybe with Bayesian priors? Which? it's a mess. -- 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/CAHrUA37Rqskb69_%2Bon4PkQrHzhW1h%3DWDxrKBZh19YOadk8pF4A%40mail.gmail.com.
