On Tue, Mar 13, 2018 at 2:30 AM, Nil Geisweiller <ngeis...@googlemail.com>
wrote:

> So if I understand well, the appropriate fix would be to use AtTimeLink
> and AtLocationLink and have the pattern matcher specially handles this via
> perhaps relaying the spatio-temporal component of the query to the space
> server.
>

Space is complicated. "Dallas is near Fort Worth" means 50 kilometers. "the
chair is near the table" means one meter.


> I know almost nothing about the current state of space server so take my
> comment with a grain of salt...
>

It "works" for appropriate level of "works". Its just super-duper naive and
simplistic.


> Alternatively, there might be more abstract heuristics that can hacked
> into the pattern matcher only, maybe that would be simpler and more
> general. No idea...
>

GroundedPredicateNodes are "sufficient". The hard part is to figure out
what kind of abstract heuristics are useful.  I know two ways of
discovering that: 1) reading textbooks and papers, 2) experimenting by
building things.

--linas



>
> Nil
>
> On 03/13/2018 07:07 AM, Linas Vepstas wrote:
>
>> I hope you can read the below. It took me a while to type it in.
>> I think maybe I'm the victim of some kind of google A/B testing
>> today, because for me, my own emails are totally unreadable.
>> Let me know if you suspect you didn't receive everything I sent ...
>>
>> --linas
>>
>> On Tue, Mar 13, 2018 at 12:05 AM, Linas Vepstas <linasveps...@gmail.com>
>> wrote:
>>
>>> OK, trying again. Maybe the third time it will work right.
>>>
>>> -- Linas
>>>
>>> On Tue, Mar 13, 2018 at 12:04 AM, Linas Vepstas <linasveps...@gmail.com>
>>> wrote:
>>>
>>>> Resending. My email agent is formatting and indenting bizarrely.
>>>> I don't understand why its 2018 and something as simple as email
>>>> has ugly and unreliable formating.  Is this what the heat death of
>>>> the universe looks like?
>>>>
>>>> --linas
>>>>
>>>> On Mon, Mar 12, 2018 at 11:55 PM, Linas Vepstas <linasveps...@gmail.com>
>>>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> To repeat my earlier remarks, and add a few more:
>>>>>
>>>>> On Mon, Mar 12, 2018 at 3:42 PM, Alexey Potapov <pas.a...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>> Yes. But Pattern Matcher compares all pairs of bounding boxes making
>>>>>> it
>>>>>> quadratic.
>>>>>>
>>>>>
>>>> Yes, there is supposed to be a space-server that is supposed to be
>>>>> optimized
>>>>> for these kinds of searches. There is one, but its super-minimal, and
>>>>> not at all
>>>>> integrated with the pattern matcher, or anything else for that
>>>>> matter.  Smart
>>>>> searches on bounding boxes is completely green-field development, for
>>>>> the
>>>>> atomspace. We've kind of got very nearly nothing for this.
>>>>>
>>>>
>>>>
>>>> Yes, but keep in mind that the PM is also Turing complete because you
>>>>>>> can
>>>>>>> call any function within a query (including the PM itself).
>>>>>>>
>>>>>>
>>>>>>
>>>>>> This is quite problematic. Basic processes should not execute anything
>>>>>> dangerous that can take too much time or loop forever and cannot be
>>>>>> interrupted. Thus, we should either not treat PM as a basic process,
>>>>>> or
>>>>>> should restrict its capabilities (and shift responsibility for
>>>>>> evaluating
>>>>>> arbitrary code to other processes).
>>>>>>
>>>>>
>>>>
>>>> This is misleading or a mis-understanding. Its not the correct way to
>>>>> think
>>>>> about it.  The current pattern matcher is 2 or three or 4 things
>>>>> matched into
>>>>> one:
>>>>>
>>>>> A) A generic subgraph isomorphism solver. Since this is an NP complete
>>>>> problem, it's certainly possible to create pathologically slow queries.
>>>>>
>>>>> B) A way of combining subgraphs using a crisp-logic boolean algebra
>>>>> (actually a Heyting algebra) which we have very vague intentions of
>>>>> promoting into something probabilistic.  Which, of course, if this was
>>>>> done,
>>>>> would layer on an additional combinatoric explosion.  It would be
>>>>> fruitful to
>>>>> discuss the wisdom or stupidity of this particular task. Or
>>>>> alternative designs
>>>>> for it.
>>>>>
>>>>> C) The ability to perform subgraph isomorphism with so-called "axiom
>>>>> schemata".
>>>>> An "axiom schemata" is roughly an infinite collection of relations,
>>>>> for example
>>>>> "less than" over the integers or rationals or reals.   This means that
>>>>> the pattern
>>>>> matcher is kind-of-like-ish a "satisfiability modulo theories" (SMT)
>>>>> solver.  The
>>>>> API for specifying a theory at this point is rather very simplistic.
>>>>> The "virtual link"
>>>>> is  that API. It says, basically "implement your model theory here, as
>>>>> C++ code,
>>>>> and we will automatically do the satisfiability modulo your theory for
>>>>> you"
>>>>>
>>>>> Currently supported theories are the equational theory (EqualLink) and
>>>>> numeric
>>>>> inequaltiy (GreaterThanLink)  An example of a nice-to-have theory
>>>>> would be
>>>>> linear algebra - done right, this could  solve your space-time
>>>>> bounding box problem
>>>>> for starters, and linear programming type problems if anyone cared
>>>>> about that.
>>>>> Maybe matroids. Whatever. Dunno.  Another nice-to-have would be naive
>>>>> set theory
>>>>> which could help lay a cornerstone of probability done right (TM) but
>>>>> this would be
>>>>> a long and difficult but veryinteresting discussion.
>>>>>
>>>>> D) Once a matching subgraph is found, you can launch arbitrary
>>>>> C++/scheme/python
>>>>> code to do something with that subgraph. So that's unbounded.
>>>>>
>>>>
>>>>
>>>> So, the first thing you should do is build a good benchmark tool, then
>>>>>>> we,
>>>>>>> you and the rest of opencog community, can supply it with a
>>>>>>> collection of
>>>>>>> critical tests.
>>>>>>>
>>>>>>
>>>>>> How do you see such tool?
>>>>>>
>>>>>
>>>> Unclear. I am interested in a tool that tells me if performance got
>>>>> worse after
>>>>> a particular code change or bug fix.  Some of our fixes accidentally
>>>>> slow things
>>>>> down (by a lot) and no one noticies for months or half a year.
>>>>>
>>>>
>>>> We have some datasets of varying sizes and
>>>>>> queries, and simply run PM on these queries and measure the time.
>>>>>> What can
>>>>>> be unified/automated?
>>>>>>
>>>>>
>>>> Yes!?
>>>>>
>>>>
>>>> Running all tests and writing log files with
>>>>>> computation times? Anything else?
>>>>>>
>>>>>
>>>> I don't care about log files.
>>>>>
>>>>
>>>> I agree that we need several (many?) tests to be sure that some changes
>>>>>> didn't affect any types of queries, but isn't it just a script? Or do
>>>>>> you
>>>>>> have something much more complicated in mind?
>>>>>>
>>>>>
>>>> Take a look at 3D graphics performance: there are two types of
>>>>> benchmark:
>>>>> triangles per second, lines per second, texture maps per second.
>>>>>
>>>>
>>>> The other type is "for game XYZ, frames per second".
>>>>>
>>>>
>>>> We need both types of benchmarks.  Probably the first more than the
>>>>> second,
>>>>> because it helps developers more.  The second kind just tells you how
>>>>> screwed
>>>>> up the system is today, without telling you why, or where to look.
>>>>>
>>>>
>>>>
>>>> In our case, the query processing time becomes unrealistically large
>>>>>> for a
>>>>>> one-minute video.  If we consider the problem of search in the entire
>>>>>> episodic memory, it should be even not linear, but logarithmic. Low
>>>>>> degree
>>>>>> polynomial complexity is ok for the task dimensions ~1000, not
>>>>>> millions or
>>>>>> billions...
>>>>>>
>>>>>
>>>> No clue what you are searching here.  Logarithmic searches mean binary
>>>>> tree,
>>>>> quad-tree, octree.  The space-time sever is an octree, but its not
>>>>> integrated with
>>>>> the pattern matcher, and has a super-naive API.
>>>>>
>>>>
>>>>
>>>> We have binary-trees and hash tables for atoms-by-name, by-type, but
>>>>> zero
>>>>> sophistication for numeric values. See above comments about
>>>>> "satisfiability
>>>>> modulo theories".
>>>>>
>>>>
>>>>
>>>> Linas
>>>>>
>>>>>
>>>>> --
>>>>> cassette tapes - analog TV - film cameras - you
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> cassette tapes - analog TV - film cameras - you
>>>>
>>>
>>>
>>>
>>> --
>>> 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 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/CAHrUA34PgYYJBCa8D2zjKfmK8nwF8wbLZbCZF%2BODjukxFYWP3A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to