subject:"\[opencog\-dev\] Re\: Pattern Matching performance"

On Sat, Mar 17, 2018 at 11:00 PM, Alexey Potapov  wrote:

> This discussion seems senseless. You literally said: "No human can
> remember 1 of anything whatsoever". Now, you said that words don't
> belong to the category of "anything whatsoever". Words have meaning,
> spelling, pronunciation. Each Chinese character has the specific stroke
> order. There are many other examples of more than 1 things known by
> humans (e.g. photostockers can recognize their works from 2+
> portfolios) ... And the specific number doesn't really matter. I'll stop
> here independent of your answer...
>

Those are all incredibly bad examples.  They are nonsense examples.
Knowing words or recognizing images is not even vaguely close to knowing
something.   You are vastly over-estimating how smart humans are by a
factor of 10 if not 100.

--linas

>
> 2018-03-17 17:30 GMT+03:00 Linas Vepstas :
>
>> ??
>>
>> I'm pretty sure I know a lot more than 1 words. That is not at all
>> comparable to knowing 1 things. Knowing 2 words is comparable to
>> knowing maybe 500 things. How, exactly, are you measuring knowledge?
>>
>> --linas
>>
>> On Sat, Mar 17, 2018 at 3:47 PM, Alexey Potapov 
>> wrote:
>>
>>>
 No human can remember 1 of anything whatsoever. The human brain is
 just simply not that big.

>>>
>>> Please, stop making such stupid claims. This is so obviously wrong that
>>> I'm not sure if there is any sense to argue. "No human", "1 of
>>> anything", "not that big"??? I will not refer to eidetic memory possessed
>>> also by some chess players... Just consider words. Normally, people use few
>>> thousands words, but writers use several tens thousands. Chinese writers
>>> can use more than 1. Polyglots can speak more than 10 languages up to
>>> (or more than) 1000 in which. Not sure how exactly much foreign words they
>>> can remember, but even if it is just several thousands, it doesn't make a
>>> principal difference. So, can't humans remember 1 words?..
>>>
>>
>>
>>
>> --
>> 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/CAHrUA365kv64%2Beov7xEawg2-%2B5ppNFWtuA46GAojDaRnu6L9kw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] Re: Pattern Matching performance

On Sat, Mar 17, 2018 at 10:56 PM, Ben Goertzel  wrote:

> This thread has gone a weird-ass direction...
>
> Of course an adult human knows way more than 10K things but I don't
>

Oh come on Ben. Of course a single human cannot know that much. That's an
absurdity.  Humans are stupid.

--linas


> even have time just now to scroll up and see how the conversation got
> here !!!
>
> On Sat, Mar 17, 2018 at 10:30 PM, Linas Vepstas 
> wrote:
> > ??
> >
> > I'm pretty sure I know a lot more than 1 words. That is not at all
> > comparable to knowing 1 things. Knowing 2 words is comparable to
> > knowing maybe 500 things. How, exactly, are you measuring knowledge?
> >
> > --linas
> >
> > On Sat, Mar 17, 2018 at 3:47 PM, Alexey Potapov 
> wrote:
> >>>
> >>>
> >>> No human can remember 1 of anything whatsoever. The human brain is
> >>> just simply not that big.
> >>
> >>
> >> Please, stop making such stupid claims. This is so obviously wrong that
> >> I'm not sure if there is any sense to argue. "No human", "1 of
> >> anything", "not that big"??? I will not refer to eidetic memory
> possessed
> >> also by some chess players... Just consider words. Normally, people use
> few
> >> thousands words, but writers use several tens thousands. Chinese
> writers can
> >> use more than 1. Polyglots can speak more than 10 languages up to
> (or
> >> more than) 1000 in which. Not sure how exactly much foreign words they
> can
> >> remember, but even if it is just several thousands, it doesn't make a
> >> principal difference. So, can't humans remember 1 words?..
> >
> >
> >
> >
> > --
> > 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/CAHrUA370iHqyqjsGLJQBU9BSMq%
> 3Dgk4tLRGmEhT2u65NAt7nP%3Dg%40mail.gmail.com.
> >
> > For more options, visit https://groups.google.com/d/optout.
>
>
>
> --
> Ben Goertzel, PhD
> http://goertzel.org
>
> "In the province of the mind, what one believes to be true is true or
> becomes true, within certain limits to be found experientially and
> experimentally. These limits are further beliefs to be transcended. In
> the mind, there are no limits In the province of connected minds,
> what the network believes to be true, either is true or becomes true
> within certain limits to be found experientially and experimentally.
> These limits are further beliefs to be transcended. In the network's
> mind there are no limits." -- John Lilly
>
> --
> 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/CACYTDBfVYuNtVynNwbsDJFHFLQ7t5sR45Lc00ab-MxPb1_Rx0A%40mail.
> gmail.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
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/CAHrUA34iYs9Fdx1X8eGmDj_tG8QXdQKXTzaQZLYi9Eni1OGCqA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] Re: Pattern Matching performance

2018-03-17 Thread Ben Goertzel

***
The limit of human knowledge is somewhere near there.  Most humans do
not contain more than 10 or 20 books of knowledge; geniuses might get
up to 100 or maybe more.  But that's the limit. Figure maybe ten pages
per topic or concept, and that is the limit of how much one person can
know (over a 50-year timespan...)
***

This was one of the key misconceptions underlying Cyc ...



On Sat, Mar 17, 2018 at 11:02 PM, Linas Vepstas  wrote:
> To be clear:  when I say "knowing things", I mean "concepts".  Think of
> "dogs", and writing down everything you know about dogs. I suppose that
> could fill at least 2 pages, maybe 10 pages of writing, and then you've
> exhausted everything you know about dogs.  That would count as "knowing one
> thing" or "knowing one concept".  How many times could you repeat that?
> Well, what do you know about cows? That they eat grass instead of meat, have
> multiple stomachs, chew cud, and that's about it.  Once you know about dogs,
> cows are more or less the same thing, with minor variations.  That really
> doesn't count as "knowing more".  Maybe 10% on top of what you already know
> about dogs.
>
> Now repeat this process. How many things in life could you exhaustively
> write about?  Do you really think you can write more than a few thousand
> 10-page essays?  Simply writing down that much requires 10 pages x 1000
> things = 10K pages. A typical book is 200 to 300 pages long (War and Peace
> is 600 pages? Maybe 800?).  Writing down that much would require writing
> 10K/300 = 30 books.  How long would it take you to write 30 books? Without
> repeating something that wasn't written down earlier? How many books has the
> most prolific author written? Of those books that this prolofic author
> wrote, how many weren't variations on the same theme, or invented fiction?
>
> The limit of human knowledge is somewhere near there.  Most humans do not
> contain more than 10 or 20 books of knowledge; geniuses might get up to 100
> or maybe more.  But that's the limit. Figure maybe ten pages per topic or
> concept, and that is the limit of how much one person can know (over a
> 50-year timespan...)
>
> --linas
>
> p.s. don't confuse "writing" with "knowing". I've written maybe 1K pages of
> math research (or much more??), and honestly, I remember maybe only 10% of
> what I wrote. The rest I forgot - the formulas, the details.  I remember the
> general plotline, not the details of the plot, of what I've written. Simply
> because I wrote a lot is not the same thing as "knowing" -- I can't
> effortlessly repeat that work. It would require lots of new, hard work.
>
> On Sat, Mar 17, 2018 at 10:30 PM, Linas Vepstas 
> wrote:
>>
>> ??
>>
>> I'm pretty sure I know a lot more than 1 words. That is not at all
>> comparable to knowing 1 things. Knowing 2 words is comparable to
>> knowing maybe 500 things. How, exactly, are you measuring knowledge?
>>
>> --linas
>>
>> On Sat, Mar 17, 2018 at 3:47 PM, Alexey Potapov 
>> wrote:


 No human can remember 1 of anything whatsoever. The human brain is
 just simply not that big.
