Alexey,
On 05/23/2018 03:44 PM, Alexey Potapov wrote:
Nil,
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.
Just small remark: it's not (only) about confidence, but also about
efficient computations. If you face a P-class problem, which solution
you don't know, you will first apply general inference/search methods,
which will be exponentially slow at first (or, given limited time, they
will be very imprecise). Specialization of a general inference engine
w.r.t. a narrow problem results in inference procedures with completely
different computational structure. The reason, why this procedures are
unconscious, lies not inremoval of linear overheads (interpretation vs
compilation), but in moving from a general inference operating over
unified search spaces to direct computations hardly applicable outside
the scope of a corresponding narrow task.
Yep, I agree, it's not just about confidence, but also, very
importantly, about efficiency.
There this notion of super compilation that Ben worked on with some
colleagues a while ago, that is very relevant. It develop the execution
tree of a program and restructure it, simplifies it, remove any
redundancy, etc. That's pretty powerful in principle, though probably
extremely slow.
That is said, I do believe that inference control alone could makes
inference pretty fast, over restricted domains of course, without the
need to immediately turn it into a specialized program.
So it seems what we want is
1. Perform general inference
2. Learning control rules to speed it up
3. Speed up Inference + Control Rule into an even faster program, by
super compiling it
this makes a lot of sense for any process that is reused over and over,
so that it's worth the effort of super compiling it.
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).
Well... it should not necessarily be about high confidence. You can have
a narrow task with very low amount of data, but very efficient
procedures to calculate these low-confedence probabilities.
True.
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.
I don't clearly understand, what do you mean by "links returning
something"? Links per se do nothing, especially, in terms of "returning
something". Returning to where? Do you mean that GetValueLink will be
executable? In any case, we are talking about applying Pattern Matching
to Values, so I'm interested in how do you view GetValueLink will behave
within Pattern Matcher?
I mean when run by cog-execute!, which also happens to be the standard
way of invoking the pattern matcher.
Nil
--
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/6a260dd8-3e37-061d-0043-4f1c341064da%40gmail.com.
For more options, visit https://groups.google.com/d/optout.
