On 03/15/2018 08:19 AM, Linas Vepstas wrote:
On Thu, Mar 15, 2018 at 1:12 AM, Nil Geisweiller
<[email protected] <mailto:[email protected]>> wrote:
Regarding speeding up pattern matcher queries for numerical and such
domains other than space-time, maybe we could use cover trees.
Well, the space-time serrver is supposed to do stuff like this.
Cool. But as far as I understood it uses a predetermined distance
measure. While a cover tree can work with any distance (thus with any
number of dimensions).
When non-obvious, maybe
such measure can be learned.
?
Wait, I was confused!!! It doesn't need to know the distance, just
know that the underlying measure is a distance!
Which is easier but is still non-trivial.
Hmm, maybe the notion of cover tree can be probabilistized to account
for uncertainty, meaning it could still work with measures that are not
perfect distances. Otherwise, it supposes to be compeletly confident
about the distance property, which is hard, requires either tones of
observations, or to infer that something is a distance from other
certain things.
Regarding queries taking too long, Linas suggested to make the pattern
matcher incremental, that is you can ask one candidate at a time if
you want
? Certainly the "SetLink is evil" issue on github is very much all
about incremental pattern matching. But also: killing a thread that is
taking too long to run is also not technically hard. No one asked for
enforced execution-time limits before, .. this can be added.
Good point.
My suspicion is that cognitive control, a la OpenPsi, almost always
need to account for resources (time in particular). So for instance if
a cognitive process needs to fetch some knowledge it will only allow
itself to do some for a certain amount of time.
(yes, as Alexey suggests, this would really start looking
like a Sampler).
I missed that part of the discussion. We already have a sampler -- the
attention-allocation version that misgana wrote a few years ago does
sampling.
Which would allow other cognitive processes to
consciously learn how to control that beast. Once the control skill
has been acquired with enough confidence, it can be moved back to the
unconscious.
We are very far away from cognitive processing....
Depends on what you defined by cognitive processing, the URE could be
seen as close to that, in the sense that it can utilize the available
knowledge to drive itself, as well as generate such knowledge.
Nil
Nil
On 03/15/2018 07:56 AM, Linas Vepstas wrote:
On Thu, Mar 15, 2018 at 12:37 AM, Alexey Potapov
<[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>> wrote:
So this is an arithmetic query, rather than a spatial
query --
but the two cases
are similar in that both arithmetic operations and spatial
operations are
"special domains" with their own algebras, and by using
those
algebras one
can answer queries in those domains more efficiently
than one
can do by generic
means...
Are you going to manually implement a special algorithm for
each domain?
How many domains are there? one? two? three? "satisfiability
modulo theories"
That's what those words mean.
So to efficiently handles queries like those you're
mentioning,
I would want to
use the PLN backward chainer rather than just the PM,
and have
the backward
chainer perhaps connected to some computer-algebra
engine as one
option to use
when encountering a GreaterThanLink ...
What rules for BC to do have in mind for this case? Let's
try them
and see if the solution will be O(N).
Again, you just say: don't use PM with GreaterThanLinks.
Then, for
what reason their support is presented in PM?
I'm totally confused. "Greater than" is just a theory. Its like
any other theory.
What exactly, is the problem here? Many theories have O(N)
algorithms.
Many other theories do not. You seem to be talking about a
linear programming
problem? which is solvable in P? I lost track of the argument.
Or one could tweak the PM to use the backward chainer
only when
encountering
a GreaterThanLink, and just do plain vanilla pattern
matching
otherwise...
PM doesn't need to know algebra to deal with this query
efficiently.
It just needs not to evaluate pairwise relations for every pair
object, but only for objects belonging to same groups.
So, stick them in the same group. If you design a crappy
representation for the knowledge you are representing, then the
query will run slowly. This is a lot like SQL -- many of the
same concepts, ideas apply -- the pattern matcher solves
satisfiability problems over a domain that is a bit richer than
plain-old relational algebra - its a graph isomoprhism problem.
But its not really all that different than any other
satisfiability problem or the kinds of queries one writes.
Yeah, I know. I just tried to imagine OpenCog in place of
human mind.
We are very very very very far away from human-mind type
intelligence. Don't imagine it that way. You'll just get bad
intuitions.
> Maybe. So, what rules will work in this case?
I think you need to describe the case again. It seemed to
require the sorting of time intervals into a linear sequence,
right? Pretty much all SQL databases support this natively. You
write a query that says "QUERY foo SORT BY colname". Or "QUERY
foo SORT BY 42*col_a - 2.35*col_b**3 + col_c>5?22:66" The
current pattern matcher does not have any sort-by statement,
although it could. As stated earlier, no one has ever tried to
push numeric data through the pattern matcher before; except in
some very super-naive and basic ways. If you really need
search and sorting by numeric value, that's a solvable problem.
Its a theory. Again "satisfiability modulo theories". We have
an API for implementing theories. Its stupid and low-level, but
it works.
--linas
--
cassette tapes - analog TV - film cameras - you
--
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/513ec841-fb20-3107-32f4-18848a8231ad%40gmail.com.
For more options, visit https://groups.google.com/d/optout.