>>>
>>>
>>> Please, stop making such stupid claims. This is so obviously wrong that
>>> I'm not sure if there is any sense to argue. "No human", "1 of
>>> anything", "not that big"??? I will not refer to eidetic memory possessed
>>> also by some chess players... Just consider words. Normally, people use few
>>> thousands words, but writers use several tens thousands. Chinese writers can
>>> use more than 1. Polyglots can speak more than 10 languages up to (or
>>> more than) 1000 in which. Not sure how exactly much foreign words they can
>>> remember, but even if it is just several thousands, it doesn't make a
>>> principal difference. So, can't humans remember 1 words?..
>>
>>
>>
>>
>> --
>> 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/CAHrUA358egO2X1-3fqU77BtBJCa5ZHUhiix3eOiLJ2NcgZ2WQg%40mail.gmail.com.
>
> For more options, visit https://groups.google.com/d/optout.



-- 
Ben Goertzel, PhD
http://goertzel.org

"In the province of the mind, what one believes to be true is true or
becomes true, within certain limits to be found experientially and
experimentally. These limits are further beliefs to be transcended. In
the mind, there are no limits In the province of connected minds,
what the network believes to be true, either is true or becomes true
within certain limits to be found experientially and experimentally.
These limits are furth

Re: [opencog-dev] Re: Pattern Matching performance

To be clear:  when I say "knowing things", I mean "concepts".  Think of
"dogs", and writing down everything you know about dogs. I suppose that
could fill at least 2 pages, maybe 10 pages of writing, and then you've
exhausted everything you know about dogs.  That would count as "knowing one
thing" or "knowing one concept".  How many times could you repeat that?
Well, what do you know about cows? That they eat grass instead of meat,
have multiple stomachs, chew cud, and that's about it.  Once you know about
dogs, cows are more or less the same thing, with minor variations.  That
really doesn't count as "knowing more".  Maybe 10% on top of what you
already know about dogs.

Now repeat this process. How many things in life could you exhaustively
write about?  Do you really think you can write more than a few thousand
10-page essays?  Simply writing down that much requires 10 pages x 1000
things = 10K pages. A typical book is 200 to 300 pages long (War and Peace
is 600 pages? Maybe 800?).  Writing down that much would require writing
10K/300 = 30 books.  How long would it take you to write 30 books? Without
repeating something that wasn't written down earlier? How many books has
the most prolific author written? Of those books that this prolofic author
wrote, how many weren't variations on the same theme, or invented fiction?

The limit of human knowledge is somewhere near there.  Most humans do not
contain more than 10 or 20 books of knowledge; geniuses might get up to 100
or maybe more.  But that's the limit. Figure maybe ten pages per topic or
concept, and that is the limit of how much one person can know (over a
50-year timespan...)

--linas

p.s. don't confuse "writing" with "knowing". I've written maybe 1K pages of
math research (or much more??), and honestly, I remember maybe only 10% of
what I wrote. The rest I forgot - the formulas, the details.  I remember
the general plotline, not the details of the plot, of what I've written.
Simply because I wrote a lot is not the same thing as "knowing" -- I can't
effortlessly repeat that work. It would require lots of new, hard work.

On Sat, Mar 17, 2018 at 10:30 PM, Linas Vepstas 
wrote:

> ??
>
> I'm pretty sure I know a lot more than 1 words. That is not at all
> comparable to knowing 1 things. Knowing 2 words is comparable to
> knowing maybe 500 things. How, exactly, are you measuring knowledge?
>
> --linas
>
> On Sat, Mar 17, 2018 at 3:47 PM, Alexey Potapov 
> wrote:
>
>>
>>> No human can remember 1 of anything whatsoever. The human brain is
>>> just simply not that big.
>>>
>>
>> Please, stop making such stupid claims. This is so obviously wrong that
>> I'm not sure if there is any sense to argue. "No human", "1 of
>> anything", "not that big"??? I will not refer to eidetic memory possessed
>> also by some chess players... Just consider words. Normally, people use few
>> thousands words, but writers use several tens thousands. Chinese writers
>> can use more than 1. Polyglots can speak more than 10 languages up to
>> (or more than) 1000 in which. Not sure how exactly much foreign words they
>> can remember, but even if it is just several thousands, it doesn't make a
>> principal difference. So, can't humans remember 1 words?..
>>
>
>
>
> --
> 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/CAHrUA358egO2X1-3fqU77BtBJCa5ZHUhiix3eOiLJ2NcgZ2WQg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] Re: Pattern Matching performance

2018-03-17 Thread Alexey Potapov

This discussion seems senseless. You literally said: "No human can remember
1 of anything whatsoever". Now, you said that words don't belong to the
category of "anything whatsoever". Words have meaning, spelling,
pronunciation. Each Chinese character has the specific stroke order. There
are many other examples of more than 1 things known by humans (e.g.
photostockers can recognize their works from 2+ portfolios) ... And the
specific number doesn't really matter. I'll stop here independent of your
answer...

2018-03-17 17:30 GMT+03:00 Linas Vepstas :

> ??
>
> I'm pretty sure I know a lot more than 1 words. That is not at all
> comparable to knowing 1 things. Knowing 2 words is comparable to
> knowing maybe 500 things. How, exactly, are you measuring knowledge?
>
> --linas
>
> On Sat, Mar 17, 2018 at 3:47 PM, Alexey Potapov 
> wrote:
>
>>
>>> No human can remember 1 of anything whatsoever. The human brain is
>>> just simply not that big.
>>>
>>
>> Please, stop making such stupid claims. This is so obviously wrong that
>> I'm not sure if there is any sense to argue. "No human", "1 of
>> anything", "not that big"??? I will not refer to eidetic memory possessed
>> also by some chess players... Just consider words. Normally, people use few
>> thousands words, but writers use several tens thousands. Chinese writers
>> can use more than 1. Polyglots can speak more than 10 languages up to
>> (or more than) 1000 in which. Not sure how exactly much foreign words they
>> can remember, but even if it is just several thousands, it doesn't make a
>> principal difference. So, can't humans remember 1 words?..
>>
>
>
>
> --
> 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/CABpRrhzDbQ7RUffbqM10NcbPQSyRdNG6djt2BB0osyWo25FaFg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] Re: Pattern Matching performance

2018-03-17 Thread Ben Goertzel

This thread has gone a weird-ass direction...

Of course an adult human knows way more than 10K things but I don't
even have time just now to scroll up and see how the conversation got
here !!!

On Sat, Mar 17, 2018 at 10:30 PM, Linas Vepstas  wrote:
> ??
>
> I'm pretty sure I know a lot more than 1 words. That is not at all
> comparable to knowing 1 things. Knowing 2 words is comparable to
> knowing maybe 500 things. How, exactly, are you measuring knowledge?
>
> --linas
>
> On Sat, Mar 17, 2018 at 3:47 PM, Alexey Potapov  wrote:
>>>
>>>
>>> No human can remember 1 of anything whatsoever. The human brain is
>>> just simply not that big.
>>
>>
>> Please, stop making such stupid claims. This is so obviously wrong that
>> I'm not sure if there is any sense to argue. "No human", "1 of
>> anything", "not that big"??? I will not refer to eidetic memory possessed
>> also by some chess players... Just consider words. Normally, people use few
>> thousands words, but writers use several tens thousands. Chinese writers can
>> use more than 1. Polyglots can speak more than 10 languages up to (or
>> more than) 1000 in which. Not sure how exactly much foreign words they can
>> remember, but even if it is just several thousands, it doesn't make a
>> principal difference. So, can't humans remember 1 words?..
>
>
>
>
> --
> 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/CAHrUA370iHqyqjsGLJQBU9BSMq%3Dgk4tLRGmEhT2u65NAt7nP%3Dg%40mail.gmail.com.
>
> For more options, visit https://groups.google.com/d/optout.



-- 
Ben Goertzel, PhD
http://goertzel.org

"In the province of the mind, what one believes to be true is true or
becomes true, within certain limits to be found experientially and
experimentally. These limits are further beliefs to be transcended. In
the mind, there are no limits In the province of connected minds,
what the network believes to be true, either is true or becomes true
within certain limits to be found experientially and experimentally.
These limits are further beliefs to be transcended. In the network's
mind there are no limits." -- John Lilly

-- 
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/CACYTDBfVYuNtVynNwbsDJFHFLQ7t5sR45Lc00ab-MxPb1_Rx0A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] Re: Pattern Matching performance

??

I'm pretty sure I know a lot more than 1 words. That is not at all
comparable to knowing 1 things. Knowing 2 words is comparable to
knowing maybe 500 things. How, exactly, are you measuring knowledge?

--linas

On Sat, Mar 17, 2018 at 3:47 PM, Alexey Potapov  wrote:

