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 in removal 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. > > 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. > > 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? > 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). > Got it. -- 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/CABpRrhwE4dxvowc3uW6EB0VFwkAiS7J4J%3DYJECrimixgZ%2B_hug%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
