OK, so lets focus on StateLink, then.
Oh, but first a comment about the atomspace itself. If you were coding in
C++ (and I don't recommend it, but just to clarify) ... if you were coding
in C++, you would notice that Atoms correspond one-to-one with C++ objects.
All the usual C++ behavior applies. You can, for example, create two Nodes
with exactly the same name; as C++ objects, they would have different
locations in RAM. You could, for example, place different TV's on each.
which one you got depended on how you passed pointers around in your C++
code.
Now the atomspace: it exists for one reason: to force atoms into being
globally unique. So if you put the first one into the atomspace, the
atomspace says "thank you I will remember it". Put the second one in, it
says "no thank you, I already got one, here's the one I have".
Neither the python nor the scheme (nor haskell) interfaces allow you to
work with "bare" atoms; they are *always* in an atomspace, by the time you
get to them. Even in C++, its dangerous to work with bare atoms: much of
the C++ code assumes that they're in the atomspace, and will behave in
undefined ways when not.
I'm only mentioning this because maybe it will help solidify your mental
model of what the atomspace is: its just a trick to ensure global
uniqueness. (global findability, global nameability...)
OK, so StateLink: by definition there can only be one "closed" StateLink at
a time. By "closed", I mean "containing no variables". So, given (SomeAtom)
there can only be one of these: (StateLink (SomeAtom)
(OtherAtomWithNoFreeVariables)) but you can have as many of these as you
want: (StateLink (SomeAtom) (AtomWithFreeVariables))
It's the atomspace that enforces the global uniqueness of the closed
StateLink. Now, if you were coding in C++, you could violate this rule...
but this would rapidly devolve into uncharted territory, posing all sorts
of questions about how all sorts of arcane scenarios need to be handled.
If the correct answer was always obvious, maybe we could do it, but its ..
not.
So ... how might you query a StateLink? You have two, three mechanisms
available. One, in scheme, is this (I guess there's a python analog, not
sure what it is). You would say
(cog-link 'StateLink (SomeAtom) (OtherAtom))
and this returns either the empty list, or the StateLink itself. The empty
list, if that particular pairing is not currently in the atomspace.
The above cannot be used in patterns. The normal way of obtaining the
current state would be to run (cog-execute! (Get (State (SomeAtom)
(Variable "x")))) and these can be composed in complex queries, for example:
(cog-evaluate! (SequentialAnd
(Equal (Concept "red light") (Get (State (Concept "stop-light")
(Variable "x"))))
(Not (Equal (Concept "car coming the other way") (Get (State (Concept
"cross-street") (Variable "y"))))))
...
))
(The above does not use the URE!! Its just base atomspace functionality.)
Note that, conceptually, that (cog-link 'StateLink (SomeAtom) (OtherAtom))
is more-or-less equivalent to (Equal (OtherAtom) (Get (State (SomeAtom)
(Variable "x"))))
Now, We could invent a brand new atom type, say, "IsInState" so that you
could write
(cog-evalute! (IsInState (SomeAtom) (OtherAtom)))
and it evaluates to true/false.... but this offers very little advantage
over just saying
(cog-evaluate! (Equal (OtherAtom) (Get (State (SomeAtom) (Variable "x")))))
which is a little more verbose, but works already. Please keep in mind
that explicit variable declarations are optional, when the query is
unambiguous like this. Finally, in scheme, you can always do this:
(define (is-in-state? A B) (Equal A (Get (State B) (Variable "x"))))
and use "is-in-state?" as if it were a real atom. It would work, in
many/most cases. If you really need it to work in *all* cases, then
something like this:
(DefineLink
(DefinedPredicate "is in state")
(Lambda
(VariableList (Variable "a") (Variable "b"))
(Equal (Variable "a") (Get (State (Variable "b") (Variable
"x"))))))
which you would use like so:
(cog-evaluate!
(EvaluationLink (DefinedPredicate "is in state")
(List (Concept "red light") (Concept "stop light"))))
and that should work just fine. This might be overkill for what you are
trying to do ... but it does work, and the intent is that, for complex
situations, this is how you would do it.
-- Linas
On Wed, Feb 26, 2020 at 2:39 PM Alexander Gabriel <[email protected]> wrote:
>
>
> Am Mittwoch, 26. Februar 2020 20:00:07 UTC schrieb linas:
>>
>>
>>
>> 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...
>>
>
> 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
> <https://groups.google.com/d/msgid/opencog/de9053fc-9b37-4471-9eb5-2da669beb6dc%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
--
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/CAHrUA344PSJVvm%2ByZVcFkdnijcjj2-7YoWASYQhVhtGZHrdEyw%40mail.gmail.com.