>
>> No human can remember 1 of anything whatsoever. The human brain is
>> just simply not that big.
>>
>
> Please, stop making such stupid claims. This is so obviously wrong that
> I'm not sure if there is any sense to argue. "No human", "1 of
> anything", "not that big"??? I will not refer to eidetic memory possessed
> also by some chess players... Just consider words. Normally, people use few
> thousands words, but writers use several tens thousands. Chinese writers
> can use more than 1. Polyglots can speak more than 10 languages up to
> (or more than) 1000 in which. Not sure how exactly much foreign words they
> can remember, but even if it is just several thousands, it doesn't make a
> principal difference. So, can't humans remember 1 words?..
>



-- 
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/CAHrUA370iHqyqjsGLJQBU9BSMq%3Dgk4tLRGmEhT2u65NAt7nP%3Dg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] Re: Pattern Matching performance

2018-03-17 Thread Alexey Potapov

>
>
> No human can remember 1 of anything whatsoever. The human brain is
> just simply not that big.
>

Please, stop making such stupid claims. This is so obviously wrong that I'm
not sure if there is any sense to argue. "No human", "1 of anything",
"not that big"??? I will not refer to eidetic memory possessed also by some
chess players... Just consider words. Normally, people use few thousands
words, but writers use several tens thousands. Chinese writers can use more
than 1. Polyglots can speak more than 10 languages up to (or more than)
1000 in which. Not sure how exactly much foreign words they can remember,
but even if it is just several thousands, it doesn't make a principal
difference. So, can't humans remember 1 words?..

-- 
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/CABpRrhxz-CMKAsULt7ifGMOR1Knm8hF5neVY5N%3D0d_S20pFrxA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] Re: Pattern Matching performance

2018-03-16 Thread Linas Vepstas

On Thu, Mar 15, 2018 at 6:20 PM, Alexey Potapov  wrote:

>
>
>> And forget the 10 thousand number.  No human can do that, not from memory.
>>
>
> I guess you are wrong. There are people who can recall any of 1 go
> games.
>

That's total bullshit. Its the Japanese equivalent of chem trails and flat
earth and aromatherapy: mumbo-jumbo to impress naive idiots.  No human can
remember 1 of anything whatsoever. The human brain is just simply not
that big.

> Why shouldn't people be able to solve simpler tasks, at least if they are
> professionally dedicated to them? Also, as well studied by Vygotsky and
> others, people from primitive societies have much better recall from
> episodic memory.
> But, ok, let's assume you are right. My claim: no human can solve zebra
> puzzle in their mind, but the backward chainer with PM can. So, let's not
> use them in AGI. Is this right conclusion from your arguments?
>

I had to google the "zebra puzzle". Its the same as the "Einstein puzzle"?
Middle house smokes camels and drinks whisky and the Dutchman keeps a dog?
Its a goofy kids puzzle.  I solved that puzzle like when I was 8 or 10
years old. It's not hard. I used an ordinary mental prosthesis: pencil &
paper, as it was called back in the day.  I guess maybe its too hard to do
it "in your head" (without pencil & paper)  because human short-term memory
is 7 +/- 2 and that puzzle requires maybe twice as much to remember. (???)
But that's why humans invented writing, yes? To get around limitations of
the human brain.

I don't understand what human limitations have to do with AGI.

What I was trying to state is that the pattern matcher (and the rule
engine, and the chainers, and the "openpsi" rule selection system) are all
just building blocks meant to be used whenever they are useful.  Figuring
out how to improve these building blocks, how to add features, how to make
them faster -- that's "easy".

I was also trying to state that getting a computer to learn knowledge from
the external world, and performing abstract reasoning with that knowledge:
that is "hard".Again: improving the pattern matcher to run in  O(N)
instead of O(N^2) == easy.  Learning+reasoning == hard.  I'm mostly
interested in the hard problem, not the easy one.

--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/CAHrUA36nSonc%3DM7P6akofDuaRORL_iGhLXjYWUsax%3D6HTvsqgA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] Re: Pattern Matching performance

2018-03-16 Thread Linas Vepstas

On Thu, Mar 15, 2018 at 2:49 PM, Nil Geisweiller 
wrote:

> On 03/15/2018 08:19 AM, Linas Vepstas wrote:
>
>>
>>
>> On Thu, Mar 15, 2018 at 1:12 AM, Nil Geisweiller > > 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).
>

The space server is an octree -- a binary tree, in three dimensions.  I
think that means that its a power-of-two (times three) cover tree ?

wikipedia: https://en.wikipedia.org/wiki/K-d_tree  K=3 for us, (I don't
know why we did not pick k=4)
https://en.wikipedia.org/wiki/Octree  I don't know why wikipedia has two
articles on the same topic that don't mention one-another.

https://en.wikipedia.org/wiki/Cover_tree

I don't think I care much about what algo gets used here.  I'm more
interested in figuring out how the atomspace interfaces to it.

>
>
> 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.
>

We need to stop calling it OpenPsi, and get a new name.  Here's why:  Eddie
Monroe was insistent that it was a model of human psychology, and we had
some ugly arguments about this. What Amen actually implemented was more of
a rule-selection mechanism, so as to limit the number of rules being fed to
.. (URE...!?) ... to control combinatorial explosion.

Amen's code uses words like "drives", "desires", "goals", which can be
interpreted either as human psychological states, or as abstract
rule-selection algorithms.  I am very interested in the later, mostly
because the later is actually useful, whereas, as a model of human
psychological state, its a real shitty model.   So I really want to ditch
"psi/psy" cause its kind-of got almost nothing to do with that.

I don't know of a good alternative name for it, though.

>
> 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.
>

To me, its just a plain-old rule engine. To me, cognition is recognizing
and learning patterns.  Whatever.  I guess we could/should have a
discussion about the opencog meta-architecture someday.

I like to avoid human psychological terms, like "cognition" and
"psychology" for the components we are building, cause they seem to mislead
and confuse people about what they can and cannot do. I'm not sure I know
what "cognition" even means.

--linas

>
> Nil
>
>
>>
>> Nil
>>
>> On 03/15/2018 07:56 AM, Linas Vepstas wrote:
>>
>>
>>
>> On Thu, Mar 15, 2018 at 12:37 AM, Alexey Potapov
>> mailto: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 a

Re: [opencog-dev] Re: Pattern Matching performance

2018-03-16 Thread Linas Vepstas

On Thu, Mar 15, 2018 at 2:13 PM, Alexey Potapov  wrote:

>
>> How many domains are there? one? two? three?  "satisfiability modulo
>> theories"
>> That's what those words mean.
>>
>
> Any relation based on individual properties of objects.
>

I think we are talking past each other.  The pattern matcher already
handles arbitrary non-numeric individual properties of objects.  So I can't
tell what you have in mind here.

When I say "theory", perhaps the easiest way to think about it, from the
point of view of the pattern matcher, is some function that returns true or
false.   Since theories typically have special-case algorithms to make them
run fast, they would be implemented as some block of C++ code ... that
returns true or false to the pattern matcher.

In mathematics, a "theory" is a collection of "axioms": for example, "group
theory" or "linear algebra" and so on. Having "group theory"  as a module
inside the pattern matcher seems fairly useless.  The one "theory" we do
want to have is that if 3D space plus time. But again, this is currently
very immature.  Another "theory" would be neural nets, I have some
unfinished ideas on this, but need to write them up in detail.

> The problem is very small: PM enumerates virtual links for every pair of
> nodes, making it O(N^2), while without such link similar queries are
> executed in O(N).
>

Well, yes. If you have a predicate that takes M arguments and has N values,
then an exhaustive search will take O(N^M). That is mild form of
"combinatoric explosion".  GreaterThan takes two arguments, so M=2, so its
O(N^2).  Avoiding combinatoric explosion requires an algorithm that knows
something special about the data, and can avoid it in some way.

If you do NOT want an exhaustive search, then you have several options:
one is to design a query that limits the possibilities in some way. Another
is to implement a "theory"; and there are several ways to do that, some
very low-brow, and some very fancy. So far, I'm the only one who has tried
to do this within the pattern matcher, and my explorations are minimal. We
could use your problem as an early test case in how to expand support for
this kind of thing.  I have several ideas how this could be done, but don't
want to propose an answer here and now because I don't understand what you
are trying to do, or how sophisticated the solution needs to be.  (I prefer
simple, minimal solutions, instead of big complex ones).

