On 05/21/2018 10:51 PM, Alexey Potapov wrote:
processes operating over values in a native code. However, what we lack in this case is meta-computations: specialization of a conscious decision-making w.r.t. some specific task should yield its efficient implementation in a native code (or trained DNNs). What we also lack is a general API to connect these conscious and subconscious processes.

Good point. I believe a possible way to connect these is via
reasoning, initially at least before this turns into schemata as well
(some of it anyway), something that is able to weight the pros and
cons of using a subconscious efficient process vs a more conscious and
general one.

What seems to happen in human is that high confidence knowledge tend
to go subconscious, while less confidence knowledge tend to be the
subject of the attention. So for instance a at first you may focus on
edge detection, etc, once you've built some high confidence model
about the relationships within this domain, you move that to the
subconscious (the neo cortex? I'm not enough into neuroscience to
tell) then you can focus on the next abstraction.

So transposed to OpenCog, I don't really know, it could mean that for
instance once you have say built an ImplicationLink with sufficient
confidence (with a Dirac like second order distribution), you no
longer need to bother updating it, unless perhaps the likelihood of
the incoming data considerably deviate from normal, in which case it
may mean that you need to go back to the basics (I suspect psychedelic
drugs do something like that, though I don't know if that a side
effect or a fundamental effect, I lack experience to really tell).

    For similar reasons PLN formulas are programmed with grounded
    schemata. A way to address that would be to complement Atomese with
    links encoding operators to access and modify values, GetValueLink,
    etc. This wouldn't make the pattern matcher more efficient
    (initially), but at least it would allow OpenCog to reason about values.


What do you suppose GetValueLink to do?

For instance

GetValueLink
  <atom>
  <key>

would return the value corresponding to `key` in `atom`. Note that
`key` is itself an atom. However the returned value may not
necessarily be an atom, it may be a proto atom, if so it would need to
"atomized". This makes me think that ProtoAtoms probably need some
"atomize" method or something.

Do you mean that this link is needed for Pattern Matcher to explicitly know that we want to apply TimesLink, etc. to Values? I guess, it makes sense, although this might be not too efficient, indeed.

The atomization might be the problem, but if it is meant to be
volatile (not be stored in the atomspace) then maybe the whole thing
can be done efficiently.

It seems it would be good if Atomese offers operators to create,
destroy, etc, atomspace, because then temporary computations could be
moved in small atomspace that I suspect would still be able to
manipulate atoms with less overhead (though I don't know well from
where come the overhead of inserting atoms in an atomspace).

Nil



-- Alexey

--
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/87c15951-d72b-dde5-7441-2831241b02cb%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to