On Thu, May 24, 2018 at 6:13 AM, Alexey Potapov <[email protected]> wrote:
>
>>>
>> No, I meant values in general. So for instance if atom (Node "A") holds a
>> FloatValue (5.2, 0.1, 4.5) at key (Schema "*-my-key*-"), the following
>> would return something like
>>
>> (cog-execute!
>> (GetValueLink
>> (Node "A")
>> (Schema "*-my-key-*")))
>>
>> (List (Number 5.2) (Number 0.1) (Number 4.5))
>>
>
As I stated earlier, I think that using a collection of predicates is
superior to using a GetValueLink, both for performance, and for
ease-of-use. But lets assume that there is a GetValueLink. To answer your
questions:
>
> Will this list then be added to Atomspace or will it exist temporally
> while Pattern Matching is working?
>
Yes. During pattern matching, a temporary atomspace is created to hold
temporary results. Whether or not any atoms are actually placed into the
main atomspace depends on what the actual pattern was.
The pattern matcher is essentially a stack machine. As it explores graphs,
it places intermediate results on stack, either the actual runtime stack,
or in one of several stacks in the code base. Some graph traversals cause
atoms to be created; however, if it later back-tracks, because that
particular branch exploration failed, then those created atoms have to be
removed, as they would be "incorrect" for other branches.
At the end of this process, when a match is found, there is an opportunity
to create atoms that are places in the main, primary atomspace. Some
queries do not create any atoms; they merely return a true/false reply.
Other queries can have the side-effect of modifying values on existing
atoms, instead of creating or destroying any atoms.
> I mean the idea was not to introduce any global changes to Pattern
> Matcher. So, PM once encounters GetValueLink, calls cog-execute! on it, and
> receives NumberNode, which then will be used to evaluate e.g.
> GreaterThanLink connecting GetValueLink to another GetValueLink or
> NumberNode. This was my initial understanding. Is it right?
>
Yes. Those atoms would be placed into the temporary atomspace. For various
arcane technical reasons (viz memory management), we have to place them
into some atomspace, somewhere, but I believe that the use of temporary
atomspaces is fairly low-cost and quite reasonable.
But it would be even faster/better, if there was, say ValueGreaterLink,
which combined into one the operations of value-getting and comparing. So,
for example:
ValueGreaterLink
Atom A
Atom B
Predicate "key-of-value-on A"
Predicate "key-of-value-on B"
which would, when executed, fetch the values and perform the comparison.
This way, we avoid having to call operator new NumberNode, set up incoming
set on NumberNode, then operator new ListLink, etc. stuff it all into the
temp atomspace, run a comparison, and then discard the whole mess.
I'm excited that well have system-programmer class people who will be able
to carefully explore system performance. The current system works, and I
think it work pretty well, but love and attention could make it better.
(The wrong kind of love and attention could make it worse, so I am somewhat
nervous, as well. I've seen plenty of projects go from "OK" to "crazy-badly
wrong", when they scaled up in size. Its really very easy to get
high-quality system programmers to do the wrong thing. It happens all the
time, everywhere.)
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 post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/opencog.
To view this discussion on the web visit
https://groups.google.com/d/msgid/opencog/CAHrUA349B-1qQ3OtROxbitiNoadreCUHg4AZ-VEWZ-k6BfwXgw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