We would need to have a distinct email chain where you describe one or more
problems, and I could describe how they could be solved.

Start this by explaining, again, what it is that you are trying to do, and
what algorithm solves it efficiently.

-- 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/CAHrUA35ZqcUtPKP%2BKyPr_dLew3hOiQZyyW--Umztr2tG%3Djwn3Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] Re: Pattern Matching performance

2018-03-15 Thread Ben Goertzel

BTW I did not forget this thread but got busy, I will respond on the weekend ;)

On Thu, Mar 15, 2018 at 9:19 PM, Alexey Potapov  wrote:
> FYI we have experimented with several other similar knowledge bases and
> queries including NumberNode and GreaterThanLink, and for all of them PM
> works fine in linear time. So, there is no common problem with virtual
> links. We just accidentally started with an unlikely pathological example,
> which might not be too interesting to study, although it causes some minor
> concerns.
>
> 2018-03-15 13:20 GMT+03:00 Alexey Potapov :
>>
>>
>>>
>>> And forget the 10 thousand number.  No human can do that, not from
>>> memory.
>>
>>
>> I guess you are wrong. There are people who can recall any of 1 go
>> games. Why shouldn't people be able to solve simpler tasks, at least if they
>> are professionally dedicated to them? Also, as well studied by Vygotsky and
>> others, people from primitive societies have much better recall from
>> episodic memory.
>> But, ok, let's assume you are right. My claim: no human can solve zebra
>> puzzle in their mind, but the backward chainer with PM can. So, let's not
>> use them in AGI. Is this right conclusion from your arguments?
>>
>
> --
> 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/CABpRrhw5nQ6AhCNGBRBKGSUM-pBSy3JtQ%2B%3DXw_WM%3DFoLnPdXCQ%40mail.gmail.com.
>
> For more options, visit https://groups.google.com/d/optout.



-- 
Ben Goertzel, PhD
http://goertzel.org

"In the province of the mind, what one believes to be true is true or
becomes true, within certain limits to be found experientially and
experimentally. These limits are further beliefs to be transcended. In
the mind, there are no limits In the province of connected minds,
what the network believes to be true, either is true or becomes true
within certain limits to be found experientially and experimentally.
These limits are further beliefs to be transcended. In the network's
mind there are no limits." -- John Lilly

-- 
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/CACYTDBfLNX_dHMeLwvgv1w8sARz9%3DpriOKbVnYXGzVuJydqHYQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] Re: Pattern Matching performance

2018-03-15 Thread Alexey Potapov

FYI we have experimented with several other similar knowledge bases and
queries including NumberNode and GreaterThanLink, and for all of them PM
works fine in linear time. So, there is no common problem with virtual
links. We just accidentally started with an unlikely pathological example,
which might not be too interesting to study, although it causes some minor
concerns.

2018-03-15 13:20 GMT+03:00 Alexey Potapov :

>
>
>> And forget the 10 thousand number.  No human can do that, not from memory.
>>
>
> I guess you are wrong. There are people who can recall any of 1 go
> games. Why shouldn't people be able to solve simpler tasks, at least if
> they are professionally dedicated to them? Also, as well studied by
> Vygotsky and others, people from primitive societies have much better
> recall from episodic memory.
> But, ok, let's assume you are right. My claim: no human can solve zebra
> puzzle in their mind, but the backward chainer with PM can. So, let's not
> use them in AGI. Is this right conclusion from your arguments?
>
>

-- 
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/CABpRrhw5nQ6AhCNGBRBKGSUM-pBSy3JtQ%2B%3DXw_WM%3DFoLnPdXCQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] Re: Pattern Matching performance

2018-03-15 Thread Alexey Potapov

> And forget the 10 thousand number.  No human can do that, not from memory.
>

I guess you are wrong. There are people who can recall any of 1 go
games. Why shouldn't people be able to solve simpler tasks, at least if
they are professionally dedicated to them? Also, as well studied by
Vygotsky and others, people from primitive societies have much better
recall from episodic memory.
But, ok, let's assume you are right. My claim: no human can solve zebra
puzzle in their mind, but the backward chainer with PM can. So, let's not
use them in AGI. Is this right conclusion from your arguments?

-- 
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/CABpRrhzW670LOETn4om7Ps1gEtve15072JC_ao3PU52veW498A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] Re: Pattern Matching performance

2018-03-15 Thread Alexey Potapov

>
> Again, the real question is: how is opencog going to learn about
> relational algebras and what SQL is and how to use it?
>

And how is it going to learn about Pattern Matching as an external tool...

-- 
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/CABpRrhz8ZU5oHpt8Q2K-KekPHBeVW299Pmpe9VYC5fS7%2BU1G0g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] Re: Pattern Matching performance

2018-03-14 Thread 'Nil Geisweiller' via opencog


On 03/15/2018 08:19 AM, Linas Vepstas wrote:



On Thu, Mar 15, 2018 at 1:12 AM, Nil Geisweiller 
mailto:ngeis...@googlemail.com>> 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
mailto: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 obje

Re: [opencog-dev] Re: Pattern Matching performance

On Thu, Mar 15, 2018 at 1:18 AM, Nil Geisweiller 
wrote:

>
> What I had understood was to have the PM delegates to the space server
> space-related queries, but this would be transparent to the user, so it
> does require to hack the PM in that respect, maybe it's a non trivial hack,
> BTW.
>

Its a non-trivial hack. I mean, I suppose there are some easy hacks.
They're probably ugly.  Getting something more elegant would require
actually working through 2 or 3 "typical use cases", figuring out what the
atomese for these should be, and then implementing it.   I don't think its
"hard" -- I think a staff programmer (not junior programmer) could
implement this after a few months, with appropriate guidance and help.

The steps are:
1) Figure out what knowledge you want to query
2) what the "best" algorithm is for performing that query is
3) design some new atoms to provide an API to that algorithm
4) write the code to implement the algo.

The pattern matcher will mostly "automatically" do the rest.

--linas

>
> Nil
>

-- 
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/CAHrUA37ax-8XpO62BFejLRTDzZLOyPVwYRd6Z_CdZT-3Muv7Qw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] Re: Pattern Matching performance

OK, we will not consider this problem.

2018-03-15 9:14 GMT+03:00 Linas Vepstas :

>
>
> On Thu, Mar 15, 2018 at 12:54 AM, Alexey Potapov 
> wrote:
>
>>
>>>
 > You can say: just don't use PM for such queries.
>>>
>>>
>>> Why not?  For certain kinds of basic prepositional queries, such as
>>> taller, closer, larger, next-to, above, behind, is-a-part-of, is related-to
>>> -- we need a good, effective query system for those, Currently, the pattern
>>> matcher cannot do many or even most of these, but the engineering needed to
>>> make it effective is not hard. The needed changes, improvements,
>>> enhancements are straight-forward.
>>>
>>
>> Man, I don't understand you... Initially, I proposed to consider the
>> possibility of performing such tweaking, but you started to argue: use
>> space-server, use SQL, use whatever you want exect PM... I have almost
>> agreed: OK, we will not touch PM... But now you say: it's not a hard
>> problem. So, what was all this discussion about?..
>>
>
> OK, I won't be able to answer email for 48 hours, but in short, I don't
> understand what you don't understand, then.
>
> The pattern matcher does not support human natural-language type
> prepositional queries.  It could, but it would require at least two or
> three things: a far more sophisticated and advanced space server, and a
> knowledge representation system for prepositions.
>
> The pattern matcher is trying to be agnostic about knowledge
> representation. It is trying to not impose any predefined knowledge
> representation system.   Concepts like "near" and "far" are knowledge, you
> have to figure out how to represent them.  Once you have done this, the
> pattern matcher can run queries.
>
> When I say SQL, I mean "think of a relational algebra". Formally,
> relational algebras are model "structures" which have no function
> signatures and only relation signatures. SQL is meant to be a generic
> example of a relational algebra is.  SQL servers were originally designed
> to implement relational algebras.
>
> There are 3 kinds of "problems" -easy, medium and hard
>
> Easy problem: any problem that a team of 5-20 competent programmers can
> solve in a year or two (or less).
>
> Medium problem: any easy problem that requires more money, resources, and
> executive management, but is solvable by standard engineering practice.
>
> Hard problem: creating algorithms that learn, in the AGI sense of "learn".
>
> Improving the pattern matcher, adding features to it, etc. is an "easy"
> problem.  Some improvements might take days, or weeks, or months, or years,
> but none of the improvemnts are technically hard. Ordinary programmers with
> some general interest in algorithms such as satisfiability, relational
> algebra, universal algebra, logic, etc. can do it.  Most database and
> compiler people have a pretty good grounding in satisfiability and
> relational algebras, and stuff of that sort.  These skills are available on
> the job market.
>
> 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/CABpRrhxgxRX2UN2VOOPawOhD54ZNVDPQq6D2dRRzh_chZLTtEg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] Re: Pattern Matching performance

