Am Mittwoch, 26. Februar 2020 20:00:07 UTC schrieb linas: > > > > On Wed, Feb 26, 2020 at 12:47 PM Alexander Gabriel <[email protected] > <javascript:>> 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... >
Hrm, my problem isn't so much truth values (if you're referencing existing atoms, your references will hold the existing truth values anyway) but rather my inability to create structure without influencing the atomspace (the statelink issue, creating one to query messes with the one already present). I tried using a second atomspace for this, but ran into error messages on the way. (I haven't tried related atomspaces yet.) > > > 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. > Hrm, I don't understand..if I wanted to query a StateLink, I'd have to build one which would mess with already existing ones, wouldn't it? Could using a child atomspace avoid that issue but still give me results according to the state of the parent? >> 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. > No, no. No worries. I'm not frustrated, just formulating my naive first idea of how this could maybe behave in a way that is less prone to make the non-expert scratch their head over their reasoning results. > > 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." > I might just have to give up my idea of being able to check the state of a specific Concept-State pair without using VariableNodes. > > 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. > I think we're talking past each other here. Probably due to a lack of awareness on my part of how all the different parts (matcher, URE, ...) interact in detail. I'm not overly concerned with what the pattern matcher does or doesn't do. I'm just imagining an interface to my KB which should allow me to do certain things. Like querying a specific statelink. I somehow can't believe that's not possible. But I also can't think how it could be possible. > 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. > yeah, it is...it's a mix even in my little project. 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/de9053fc-9b37-4471-9eb5-2da669beb6dc%40googlegroups.com.
