Regarding speeding up pattern matcher queries for numerical and such
domains other than space-time, maybe we could use cover trees. It does
involve defining a distance measure though. When non-obvious, maybe
such measure can be learned.
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 (yes, as Alexey suggests, this would really start looking
like a Sampler). 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.
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]>> 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
--
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/d71db589-f161-b4a3-f19e-6b78cd3072fe%40gmail.com.
For more options, visit https://groups.google.com/d/optout.