On Thu, Mar 15, 2018 at 1:12 AM, Nil Geisweiller 
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.


> It does
> involve defining a distance measure though.


Spacetime server dines one. But its super-naive, and not integrated with
pattern matcher.


> 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


?  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.


> (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

>
> Nil
>
> On 03/15/2018 07:56 AM, Linas Vepstas wrote:
>
>
>>
>> On Thu, Mar 15, 2018 at 12:37 AM, Alexey Potapov > > 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
>> "sat

Re: [opencog-dev] Re: Pattern Matching performance

2018-03-14 Thread 'Nil Geisweiller' via opencog

On 03/15/2018 07:54 AM, Alexey Potapov wrote:

> You can say: just don't use PM for such queries.

Why not? For certain kinds of basic prepositional queries, such as
taller, closer, larger, next-to, above, behind, is-a-part-of, is
related-to -- we need a good, effective query system for those,
Currently, the pattern matcher cannot do many or even most of these,
but the engineering needed to make it effective is not hard. The
needed changes, improvements, enhancements are straight-forward.

Man, I don't understand you... Initially, I proposed to consider the
possibility of performing such tweaking, but you started to argue: use
space-server, use SQL, use whatever you want exect PM... I have almost
agreed: OK, we will not touch PM... But now you say: it's not a hard
problem. So, what was all this discussion about?..

What I had understood was to have the PM delegates to the space server
space-related queries, but this would be transparent to the user, so it
does require to hack the PM in that respect, maybe it's a non trivial
hack, BTW.

Nil

--
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/24000621-b49b-d326-7da7-8c536703c5cd%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] Re: Pattern Matching performance

On Thu, Mar 15, 2018 at 12:54 AM, Alexey Potapov  wrote:

>
>>
>>> > You can say: just don't use PM for such queries.
>>
>>
>> Why not?  For certain kinds of basic prepositional queries, such as
>> taller, closer, larger, next-to, above, behind, is-a-part-of, is related-to
>> -- we need a good, effective query system for those, Currently, the pattern
>> matcher cannot do many or even most of these, but the engineering needed to
>> make it effective is not hard. The needed changes, improvements,
>> enhancements are straight-forward.
>>
>
> Man, I don't understand you... Initially, I proposed to consider the
> possibility of performing such tweaking, but you started to argue: use
> space-server, use SQL, use whatever you want exect PM... I have almost
> agreed: OK, we will not touch PM... But now you say: it's not a hard
> problem. So, what was all this discussion about?..
>

OK, I won't be able to answer email for 48 hours, but in short, I don't
understand what you don't understand, then.

The pattern matcher does not support human natural-language type
prepositional queries.  It could, but it would require at least two or
three things: a far more sophisticated and advanced space server, and a
knowledge representation system for prepositions.

The pattern matcher is trying to be agnostic about knowledge
representation. It is trying to not impose any predefined knowledge
representation system.   Concepts like "near" and "far" are knowledge, you
have to figure out how to represent them.  Once you have done this, the
pattern matcher can run queries.

When I say SQL, I mean "think of a relational algebra". Formally,
relational algebras are model "structures" which have no function
signatures and only relation signatures. SQL is meant to be a generic
example of a relational algebra is.  SQL servers were originally designed
to implement relational algebras.

There are 3 kinds of "problems" -easy, medium and hard

Easy problem: any problem that a team of 5-20 competent programmers can
solve in a year or two (or less).

Medium problem: any easy problem that requires more money, resources, and
executive management, but is solvable by standard engineering practice.

Hard problem: creating algorithms that learn, in the AGI sense of "learn".

Improving the pattern matcher, adding features to it, etc. is an "easy"
problem.  Some improvements might take days, or weeks, or months, or years,
but none of the improvemnts are technically hard. Ordinary programmers with
some general interest in algorithms such as satisfiability, relational
algebra, universal algebra, logic, etc. can do it.  Most database and
compiler people have a pretty good grounding in satisfiability and
relational algebras, and stuff of that sort.  These skills are available on
the job market.

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/CAHrUA343z3-2YBeS%3D_en1vCTb9rkUTySpJkMPBXFoasF-ycfqg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] Re: Pattern Matching performance

>
>
> How many domains are there? one? two? three?  "satisfiability modulo
> theories"
> That's what those words mean.
>

Any relation based on individual properties of objects.


>
> I'm totally confused. "Greater than" is just a theory. Its like any other
> theory.
> What exactly, is the problem here?
>

The problem is very small: PM enumerates virtual links for every pair of
nodes, making it O(N^2), while without such link similar queries are
executed in O(N).


> 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.
>

They are in the same group. Maybe the representation is crappy, maybe
algorithms...

-- 
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/CABpRrhz3uLkfmgY_qoJLrkfR5%2B6y%2B9V_RZxqG-nUizox06newQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] Re: Pattern Matching performance

2018-03-14 Thread 'Nil Geisweiller' via opencog

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 > 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/d71db589-f161-b4a3-f19e-6b78cd3072fe%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] Re: Pattern Matching performance

On Thu, Mar 15, 2018 at 12:37 AM, Alexey Potapov  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.

Re: [opencog-dev] Re: Pattern Matching performance

>
>
>
>> > You can say: just don't use PM for such queries.
>
>
> Why not?  For certain kinds of basic prepositional queries, such as
> taller, closer, larger, next-to, above, behind, is-a-part-of, is related-to
> -- we need a good, effective query system for those, Currently, the pattern
> matcher cannot do many or even most of these, but the engineering needed to
> make it effective is not hard. The needed changes, improvements,
> enhancements are straight-forward.
>

Man, I don't understand you... Initially, I proposed to consider the
possibility of performing such tweaking, but you started to argue: use
space-server, use SQL, use whatever you want exect PM... I have almost
agreed: OK, we will not touch PM... But now you say: it's not a hard
problem. So, what was all this discussion about?..

-- 
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/CABpRrhx%2BC5jb0n_xJSjsNHBG3bVXen3oRXssqsda85zSYRZbSg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] Re: Pattern Matching performance

>
>
> 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?


>
> 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?


>
> 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.


>
> It begs the question "OK but how would
> something analogous to a computer-algebra engine be learned via
> experience" 
>

Yes, this is also the right question, although the considered problem is
not necesserily related to it.


> Human memory is very *constructive*.   Rather than searching among stored
> memories, as in a database search or whatever, the "pattern matching" done
> when a human mind searches its memory is a matter of inventing memories
> that match the pattern being searched for.


Yeah, I know. I just tried to imagine OpenCog in place of human mind. So,
does OpenCog have anything to perform memory quering? For me, PM was a
natural candidate. But we can consider the backward chainer.


> What human memory search does is way more like PLN abductive inference
> based on the cues of stored memories (existing patterns) ...
>

So, you just say, we shouldn't use PM to match data pattern, but should use
it to match patterns describing some general rules?


>
> One jewel of wisdom from Pei Wang is: Almost all algorithms used by
> human-like
> minds have exponential complexity in worst case
>

I doubt this is true for unconcsious algorithms. Or, at least, they are
any-time algorithms. They will rather fail than run for more than a certain
time.


>
> My gut reaction is it's perhaps often better to think about PLN
> backward chainer (which uses the
> URE which uses the PM).   I.e. often, instead of thinking about
> custom callbacks to the PM,
> one can think about custom domain-specific inference rules to use within
> PLN...
>

Maybe. So, what rules will work in this case?

-- 
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/CABpRrhyVVUX4_ohu6%2BjEMu1h6Wk%3DKj-7yhYxV5V3gQ0nk3Nucg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] Re: Pattern Matching performance

On Wed, Mar 14, 2018 at 8:29 PM, Ben Goertzel  wrote:

