On Thu, Mar 15, 2018 at 12:37 AM, Alexey Potapov <pota...@aideus.com> 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 opencog+unsubscr...@googlegroups.com. To post to this group, send email to opencog@googlegroups.com. 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/CAHrUA35yXZUn4YTDB2CvL5MWigknCUjhfBFfTv28kDf3EfWAbg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