> Let me preface this by noting that I am really psyched we are having this
> sort of discussion ;) ...
>

I agree with Ben; and have nothing to add to his replies. So below is a
different slant on things.

>
> > - Let's imagine I know 1 people, and I'm asked if I know a family in
> > which the difference in ages of two children is larger than 15 years (a
> wife
> > is taller than a husband more than by 20 cm, or whatever you want). Such
> > dataset and query are essentially the same as in our example with video
> > frames and bounding boxes, and PM behavior will be the same. Should
> > information about these people be stored in the long-term memory? Sure.
> > Should we use space-server to deal with this query? I guess, no. By what
> > means should this query be answered?
>

Umm, except you don't know that many people. Lets reduce it to the number
of people you actually know.  Personally, I would not be able to answer
that question, not without a lot of work. I would have to spend a lot of
time trying to think of everyone I know -- that alone could take hours or
more. Then I would have to imagine their ages or heights.  Try to imagine
how much 20 centimeters is, in ordinary social situations. Find a ruler,
stare at it for a while. Try to imagine those two people standing next to
one another, mentally painting a ruler next to them.  If you wanted an
accurate answer it would take me a day. Its not a question that any normal
human can answer.  And forget the 10 thousand number.  No human can do
that, not from memory.

The correct answer is: use a mental prosthesis.  Write a database, populate
the database with statistics about 1 people, and perform an SQL query
on it. Bingo. Fast. Easy.  So the real question is: How does AGI go about
building a database?   How can we teach opencog about databases and about
programming, that, when faced with such a question, it would be able to
surf the net, evaluate competing sql products, pick one, download it, read
the API documentation, write some code, stuff it with info about 1
people, write an SQL query, and then provide the answer?   *That* is what I
want opencog to be able to do.

Again, the real question is: how is opencog going to learn about relational
algebras and what SQL is and how to use it? How to surf the net?  How is it
going to learn how to normalize database tables? That's the problem we have
to solve.

> So this is an arithmetic query, rather than a spatial query --

Certainly for a handful of special cases, (such as this)  we could write
special-case code.  Size, age, nearness/distance relations are all
important. So is next-to, behind, is-a-part-of. We need code to handle all
those cases fairly quickly, fairly effectively.

>
> > - I'm asked, "Do you remember a scene in any film, in which a planet was
> > inside a luggage locker"? My brain says: "Yeah, I remember!".

You must be watching some crazy films!

> But if I'm
> > asked: "Do you remember a scene in a film, in which there was a flower
> pot
> > more than 30 cm above a bed?"... Huh, maybe, I need to think... My brain
> > will not go into a loop for 10 billion years.

Perhaps you intended to talk about the pattern matcher, but that is
perfectly silly.  Don't build a system like that.  This is a solvable
problem, and the solution is actually quite easy.  Computer engineers have
been solving this particular problem since the invention of computers. Its
not a valid complaint.

>
> > You can say: just don't use PM for such queries.

Why not?  For certain kinds of basic prepositional queries, such as taller,
closer, larger, next-to, above, behind, is-a-part-of, is related-to -- we
need a good, effective query system for those, Currently, the pattern
matcher cannot do many or even most of these, but the engineering needed to
make it effective is not hard. The needed changes, improvements,
enhancements are straight-forward.

Its a red herring, to argue about NP-completeness.

AGI-wise, this is NOT where the hard problem lies.  It is work that we need
to do for opencog, but that's the easy part.  Some clever systems
programmers, with a bit of scientific guidance, could assemble a reasonable
practical system. Self-driving cars already do a lot./most of this kind of
stuff, in real time(!)  Even though driving a car, as a task, is
NP-complete!This ain't rocket science.  Its not where the hard part
lies.

>
> My gut reaction is it's perhaps often better to think about PLN
> backward chainer (which uses the
> URE which uses the PM).   I.e. often, instead of thinking about
> custom callbacks to the PM,
> one can think about custom domain-specific inference rules to use within
> PLN...
>

This is more interesting.  Nil and I were talking, and I believe that a
very reasonable approach would be to approximate PLN by a fast crisp-logic
chainer, and then compute probabilities by sampling over crisp-logic inputs
to the chainer. Yes,

Re: [opencog-dev] Re: Pattern Matching performance

2018-03-14 Thread Ben Goertzel

Let me preface this by noting that I am really psyched we are having this
sort of discussion ;) ...

> - Let's imagine I know 1 people, and I'm asked if I know a family in
> which the difference in ages of two children is larger than 15 years (a wife
> is taller than a husband more than by 20 cm, or whatever you want). Such
> dataset and query are essentially the same as in our example with video
> frames and bounding boxes, and PM behavior will be the same. Should
> information about these people be stored in the long-term memory? Sure.
> Should we use space-server to deal with this query? I guess, no. By what
> means should this query be answered?

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...

For questions regarding numerical comparison, we have GreaterThanLink

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 ...

Or one could tweak the PM to use the backward chainer only when encountering
a GreaterThanLink, and just do plain vanilla pattern matching otherwise...

This is a pragmatic solution but obviously doesn't solve the
underlying conceptual
AGI-related problem.   It begs the question "OK but how would
something analogous
to a computer-algebra engine be learned via experience" 

The "engine" part of a computer algebra engine can just be the URE.
So then the
question is how can the rules of algebra be learned from experience.
But this is
straightforward inductive reasoning from a bunch of examples...

QED

;)


> - I'm asked, "Do you remember a scene in any film, in which a planet was
> inside a luggage locker"? My brain says: "Yeah, I remember!". But if I'm
> asked: "Do you remember a scene in a film, in which there was a flower pot
> more than 30 cm above a bed?"... Huh, maybe, I need to think... My brain
> will not go into a loop for 10 billion years. It simply will not evaluate
> all possibilities. It will search only among already evaluated subgraphs.
> And if it fails, it will try to come up with a special search strategy. So,
> the unconscious process of recalling is restricted to matching existing
> patterns. I remember about the planet, because my brain evaluated Inside
> predicate when I saw the film, cause it found this interesting or
> surprising. It doesn't evaluate this predicate during answering the query.
> Do we need a space-server for this? Maybe. Do we need PM for this? Maybe,
> but with restricted permissions.

Hey, this is incorrect as a statement about how human memory works...

Human memory is very *constructive*.   Rather than searching among stored
memories, as in a database search or whatever, the "pattern matching" done
when a human mind searches its memory is a matter of inventing memories
that match the pattern being searched for.   This is very well documented
and is why stuff like eyewitness evidence of crimes is so fucked up...

What human memory search does is way more like PLN abductive inference
based on the cues of stored memories (existing patterns) ...


> - NP-complete problems... Yeah, there are a lot of them. But we don't use
> unconscious-level algorithms with exponential complexity to solve them. We
> either slowly solve them on the conscious level, or slowly learn to solve
> them approximately, but fast on the unconscious level. My claim is trivial:
> we just should avoid the possibility that some question hangs our AGI system
> forever.

One jewel of wisdom from Pei Wang is: Almost all algorithms used by human-like
minds have exponential complexity in worst case

The point is they have tractable time in the average case, relative to
the probability
distribution over problems that is relevant to the organism/mind in
question, for
problem sizes relevant to the organism/mind in question etc.

> You can say: just don't use PM for such queries. Well, OK... But I guess, PM
> is a powerful enough tool to cope with them in a reasonable time, either
> being provided with appropriate callbacks represented in Atomese, or by some
> other means. Right now, we don't propose anything. We just ask: is there any
> sense in studying PM on the example of this problem?

My gut reaction is it's perhaps often better to think about PLN
backward chainer (which uses the
URE which uses the PM).   I.e. often, instead of thinking about
custom callbacks to the PM,
one can think about custom domain-specific inference rules to use within PLN...

But sometimes one may want to think about custom callbacks as well, I
wouldn't want to rule
it out totally...

ben

-- 
You received this me

[opencog-dev] Re: Pattern Matching performance

2018-03-13 Thread Linas Vepstas

On Tue, Mar 13, 2018 at 3:14 AM, Alexey Potapov  wrote:

> Efficient data structures and algos to deal with numeric data are
> necessary,
>

What kind of numeric data?  Again, please note that the atomspace has two
classes of data: peristent, immutable, globally-unique  "Atoms" which are
slow in part because they are indexed: they are used to represent
"knowledge". The NumberNode is an atom.

The other type are "Values" (sich as truth values) which are temporary,
fleeting, non-unique, not indexed/indexable. And much faster. FloatValue is
a value. Its actually a vector of floats.

Both NumberNodes and FloatValues store numbers, but they have very
different performance characteristics, and are meant to solve different
classes of problems.

> although the queries to episodic memory may be as complex as to pattern
> matcher.
>

Sure. If by "episodic" you mean time and 3D locations, then yes. Like I
said, the space-server is very naive. It would be nice if the space server
were actually episodic memory, but it isn't.

> But even with this additional module, the conceptual problem with PM
> remains.
>

What conceptual problem is that?

> A fixed algo for solving an NP-complete problem cannot be a basis for
> intelligence. Period.
>

Eh? Just because a problem is NP complete does not mean that it doesn't
contain sub-problems that are solvable much much faster.  Pattern matcher
queries for single variables will run in log(N) time, or worst-case O(N)
time. But you can also create queries that are pathologically perverse.

Take, for example, SAT solvers.  They are commonly used to model 64-bit
CPU's. Modelling a three-register operation on a CPU requires exploring
2^(64+64+64) = 2^192 possibilities, which is more than there are atoms in
our local galaxy cluster.  It is literally an astronomic number. Yet SAT
solvers solve this in fractions of a second.  There's a reason for that.
Just because a problem is NP complete, doesn't mean that it has to be slow.

Of course, if your 64-bit CPU has instructions that implement cryptographic
hashes in hardware, and hand it to the same SAT solver as before, don't be
surprised if that millisecond computation suddenly takes years to
complete.   SAT cannot magically factor large primes.

Life, the universe, and everything is NP complete. That's just how it is.

> I'll answer to Linas in more detail later...
>

-- I  don't always respond to email quickly. If its important, please nag
me.

--linas

>
> 2018-03-13 10:52 GMT+03:00 Ben Goertzel :
>
>> Yes, if the problem at hand is
>>
>> ***
>> It just searches for pairs of bounding boxes one of which is higher
>> than another within the same frame.
>> ***
>>
>> then it should be possible to fairly simply craft some optimized way
>> to solve this using the SpaceServer ...
>>
>> Basically the SpaceServer gives an octree (or quadtree) index for a
>> set of Atoms that correspond to coordinate values in some common 3D or
>> 2D space..
>>
>> The situation is similar to with spatial DBs versus standard
>> relational DBs   For some queries a spatial DB is massively more
>> efficient due to the types of indexes it contains...
>>
>> For some PM queries, using the octree/quadtree index in the
>> SpaceServer will be much more efficient than just using the
>> Atomspace...
>>
>> Right now however the PM is not connected to the SpaceServer, i.e. if
>> a predicate or schema that would be rapidly evaluated/executed using
>> the SpaceServer is encountered, it is not currently evaluated/executed
>> that way...
>>
>> So linking the PM to the SpaceServer would be clearly beneficial for
>> many applications and would enable space and/or time related PM
>> queries to get resolved much more rapidly...
>>
>> -- ben
>>
>>
>> On Tue, Mar 13, 2018 at 3:30 PM, Nil Geisweiller
>>  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.
>> >
>> > I know almost nothing about the current state of space server so take my
>> > comment with a grain of salt...
>> >
>> > 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...
>> >
>> > 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

[opencog-dev] Re: Pattern Matching performance

2018-03-13 Thread Linas Vepstas

On Tue, Mar 13, 2018 at 2:52 AM, Ben Goertzel  wrote:

>
> So linking the PM to the SpaceServer would be clearly beneficial for
> many applications and would enable space and/or time related PM
> queries to get resolved much more rapidly...
>

Yes.

I'm far less interested in raw speed, than clever robot tricks.  I'd like
to talk
to the robot about what it sees, and use words like "near", "far", "in
front",
"behind".   These kinds of queries need to go through the ordinary pattern
matcher for he usual reasons, and through the space server to, of course,
and if the two are not well-integrated, you just get hacky spaghetti code.

Its a significant project

--linas

>
> -- ben
>
>
> On Tue, Mar 13, 2018 at 3:30 PM, Nil Geisweiller
>  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.
> >
> > I know almost nothing about the current state of space server so take my
> > comment with a grain of salt...
> >
> > 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...
> >
> > 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  >
> >> 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 
> > 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

[opencog-dev] Re: Pattern Matching performance

2018-03-13 Thread Linas Vepstas

On Tue, Mar 13, 2018 at 2:30 AM, Nil Geisweiller 
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 
>> wrote:
>>
>>> OK, trying again. Maybe the third time it will work right.
>>>
>>> -- Linas
>>>
>>> On Tue, Mar 13, 2018 at 12:04 AM, Linas Vepstas 
>>> 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 
 wrote:

> Hi,
>
> To repeat my earlier remarks, and add a few more:
>
> On Mon, Mar 12, 2018 at 3:42 PM, Alexey Potapov 
> 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 ca

[opencog-dev] Re: Pattern Matching performance

2018-03-13 Thread Ben Goertzel

That said, I like the idea of having automated learning used to learn
predicates that serve in the PM callbacks

On Tue, Mar 13, 2018 at 4:41 PM, Ben Goertzel  wrote:
> Conceptually --
> A fixed algo for solving NP-complete problems of a particular type, of
> bounded size  intelligence...
>
>
>
> On Tue, Mar 13, 2018 at 4:14 PM, Alexey Potapov  wrote:
>> Efficient data structures and algos to deal with numeric data are necessary,
>> although the queries to episodic memory may be as complex as to pattern
>> matcher.
>> But even with this additional module, the conceptual problem with PM
>> remains. A fixed algo for solving an NP-complete problem cannot be a basis
>> for intelligence. Period.
>> I'll answer to Linas in more detail later...
>>
>> 2018-03-13 10:52 GMT+03:00 Ben Goertzel :
>>>
>>> Yes, if the problem at hand is
>>>
>>> ***
>>> It just searches for pairs of bounding boxes one of which is higher
>>> than another within the same frame.
>>> ***
>>>
>>> then it should be possible to fairly simply craft some optimized way
>>> to solve this using the SpaceServer ...
>>>
>>> Basically the SpaceServer gives an octree (or quadtree) index for a
>>> set of Atoms that correspond to coordinate values in some common 3D or
>>> 2D space..
>>>
>>> The situation is similar to with spatial DBs versus standard
>>> relational DBs   For some queries a spatial DB is massively more
>>> efficient due to the types of indexes it contains...
>>>
>>> For some PM queries, using the octree/quadtree index in the
>>> SpaceServer will be much more efficient than just using the
>>> Atomspace...
>>>
>>> Right now however the PM is not connected to the SpaceServer, i.e. if
>>> a predicate or schema that would be rapidly evaluated/executed using
>>> the SpaceServer is encountered, it is not currently evaluated/executed
>>> that way...
>>>
>>> So linking the PM to the SpaceServer would be clearly beneficial for
>>> many applications and would enable space and/or time related PM
>>> queries to get resolved much more rapidly...
>>>
>>> -- ben
>>>
>>>
>>> On Tue, Mar 13, 2018 at 3:30 PM, Nil Geisweiller
>>>  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.
>>> >
>>> > I know almost nothing about the current state of space server so take my
>>> > comment with a grain of salt...
>>> >
>>> > 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...
>>> >
>>> > 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
>>> >> 
>>> >> wrote:
>>> >>>
>>> >>> OK, trying again. Maybe the third time it will work right.
>>> >>>
>>> >>> -- Linas
>>> >>>
>>> >>> On Tue, Mar 13, 2018 at 12:04 AM, Linas Vepstas
>>> >>> 
>>> >>> 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
>>>  
>>>  wrote:
>>> >
>>> > Hi,
>>> >
>>> > To repeat my earlier remarks, and add a few more:
>>> >
>>> > On Mon, Mar 12, 2018 at 3:42 PM, Alexey Potapov 
>>> > 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

[opencog-dev] Re: Pattern Matching performance

2018-03-13 Thread Ben Goertzel

Conceptually --
A fixed algo for solving NP-complete problems of a particular type, of
bounded size  wrote:
> Efficient data structures and algos to deal with numeric data are necessary,
> although the queries to episodic memory may be as complex as to pattern
> matcher.
> But even with this additional module, the conceptual problem with PM
> remains. A fixed algo for solving an NP-complete problem cannot be a basis
> for intelligence. Period.
> I'll answer to Linas in more detail later...
>
> 2018-03-13 10:52 GMT+03:00 Ben Goertzel :
>>
>> Yes, if the problem at hand is
>>
>> ***
>> It just searches for pairs of bounding boxes one of which is higher
>> than another within the same frame.
>> ***
>>
>> then it should be possible to fairly simply craft some optimized way
>> to solve this using the SpaceServer ...
>>
>> Basically the SpaceServer gives an octree (or quadtree) index for a
>> set of Atoms that correspond to coordinate values in some common 3D or
>> 2D space..
>>
>> The situation is similar to with spatial DBs versus standard
>> relational DBs   For some queries a spatial DB is massively more
>> efficient due to the types of indexes it contains...
>>
>> For some PM queries, using the octree/quadtree index in the
>> SpaceServer will be much more efficient than just using the
>> Atomspace...
>>
>> Right now however the PM is not connected to the SpaceServer, i.e. if
>> a predicate or schema that would be rapidly evaluated/executed using
>> the SpaceServer is encountered, it is not currently evaluated/executed
>> that way...
>>
>> So linking the PM to the SpaceServer would be clearly beneficial for
>> many applications and would enable space and/or time related PM
>> queries to get resolved much more rapidly...
>>
>> -- ben
>>
>>
>> On Tue, Mar 13, 2018 at 3:30 PM, Nil Geisweiller
>>  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.
>> >
>> > I know almost nothing about the current state of space server so take my
>> > comment with a grain of salt...
>> >
>> > 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...
>> >
>> > 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
>> >> 
>> >> wrote:
>> >>>
>> >>> OK, trying again. Maybe the third time it will work right.
>> >>>
>> >>> -- Linas
>> >>>
>> >>> On Tue, Mar 13, 2018 at 12:04 AM, Linas Vepstas
>> >>> 
>> >>> 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
>>  
>>  wrote:
>> >
>> > Hi,
>> >
>> > To repeat my earlier remarks, and add a few more:
>> >
>> > On Mon, Mar 12, 2018 at 3:42 PM, Alexey Potapov 
>> > 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

[opencog-dev] Re: Pattern Matching performance

On 03/13/2018 07:22 AM, Linas Vepstas wrote:
 >> 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?

It could perhaps use cxxtest. On the other hand there probably no need 
to touch C++ at all. Maybe a combination of Scheme and bash scripts, or 
which ever way you're comfortable with. I suppose it could automatically 
append the results into a diary, that could perhaps be turned into a 
plot (which poses the problem of making sure the system is the same).

Maybe it should have some functionality to repeat the benchmark a number 
of times and gather some stats (mean and std dev), as there tends to be 
a lot of variance.

Relatedly I wrote this simplistic benchmark tool that merely reruns a 
number of times the unit tests and gather stats

https://github.com/opencog/atomspace/blob/master/scripts/benchmark_utests.sh

the problem is that unit tests are not meant to be representative 
benchmarks. Also benchmarks can be afforded to take more time to run as 
they don't need to run as often as unit tests. Personally I see no 
problem having a benchmark suite taking hours. They might also require 
larger data sets. For these reasons it makes sense to have the benchmark 
tool live in its own repository. I suppose this repository could be 
generally dedicated to OpenCog's benchmarks, or it could be for the 
pattern matcher alone. I don't know.

Nil

--
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/e9e08e4a-8f23-0af5-ad58-8c3f28ea7454%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

[opencog-dev] Re: Pattern Matching performance

2018-03-13 Thread Ben Goertzel

Yes, if the problem at hand is

***
It just searches for pairs of bounding boxes one of which is higher
than another within the same frame.
***

then it should be possible to fairly simply craft some optimized way
to solve this using the SpaceServer ...

Basically the SpaceServer gives an octree (or quadtree) index for a
set of Atoms that correspond to coordinate values in some common 3D or
2D space..

The situation is similar to with spatial DBs versus standard
relational DBs   For some queries a spatial DB is massively more
efficient due to the types of indexes it contains...

For some PM queries, using the octree/quadtree index in the
SpaceServer will be much more efficient than just using the
Atomspace...

Right now however the PM is not connected to the SpaceServer, i.e. if
a predicate or schema that would be rapidly evaluated/executed using
the SpaceServer is encountered, it is not currently evaluated/executed
that way...

So linking the PM to the SpaceServer would be clearly beneficial for
many applications and would enable space and/or time related PM
queries to get resolved much more rapidly...

-- ben


On Tue, Mar 13, 2018 at 3:30 PM, Nil Geisweiller
 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.
>
> I know almost nothing about the current state of space server so take my
> comment with a grain of salt...
>
> 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...
>
> 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 
>> wrote:
>>>
>>> OK, trying again. Maybe the third time it will work right.
>>>
>>> -- Linas
>>>
>>> On Tue, Mar 13, 2018 at 12:04 AM, Linas Vepstas 
>>> 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 
 wrote:
>
> Hi,
>
> To repeat my earlier remarks, and add a few more:
>
> On Mon, Mar 12, 2018 at 3:42 PM, Alexey Potapov 
> 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 "sati

[opencog-dev] Re: Pattern Matching performance

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.


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


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...


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  wrote:

OK, trying again. Maybe the third time it will work right.

-- Linas

On Tue, Mar 13, 2018 at 12:04 AM, Linas Vepstas  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  wrote:

Hi,

To repeat my earlier remarks, and add a few more:

On Mon, Mar 12, 2018 at 3:42 PM, Alexey Potapov  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?

[opencog-dev] Re: Pattern Matching performance


On 03/13/2018 09:20 AM, Nil Geisweiller wrote:
used to manage my emails in Emacs via Wonderlust, but it's much slower 


It's spelled Wanderlust.

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 
 wrote:

OK, trying again. Maybe the third time it will work right.

-- Linas

On Tue, Mar 13, 2018 at 12:04 AM, Linas Vepstas 
 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 
 wrote:

Hi,

To repeat my earlier remarks, and add a few more:

On Mon, Mar 12, 2018 at 3:42 PM, Alexey Potapov 
 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 oth

[opencog-dev] Re: Pattern Matching performance


Linas, your email looked perfectly fine to me.

I would advice you to not use Google webmail interface. Personally, I 
use Thunderbird. It's completely community driven (unlike Firefox), 
allows to read and write emails off-line. The only thing I miss is 
external editor support so I can easily read/write my emails in Emacs (I 
used to manage my emails in Emacs via Wonderlust, but it's much slower 
than Thunderbird).


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  wrote:

OK, trying again. Maybe the third time it will work right.

-- Linas

On Tue, Mar 13, 2018 at 12:04 AM, Linas Vepstas  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  wrote:

Hi,

To repeat my earlier remarks, and add a few more:

On Mon, Mar 12, 2018 at 3:42 PM, Alexey Potapov  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

[opencog-dev] Re: Pattern Matching performance

Hi,

To repeat my earlier remarks, and add a few more:

On Mon, Mar 12, 2018 at 3:42 PM, Alexey Potapov  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 theo

[opencog-dev] Re: Pattern Matching performance

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  wrote:
> OK, trying again. Maybe the third time it will work right.
>
> -- Linas
>
> On Tue, Mar 13, 2018 at 12:04 AM, Linas Vepstas  
> 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  
>> wrote:
>>> Hi,
>>>
>>> To repeat my earlier remarks, and add a few more:
>>>
>>> On Mon, Mar 12, 2018 at 3:42 PM, Alexey Potapov  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 somet

[opencog-dev] Re: Pattern Matching performance

OK, trying again. Maybe the third time it will work right.

-- Linas

On Tue, Mar 13, 2018 at 12:04 AM, Linas Vepstas  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  
> wrote:
>> Hi,
>>
>> To repeat my earlier remarks, and add a few more:
>>
>> On Mon, Mar 12, 2018 at 3:42 PM, Alexey Potapov  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 wh

[opencog-dev] Re: Pattern Matching performance

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  wrote:
> Hi,
>
> To repeat my earlier remarks, and add a few more:
>
> On Mon, Mar 12, 2018 at 3:42 PM, Alexey Potapov  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 c

[opencog-dev] Re: Pattern Matching performance