Re: Pattern Matching performance
98 views
Skip to first unread message
Linas Vepstas
Mar 13, 2018, 12:09:02 AM3/13/18
to Nil Geisweiller, Alexey Potapov, Ben Goertzel, vsb...@gmail.com, opencog
Hi,
On Mon, Mar 12, 2018 at 3:24 AM, Nil Geisweiller
<ngei...@googlemail.com> wrote:
> Hi,
>
> I'm adding Linas, the author of the pattern matcher, who knows it better
> than I do. Also, generally speaking, feel free to use the opencog list, that
> way all opencog community can participate.
>
> On 03/11/2018 09:24 PM, Alexey Potapov wrote:
>>
>> It just searches for pairs of bounding boxes one of which is higher than
>> another /within the same frame/.
>> We expect coordinates of BBs to be compared only within same frame, so the
>> time should depend on the number of frames linearly.
>> Unfortunately, it grows quadratically, and becomes too large for rather
>> short videos.
>
>
> OK, so you're saying that in principle you only need to iterate through the
> frames, and fetching the corresponding coordinates should be constant, thus
> it should be linear overall.
Several remarks, some obvious, some maybe not:
1) The atomspace is optimized for long-term storage of knowledge
representations,
and for certain tasks applied to KR, e.g. subgraph isomorphism
(pattern matching)
2) The atomspace is not optimized for numerical computation or general
computation,
so that adding two numbers with NumberNodes might be thousands if not millions
of times slower than doing it "natively". That said, there are some
interesting stunts
that could improve generic computation by factors of hundreds or
thousands, or more,
if that was desired.
3) Fleeting short-term, rapidly changing data should use Values, not Atoms (!!!)
4) There is some rudimentary support for a "space-time server" to store location
position data, but its not well integrated or refined: its just a
super-naive octree
store. Much work is needed to make it generically useful.
>> Maybe, we could represent these data and queries in a better way, but the
>> problem (with virtual links) seems general. The problem here is that the
>> search is quadratic while it can in principle be linear.
5) The pattern matcher tries to be quite very smart about where to
start searches
and how to move forward in them. However, no one has ever tried to digest
numeric data with it before, so failures of this kind - quadratic vs.
linear, are not
surprising. They're certainly fixable but (probably) not in an
afternoon or two.
At this point, its a rather very complex and elaborate block of code
trying to do
lots of things, and it very much needs a full-time devoted expert to
maintain it.
It will take more than weeks - maybe months to really understand what's going
on inside of it. Viz. It needs an experienced pro, not a code-monkey
to maintain it.
>> The PM
>> documentation says that its computational time can be even exponential for
>> unordered links...
That's not the PM, that's a fundamental mathematical statement about the
isomorphism problem for unordered sets. For N elements to be matched to
N variables, there are N-factorial alternatives. That's not "fixable".
> One would need to look at what the pattern matcher is doing in that
> instance. I suspect it chooses a sub-optimal starting point.
Possibly. See above comments about numbers.
>> I thought that PM is a basic function in sense that it doesn't need to be
>> 'intelligent', but is one of building blocks for 'intelligent' functions
>> like the backward chaining.
Its not "intelligent" but it is complicated. If it looks simple, then
in a certain
sense, we've succeeded. :-) I want software that works well, is easy and
pleasant to use, and looks "simple" to the user.
> what the URE is more suitable for. Although of course the boundary is
> completely blurry, as you know, but you see what I mean.
We're trying to figure out the boundary by touch and feel.
> I think it is solvable. In particular take a look at
> https://github.com/opencog/atomspace/blob/master/opencog/query/InitiateSearchCB.h
Yes. I did not catch the inital part of this, so cannot offer more. But that
is where the inital starting points for a search get picked. I'm
totally swamped
so please don't send me long complicated blobs of code cause I won;t be able
to respond quickly.
>> I believe that either PM should have a guaranteed linear computational
>> time,
The subgraph isomorphism problem is an NP-complete problem, last time
I looked. When its fast, its only because the query is hanging out in the
simple side of the lambda cube.
I think that for "most" queries, the pattern matcher runs in O(SAT) time
that is O(Davis-Putnam) time, because it kind-of-ish performs some of
the similar kind of graph pruning exploration. Sort-of-ish. But only partly.
It could be made more completely Davis-Putnam by someone who has
the brain cells and the time on their hands.
> Nil
>
>>
>> Best regards,
>> Alexey.
Linas.
--
cassette tapes - analog TV - film cameras - you
On Mon, Mar 12, 2018 at 3:24 AM, Nil Geisweiller
<ngei...@googlemail.com> wrote:
> Hi,
>
> I'm adding Linas, the author of the pattern matcher, who knows it better
> than I do. Also, generally speaking, feel free to use the opencog list, that
> way all opencog community can participate.
>
> On 03/11/2018 09:24 PM, Alexey Potapov wrote:
>>
>> It just searches for pairs of bounding boxes one of which is higher than
>> another /within the same frame/.
>> We expect coordinates of BBs to be compared only within same frame, so the
>> time should depend on the number of frames linearly.
>> Unfortunately, it grows quadratically, and becomes too large for rather
>> short videos.
>
>
> OK, so you're saying that in principle you only need to iterate through the
> frames, and fetching the corresponding coordinates should be constant, thus
> it should be linear overall.
Several remarks, some obvious, some maybe not:
1) The atomspace is optimized for long-term storage of knowledge
representations,
and for certain tasks applied to KR, e.g. subgraph isomorphism
(pattern matching)
2) The atomspace is not optimized for numerical computation or general
computation,
so that adding two numbers with NumberNodes might be thousands if not millions
of times slower than doing it "natively". That said, there are some
interesting stunts
that could improve generic computation by factors of hundreds or
thousands, or more,
if that was desired.
3) Fleeting short-term, rapidly changing data should use Values, not Atoms (!!!)
4) There is some rudimentary support for a "space-time server" to store location
position data, but its not well integrated or refined: its just a
super-naive octree
store. Much work is needed to make it generically useful.
>> Maybe, we could represent these data and queries in a better way, but the
>> problem (with virtual links) seems general. The problem here is that the
>> search is quadratic while it can in principle be linear.
5) The pattern matcher tries to be quite very smart about where to
start searches
and how to move forward in them. However, no one has ever tried to digest
numeric data with it before, so failures of this kind - quadratic vs.
linear, are not
surprising. They're certainly fixable but (probably) not in an
afternoon or two.
At this point, its a rather very complex and elaborate block of code
trying to do
lots of things, and it very much needs a full-time devoted expert to
maintain it.
It will take more than weeks - maybe months to really understand what's going
on inside of it. Viz. It needs an experienced pro, not a code-monkey
to maintain it.
>> The PM
>> documentation says that its computational time can be even exponential for
>> unordered links...
That's not the PM, that's a fundamental mathematical statement about the
isomorphism problem for unordered sets. For N elements to be matched to
N variables, there are N-factorial alternatives. That's not "fixable".
> One would need to look at what the pattern matcher is doing in that
> instance. I suspect it chooses a sub-optimal starting point.
Possibly. See above comments about numbers.
>> I thought that PM is a basic function in sense that it doesn't need to be
>> 'intelligent', but is one of building blocks for 'intelligent' functions
>> like the backward chaining.
Its not "intelligent" but it is complicated. If it looks simple, then
in a certain
sense, we've succeeded. :-) I want software that works well, is easy and
pleasant to use, and looks "simple" to the user.
> what the URE is more suitable for. Although of course the boundary is
> completely blurry, as you know, but you see what I mean.
We're trying to figure out the boundary by touch and feel.
> I think it is solvable. In particular take a look at
> https://github.com/opencog/atomspace/blob/master/opencog/query/InitiateSearchCB.h
Yes. I did not catch the inital part of this, so cannot offer more. But that
is where the inital starting points for a search get picked. I'm
totally swamped
so please don't send me long complicated blobs of code cause I won;t be able
to respond quickly.
>> I believe that either PM should have a guaranteed linear computational
>> time,
The subgraph isomorphism problem is an NP-complete problem, last time
I looked. When its fast, its only because the query is hanging out in the
simple side of the lambda cube.
I think that for "most" queries, the pattern matcher runs in O(SAT) time
that is O(Davis-Putnam) time, because it kind-of-ish performs some of
the similar kind of graph pruning exploration. Sort-of-ish. But only partly.
It could be made more completely Davis-Putnam by someone who has
the brain cells and the time on their hands.
> Nil
>
>>
>> Best regards,
>> Alexey.
Linas.
--
cassette tapes - analog TV - film cameras - you
Linas Vepstas
Mar 13, 2018, 1:04:53 AM3/13/18
to Alexey Potapov, opencog, Nil Geisweiller, Ben Goertzel, vsb...@gmail.com
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 <linasv...@gmail.com> wrote:
> Hi,
>
> To repeat my earlier remarks, and add a few more:
>
> On Mon, Mar 12, 2018 at 3:42 PM, Alexey Potapov <pas....@gmail.com> wrote:
>>
>> Yes. But Pattern Matcher compares all pairs of bounding boxes making it
>> quadratic.
> Yes, there is supposed to be a space-server that is supposed to be optimized
> for these kinds of searches. There is one, but its super-minimal, and not at all
> integrated with the pattern matcher, or anything else for that matter. Smart
> searches on bounding boxes is completely green-field development, for the
> atomspace. We've kind of got very nearly nothing for this.
>>> Yes, but keep in mind that the PM is also Turing complete because you can
>>> call any function within a query (including the PM itself).
>>
>>
>> This is quite problematic. Basic processes should not execute anything
>> dangerous that can take too much time or loop forever and cannot be
>> interrupted. Thus, we should either not treat PM as a basic process, or
>> should restrict its capabilities (and shift responsibility for evaluating
>> arbitrary code to other processes).
> This is misleading or a mis-understanding. Its not the correct way to think
> about it. The current pattern matcher is 2 or three or 4 things matched into
> one:
>
> A) A generic subgraph isomorphism solver. Since this is an NP complete
> problem, it's certainly possible to create pathologically slow queries.
>
> B) A way of combining subgraphs using a crisp-logic boolean algebra
> (actually a Heyting algebra) which we have very vague intentions of
> promoting into something probabilistic. Which, of course, if this was done,
> would layer on an additional combinatoric explosion. It would be fruitful to
> discuss the wisdom or stupidity of this particular task. Or alternative designs
> for it.
>
> C) The ability to perform subgraph isomorphism with so-called "axiom schemata".
> An "axiom schemata" is roughly an infinite collection of relations, for example
> "less than" over the integers or rationals or reals. This means that the pattern
> matcher is kind-of-like-ish a "satisfiability modulo theories" (SMT) solver. The
> API for specifying a theory at this point is rather very simplistic. The "virtual link"
> is that API. It says, basically "implement your model theory here, as C++ code,
> and we will automatically do the satisfiability modulo your theory for you"
>
> Currently supported theories are the equational theory (EqualLink) and numeric
> inequaltiy (GreaterThanLink) An example of a nice-to-have theory would be
> linear algebra - done right, this could solve your space-time bounding box problem
> for starters, and linear programming type problems if anyone cared about that.
> Maybe matroids. Whatever. Dunno. Another nice-to-have would be naive set theory
> which could help lay a cornerstone of probability done right (TM) but this would be
> a long and difficult but veryinteresting discussion.
>
> D) Once a matching subgraph is found, you can launch arbitrary C++/scheme/python
> code to do something with that subgraph. So that's unbounded.
>>> So, the first thing you should do is build a good benchmark tool, then we,
>>> you and the rest of opencog community, can supply it with a collection of
>>> critical tests.
>>
>> How do you see such tool?
> Unclear. I am interested in a tool that tells me if performance got worse after
> a particular code change or bug fix. Some of our fixes accidentally slow things
> down (by a lot) and no one noticies for months or half a year.
>> We have some datasets of varying sizes and
>> queries, and simply run PM on these queries and measure the time. What can
>> be unified/automated?
> Yes!?
>> Running all tests and writing log files with
>> computation times? Anything else?
> I don't care about log files.
>> I agree that we need several (many?) tests to be sure that some changes
>> didn't affect any types of queries, but isn't it just a script? Or do you
>> have something much more complicated in mind?
> Take a look at 3D graphics performance: there are two types of benchmark:
> triangles per second, lines per second, texture maps per second.
> The other type is "for game XYZ, frames per second".
> We need both types of benchmarks. Probably the first more than the second,
> because it helps developers more. The second kind just tells you how screwed
> up the system is today, without telling you why, or where to look.
>> In our case, the query processing time becomes unrealistically large for a
>> one-minute video. If we consider the problem of search in the entire
>> episodic memory, it should be even not linear, but logarithmic. Low degree
>> polynomial complexity is ok for the task dimensions ~1000, not millions or
>> billions...
> No clue what you are searching here. Logarithmic searches mean binary tree,
> quad-tree, octree. The space-time sever is an octree, but its not integrated with
> the pattern matcher, and has a super-naive API.
> We have binary-trees and hash tables for atoms-by-name, by-type, but zero
> sophistication for numeric values. See above comments about "satisfiability
> modulo theories".
> Linas
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 <linasv...@gmail.com> wrote:
> Hi,
>
> To repeat my earlier remarks, and add a few more:
>
> On Mon, Mar 12, 2018 at 3:42 PM, Alexey Potapov <pas....@gmail.com> wrote:
>>
>> Yes. But Pattern Matcher compares all pairs of bounding boxes making it
>> quadratic.
> Yes, there is supposed to be a space-server that is supposed to be optimized
> for these kinds of searches. There is one, but its super-minimal, and not at all
> integrated with the pattern matcher, or anything else for that matter. Smart
> searches on bounding boxes is completely green-field development, for the
> atomspace. We've kind of got very nearly nothing for this.
>>> Yes, but keep in mind that the PM is also Turing complete because you can
>>> call any function within a query (including the PM itself).
>>
>>
>> This is quite problematic. Basic processes should not execute anything
>> dangerous that can take too much time or loop forever and cannot be
>> interrupted. Thus, we should either not treat PM as a basic process, or
>> should restrict its capabilities (and shift responsibility for evaluating
>> arbitrary code to other processes).
> This is misleading or a mis-understanding. Its not the correct way to think
> about it. The current pattern matcher is 2 or three or 4 things matched into
> one:
>
> A) A generic subgraph isomorphism solver. Since this is an NP complete
> problem, it's certainly possible to create pathologically slow queries.
>
> B) A way of combining subgraphs using a crisp-logic boolean algebra
> (actually a Heyting algebra) which we have very vague intentions of
> promoting into something probabilistic. Which, of course, if this was done,
> would layer on an additional combinatoric explosion. It would be fruitful to
> discuss the wisdom or stupidity of this particular task. Or alternative designs
> for it.
>
> C) The ability to perform subgraph isomorphism with so-called "axiom schemata".
> An "axiom schemata" is roughly an infinite collection of relations, for example
> "less than" over the integers or rationals or reals. This means that the pattern
> matcher is kind-of-like-ish a "satisfiability modulo theories" (SMT) solver. The
> API for specifying a theory at this point is rather very simplistic. The "virtual link"
> is that API. It says, basically "implement your model theory here, as C++ code,
> and we will automatically do the satisfiability modulo your theory for you"
>
> Currently supported theories are the equational theory (EqualLink) and numeric
> inequaltiy (GreaterThanLink) An example of a nice-to-have theory would be
> linear algebra - done right, this could solve your space-time bounding box problem
> for starters, and linear programming type problems if anyone cared about that.
> Maybe matroids. Whatever. Dunno. Another nice-to-have would be naive set theory
> which could help lay a cornerstone of probability done right (TM) but this would be
> a long and difficult but veryinteresting discussion.
>
> D) Once a matching subgraph is found, you can launch arbitrary C++/scheme/python
> code to do something with that subgraph. So that's unbounded.
>>> So, the first thing you should do is build a good benchmark tool, then we,
>>> you and the rest of opencog community, can supply it with a collection of
>>> critical tests.
>>
>> How do you see such tool?
> Unclear. I am interested in a tool that tells me if performance got worse after
> a particular code change or bug fix. Some of our fixes accidentally slow things
> down (by a lot) and no one noticies for months or half a year.
>> We have some datasets of varying sizes and
>> queries, and simply run PM on these queries and measure the time. What can
>> be unified/automated?
> Yes!?
>> Running all tests and writing log files with
>> computation times? Anything else?
> I don't care about log files.
>> I agree that we need several (many?) tests to be sure that some changes
>> didn't affect any types of queries, but isn't it just a script? Or do you
>> have something much more complicated in mind?
> Take a look at 3D graphics performance: there are two types of benchmark:
> triangles per second, lines per second, texture maps per second.
> The other type is "for game XYZ, frames per second".
> We need both types of benchmarks. Probably the first more than the second,
> because it helps developers more. The second kind just tells you how screwed
> up the system is today, without telling you why, or where to look.
>> In our case, the query processing time becomes unrealistically large for a
>> one-minute video. If we consider the problem of search in the entire
>> episodic memory, it should be even not linear, but logarithmic. Low degree
>> polynomial complexity is ok for the task dimensions ~1000, not millions or
>> billions...
> No clue what you are searching here. Logarithmic searches mean binary tree,
> quad-tree, octree. The space-time sever is an octree, but its not integrated with
> the pattern matcher, and has a super-naive API.
> We have binary-trees and hash tables for atoms-by-name, by-type, but zero
> sophistication for numeric values. See above comments about "satisfiability
> modulo theories".
> Linas
Linas Vepstas
Mar 13, 2018, 1:05:55 AM3/13/18
to Alexey Potapov, opencog, Nil Geisweiller, Ben Goertzel, vsb...@gmail.com
OK, trying again. Maybe the third time it will work right.
-- Linas
-- Linas
Linas Vepstas
Mar 13, 2018, 1:07:41 AM3/13/18
to Alexey Potapov, opencog, Nil Geisweiller, Ben Goertzel, vsb...@gmail.com
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
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
Linas Vepstas
Mar 13, 2018, 1:23:19 AM3/13/18
to Alexey Potapov, opencog, Nil Geisweiller, Ben Goertzel, vsb...@gmail.com
> OK, then, we will study PM for now.
> Right now, I can only make some contradictory guesses. Maybe, there is a
> simple yet general heuristic, which fixes our case (surely, not all possible
> cases, but maybe they are not too frequent). Maybe, we need another specific
> algo and data structures to retrieve from episodic memory. Maybe, we need a
> sort of specializer, that can project the general PM on a specific query (in
> our case, to consequently enumerate all frames and to compare BBs inside
> them). Maybe we should do everything via callbacks implemented in Atomese...
> Also, I'm starting to think about possible merging of PM with Sampling.
> Indeed, queries are non-deterministic programs with variables as random
> choices conditioned on a set of clauses... But I'm not sure it is
> technically sensible to put it in such way...
>
> -- Alexey
Linas.> Right now, I can only make some contradictory guesses. Maybe, there is a
> simple yet general heuristic, which fixes our case (surely, not all possible
> cases, but maybe they are not too frequent). Maybe, we need another specific
> algo and data structures to retrieve from episodic memory. Maybe, we need a
> sort of specializer, that can project the general PM on a specific query (in
> our case, to consequently enumerate all frames and to compare BBs inside
> them). Maybe we should do everything via callbacks implemented in Atomese...
> Also, I'm starting to think about possible merging of PM with Sampling.
> Indeed, queries are non-deterministic programs with variables as random
> choices conditioned on a set of clauses... But I'm not sure it is
> technically sensible to put it in such way...
>
> -- Alexey
Nil Geisweiller
Mar 13, 2018, 3:20:53 AM3/13/18
to linasv...@gmail.com, Alexey Potapov, opencog, Nil Geisweiller, Ben Goertzel, vsb...@gmail.com
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
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
Nil Geisweiller
Mar 13, 2018, 3:24:13 AM3/13/18
to linasv...@gmail.com, Alexey Potapov, opencog, Nil Geisweiller, Ben Goertzel, vsb...@gmail.com
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.
> used to manage my emails in Emacs via Wonderlust, but it's much slower
Nil Geisweiller
Mar 13, 2018, 3:30:18 AM3/13/18
to linasv...@gmail.com, Alexey Potapov, opencog, Nil Geisweiller, Ben Goertzel, vsb...@gmail.com
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:
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:
Ben Goertzel
Mar 13, 2018, 3:53:02 AM3/13/18
to Nil Geisweiller, Linas Vepstas, Alexey Potapov, opencog, vsb...@gmail.com
Yes, if the problem at hand is
***
***
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
--
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
***
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
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
Nil Geisweiller
Mar 13, 2018, 4:13:17 AM3/13/18
to linasv...@gmail.com, Alexey Potapov, opencog, Nil Geisweiller, Ben Goertzel, vsb...@gmail.com
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
> >> 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?
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
Ben Goertzel
Mar 13, 2018, 4:41:27 AM3/13/18
to Alexey Potapov, Nil Geisweiller, Linas Vepstas, opencog, vsb...@gmail.com
Conceptually --
A fixed algo for solving NP-complete problems of a particular type, of
bounded size <K, **may** be part of a framework for general
intelligence...
On Tue, Mar 13, 2018 at 4:14 PM, Alexey Potapov <pas....@gmail.com> 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...
A fixed algo for solving NP-complete problems of a particular type, of
bounded size <K, **may** be part of a framework for general
intelligence...
On Tue, Mar 13, 2018 at 4:14 PM, Alexey Potapov <pas....@gmail.com> 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...
Ben Goertzel
Mar 13, 2018, 4:42:35 AM3/13/18
to Alexey Potapov, Nil Geisweiller, Linas Vepstas, opencog, vsb...@gmail.com
That said, I like the idea of having automated learning used to learn
predicates that serve in the PM callbacks....
predicates that serve in the PM callbacks....
Linas Vepstas
Mar 14, 2018, 12:28:35 AM3/14/18
to Nil Geisweiller, Alexey Potapov, opencog, Ben Goertzel, vsb...@gmail.com
On Tue, Mar 13, 2018 at 2:30 AM, Nil Geisweiller <ngei...@googlemail.com> wrote:
So if I understand well, the appropriate fix would be to use AtTimeLink and AtLocationLink and have the pattern matcher specially handles this via perhaps relaying the spatio-temporal component of the query to the space server.
Space is complicated. "Dallas is near Fort Worth" means 50 kilometers. "the chair is near the table" means one meter.
I know almost nothing about the current state of space server so take my comment with a grain of salt...
It "works" for appropriate level of "works". Its just super-duper naive and simplistic.
Alternatively, there might be more abstract heuristics that can hacked into the pattern matcher only, maybe that would be simpler and more general. No idea...
GroundedPredicateNodes are "sufficient". The hard part is to figure out what kind of abstract heuristics are useful. I know two ways of discovering that: 1) reading textbooks and papers, 2) experimenting by building things.
--linas
Linas Vepstas
Mar 14, 2018, 12:33:42 AM3/14/18
to Ben Goertzel, Nil Geisweiller, Alexey Potapov, opencog, vsb...@gmail.com
On Tue, Mar 13, 2018 at 2:52 AM, Ben Goertzel <b...@goertzel.org> 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,
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
Linas Vepstas
Mar 14, 2018, 12:55:14 AM3/14/18
to Alexey Potapov, Ben Goertzel, Nil Geisweiller, opencog, vsb...@gmail.com
On Tue, Mar 13, 2018 at 3:14 AM, Alexey Potapov <pas....@gmail.com> 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 <b...@goertzel.org>:
Ben Goertzel
Mar 14, 2018, 9:29:18 PM3/14/18
to Alexey Potapov, opencog, Nil Geisweiller, vsb...@gmail.com
Let me preface this by noting that I am really psyched we are having this
sort of discussion ;) ...
> - Let's imagine I know 10000 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
sort of discussion ;) ...
> - Let's imagine I know 10000 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
Linas Vepstas
Mar 15, 2018, 12:08:31 AM3/15/18
to opencog, Alexey Potapov, Nil Geisweiller, vsb...@gmail.com
On Wed, Mar 14, 2018 at 8:29 PM, Ben Goertzel <b...@goertzel.org> 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 10000 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 10000 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 10000 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.
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.
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, this is combinatorial, but fast boolean solver exist and can crank through the alternatives quite quickly. Taking the average of these would provide a reasonable approximation to have PLN+attention-allocation is trying to do. Its a different algo, though. Its a simpler special-case of probabililisic programming, something I thought Alexy was good at. ...
Creating a fast crisp solver that takes averages over the same kinds of inputs that the URE backward chainer takes ... its a non-trivial engineering task, requires a lot of code .. but, again . its an engineering task. It seems fairly straight-foreward. There are various interesting science questions in there, but it seems doable. But, again, this is also not where the hard problem of AGI lies.
--linas
Alexey Potapov
Mar 15, 2018, 1:37:39 AM3/15/18
to Ben Goertzel, opencog, Nil Geisweiller, vsb...@gmail.com
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?
Alexey Potapov
Mar 15, 2018, 1:54:52 AM3/15/18
to Linas Vepstas, opencog, Nil Geisweiller, vsb...@gmail.com
> 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?..
Linas Vepstas
Mar 15, 2018, 1:56:51 AM3/15/18
to opencog, Ben Goertzel, Nil Geisweiller, vsb...@gmail.com
On Thu, Mar 15, 2018 at 12:37 AM, Alexey Potapov <pot...@aideus.com> wrote:
So this is an arithmetic query, rather than a spatial query -- but the two cases
are similar in that both arithmetic operations and spatial operations are
"special domains" with their own algebras, and by using those algebras one
can answer queries in those domains more efficiently than one can do by generic
means...Are you going to manually implement a special algorithm for each domain?
How many domains are there? one? two? three? "satisfiability modulo theories"
That's what those words mean.
So to efficiently handles queries like those you're mentioning, I would want to
use the PLN backward chainer rather than just the PM, and have the backward
chainer perhaps connected to some computer-algebra engine as one option to use
when encountering a GreaterThanLink ...What rules for BC to do have in mind for this case? Let's try them and see if the solution will be O(N).Again, you just say: don't use PM with GreaterThanLinks. Then, for what reason their support is presented in PM?
I'm totally confused. "Greater than" is just a theory. Its like any other theory.
What exactly, is the problem here? Many theories have O(N) algorithms.
Many other theories do not. You seem to be talking about a linear programming
problem? which is solvable in P? I lost track of the argument.
Or one could tweak the PM to use the backward chainer only when encountering
a GreaterThanLink, and just do plain vanilla pattern matching otherwise...PM doesn't need to know algebra to deal with this query efficiently. It just needs not to evaluate pairwise relations for every pair object, but only for objects belonging to same groups.
So, stick them in the same group. If you design a crappy representation for the knowledge you are representing, then the query will run slowly. This is a lot like SQL -- many of the same concepts, ideas apply -- the pattern matcher solves satisfiability problems over a domain that is a bit richer than plain-old relational algebra - its a graph isomoprhism problem. But its not really all that different than any other satisfiability problem or the kinds of queries one writes.
Yeah, I know. I just tried to imagine OpenCog in place of human mind.
We are very very very very far away from human-mind type intelligence. Don't imagine it that way. You'll just get bad intuitions.
> Maybe. So, what rules will work in this case?
I think you need to describe the case again. It seemed to require the sorting of time intervals into a linear sequence, right? Pretty much all SQL databases support this natively. You write a query that says "QUERY foo SORT BY colname". Or "QUERY foo SORT BY 42*col_a - 2.35*col_b**3 + col_c>5?22:66" The current pattern matcher does not have any sort-by statement, although it could. As stated earlier, no one has ever tried to push numeric data through the pattern matcher before; except in some very super-naive and basic ways. If you really need search and sorting by numeric value, that's a solvable problem. Its a theory. Again "satisfiability modulo theories". We have an API for implementing theories. Its stupid and low-level, but it works.
--linas
Nil Geisweiller
Mar 15, 2018, 2:12:23 AM3/15/18
to linasv...@gmail.com, opencog, Ben Goertzel, Nil Geisweiller, vsb...@gmail.com
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
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
Alexey Potapov
Mar 15, 2018, 2:13:34 AM3/15/18
to opencog, Ben Goertzel, Nil Geisweiller, vsb...@gmail.com
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...
Linas Vepstas
Mar 15, 2018, 2:14:44 AM3/15/18
to Alexey Potapov, opencog, Nil Geisweiller, vsb...@gmail.com
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.
Nil Geisweiller
Mar 15, 2018, 2:18:33 AM3/15/18
to Alexey Potapov, Linas Vepstas, opencog, Nil Geisweiller, vsb...@gmail.com
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
Linas Vepstas
Mar 15, 2018, 2:20:17 AM3/15/18
to Nil Geisweiller, opencog, Ben Goertzel, vsb...@gmail.com
On Thu, Mar 15, 2018 at 1:12 AM, Nil Geisweiller <ngei...@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.
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....
Alexey Potapov
Mar 15, 2018, 2:26:57 AM3/15/18
to Linas Vepstas, opencog, Nil Geisweiller, vsb...@gmail.com
OK, we will not consider this problem.
Linas Vepstas
Mar 15, 2018, 2:28:06 AM3/15/18
to Nil Geisweiller, Alexey Potapov, opencog, vsb...@gmail.com
On Thu, Mar 15, 2018 at 1:18 AM, Nil Geisweiller <ngei...@googlemail.com> 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
Nil Geisweiller
Mar 15, 2018, 2:49:29 AM3/15/18
to linasv...@gmail.com, Nil Geisweiller, opencog, Ben Goertzel, vsb...@gmail.com
On 03/15/2018 08:19 AM, Linas Vepstas wrote:
>
>
> On Thu, Mar 15, 2018 at 1:12 AM, Nil Geisweiller
> <ngei...@googlemail.com <mailto:ngei...@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
>
>
> On Thu, Mar 15, 2018 at 1:12 AM, Nil Geisweiller
> <ngei...@googlemail.com <mailto:ngei...@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.
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.
>
> ?
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.
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....
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
> <pot...@aideus.com <mailto:pot...@aideus.com>
Alexey Potapov
Mar 15, 2018, 5:30:31 AM3/15/18
to Linas Vepstas, opencog, Nil Geisweiller, vsb...@gmail.com
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...
Alexey Potapov
Mar 15, 2018, 6:21:02 AM3/15/18
to Linas Vepstas, opencog, Nil Geisweiller, vsb...@gmail.com
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 10000 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?
Alexey Potapov
Mar 15, 2018, 9:19:49 AM3/15/18
to Linas Vepstas, opencog, Nil Geisweiller, vsb...@gmail.com
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.
Ben Goertzel
Mar 15, 2018, 9:08:08 PM3/15/18
to opencog, Linas Vepstas, Nil Geisweiller, vsb...@gmail.com
BTW I did not forget this thread but got busy, I will respond on the weekend ;)
> --
> 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+u...@googlegroups.com.
> To post to this group, send email to ope...@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.
> 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+u...@googlegroups.com.
> To post to this group, send email to ope...@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.
Linas Vepstas
Mar 17, 2018, 1:13:12 AM3/17/18
to opencog, Ben Goertzel, Nil Geisweiller, vsb...@gmail.com
On Thu, Mar 15, 2018 at 2:13 PM, Alexey Potapov <pot...@aideus.com> 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.
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.
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
Linas Vepstas
Mar 17, 2018, 1:41:46 AM3/17/18
to Nil Geisweiller, opencog, Ben Goertzel, vsb...@gmail.com
On Thu, Mar 15, 2018 at 2:49 PM, Nil Geisweiller <ngei...@googlemail.com> wrote:
On 03/15/2018 08:19 AM, Linas Vepstas wrote:
On Thu, Mar 15, 2018 at 1:12 AM, Nil Geisweiller <ngei...@googlemail.com <mailto:ngei...@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).
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
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.
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
Linas Vepstas
Mar 17, 2018, 2:05:27 AM3/17/18
to Alexey Potapov, opencog, Nil Geisweiller, vsb...@gmail.com
On Thu, Mar 15, 2018 at 6:20 PM, Alexey Potapov <pot...@aideus.com> 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 10000 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 10000 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.
Alexey Potapov
Mar 17, 2018, 3:47:42 AM3/17/18
to Linas Vepstas, opencog, Nil Geisweiller, vsb...@gmail.com
No human can remember 10000 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", "10000 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 10000. 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 10000 words?..
Linas Vepstas
Mar 17, 2018, 10:30:32 AM3/17/18
to Alexey Potapov, opencog, Nil Geisweiller, vsb...@gmail.com
??
I'm pretty sure I know a lot more than 10000 words. That is not at all comparable to knowing 10000 things. Knowing 20000 words is comparable to knowing maybe 500 things. How, exactly, are you measuring knowledge?On Sat, Mar 17, 2018 at 3:47 PM, Alexey Potapov <pot...@aideus.com> wrote:
No human can remember 10000 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", "10000 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 10000. 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 10000 words?..
Ben Goertzel
Mar 17, 2018, 10:56:16 AM3/17/18
to opencog, Alexey Potapov, Nil Geisweiller, vsb...@gmail.com
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 !!!
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 !!!
> --
> 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+u...@googlegroups.com.
> To post to this group, send email to ope...@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.
> 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+u...@googlegroups.com.
> To post to this group, send email to ope...@googlegroups.com.
> Visit this group at https://groups.google.com/group/opencog.
> To view this discussion on the web visit
Alexey Potapov
Mar 17, 2018, 11:00:07 AM3/17/18
to Linas Vepstas, opencog, Nil Geisweiller, vsb...@gmail.com
This discussion seems senseless. You literally said: "No human can remember 10000 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 10000 things known by humans (e.g. photostockers can recognize their works from 20000+ portfolios) ... And the specific number doesn't really matter. I'll stop here independent of your answer...
Linas Vepstas
Mar 17, 2018, 11:03:18 AM3/17/18
to Alexey Potapov, opencog, Nil Geisweiller, vsb...@gmail.com
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? Ben Goertzel
Mar 17, 2018, 11:06:01 AM3/17/18
to opencog, Alexey Potapov, Nil Geisweiller, vsb...@gmail.com
***
This was one of the key misconceptions underlying Cyc ...
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...)
***
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 ...
> --
> 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+u...@googlegroups.com.
> To post to this group, send email to ope...@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.
> 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+u...@googlegroups.com.
> To post to this group, send email to ope...@googlegroups.com.
> Visit this group at https://groups.google.com/group/opencog.
> To view this discussion on the web visit
Linas Vepstas
Mar 17, 2018, 11:35:21 AM3/17/18
to opencog
On Sat, Mar 17, 2018 at 10:56 PM, Ben Goertzel <b...@goertzel.org> 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
> email to opencog+unsubscribe@googlegroups.com.
> To post to this group, send email to ope...@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+unsubscribe@googlegroups.com.
To post to this group, send email to ope...@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.
--
Linas Vepstas
Mar 17, 2018, 11:40:25 AM3/17/18
to Alexey Potapov, opencog, Nil Geisweiller, vsb...@gmail.com
On Sat, Mar 17, 2018 at 11:00 PM, Alexey Potapov <pot...@aideus.com> wrote:
This discussion seems senseless. You literally said: "No human can remember 10000 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 10000 things known by humans (e.g. photostockers can recognize their works from 20000+ 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 <linasv...@gmail.com>:--linas??I'm pretty sure I know a lot more than 10000 words. That is not at all comparable to knowing 10000 things. Knowing 20000 words is comparable to knowing maybe 500 things. How, exactly, are you measuring knowledge?On Sat, Mar 17, 2018 at 3:47 PM, Alexey Potapov <pot...@aideus.com> wrote:No human can remember 10000 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", "10000 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 10000. 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 10000 words?..
--cassette tapes - analog TV - film cameras - you
Cassio Pennachin
Mar 17, 2018, 11:42:09 AM3/17/18
to opencog, Alexey Potapov, Nil Geisweiller, vsb...@gmail.com
I believe this thread has run way past its useful course, and suggest we kill it.
--
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+unsubscribe@googlegroups.com.
To post to this group, send email to ope...@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.
Cassio Pennachin
Ben Goertzel
Mar 17, 2018, 11:43:59 AM3/17/18
to opencog, Alexey Potapov, Nil Geisweiller, vsb...@gmail.com
"To see a World in a Grain of Sand
And a Heaven in a Wild Flower,
Hold Infinity in the palm of your hand
And Eternity in an hour.
A Robin Redbreast in a Cage
Puts all Heaven in a Rage.
A dove house fill’d with doves and pigeons
Shudders Hell thro’ all its regions.
A Dog starv’d at his Master’s Gate
Predicts the ruin of the State.
A Horse misus’d upon the Road
Calls to Heaven for Human blood.
Each outcry of the hunted Hare
A fiber from the Brain does tear."
>> email to opencog+u...@googlegroups.com.
And a Heaven in a Wild Flower,
Hold Infinity in the palm of your hand
And Eternity in an hour.
A Robin Redbreast in a Cage
Puts all Heaven in a Rage.
A dove house fill’d with doves and pigeons
Shudders Hell thro’ all its regions.
A Dog starv’d at his Master’s Gate
Predicts the ruin of the State.
A Horse misus’d upon the Road
Calls to Heaven for Human blood.
Each outcry of the hunted Hare
A fiber from the Brain does tear."
>> To post to this group, send email to ope...@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.
>
>
>
>
> --
> Cassio Pennachin
>
>> 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.
>
>
>
>
> --
> Cassio Pennachin
>
> --
> 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+u...@googlegroups.com.
> 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
> To post to this group, send email to ope...@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/CADwLDSQrwJwkx4KEVumra4piovOK-tJXS1FLAZax1_CwekAS_g%40mail.gmail.com.
> Visit this group at https://groups.google.com/group/opencog.
> To view this discussion on the web visit
Nil Geisweiller
Mar 18, 2018, 3:59:10 AM3/18/18
to linasv...@gmail.com, Nil Geisweiller, opencog, Ben Goertzel, vsb...@gmail.com
On 03/17/2018 07:41 AM, Linas Vepstas wrote:> My suspicion is that
I don't know if we want the term OpenPsi to refer to this human
psychology model, or something more abstract.
The only thing I know is that the most abstract decision component
should not be called OpenPsi, it's way too abstract compared to what is
described by Joshua Bach and Dietrich Dörner to define MicroPsi.
Perhaps simply
OpenCog Decision
or
OCD ;-)
> 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
Even this sounds already too specialized (but I don't know enough the
current OpenPsi code to tell).
> 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.
I think the abstract part of OpenPsi, provisionally called OCD, should
be clearly taken away and put in another directory. If it's abstract
enough it could even live in the AtomSpace repo. That would be
convenient as the URE needs such a decision code. Currently I'm using my
own code
https://github.com/opencog/atomspace/blob/master/opencog/rule-engine/backwardchainer/MixtureModel.h
https://github.com/opencog/atomspace/blob/master/opencog/rule-engine/backwardchainer/ActionSelection.h
but ideally it should be merged into a generic decision component.
Nil
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.
I totally agree.
> 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.
I don't know if we want the term OpenPsi to refer to this human
psychology model, or something more abstract.
The only thing I know is that the most abstract decision component
should not be called OpenPsi, it's way too abstract compared to what is
described by Joshua Bach and Dietrich Dörner to define MicroPsi.
Perhaps simply
OpenCog Decision
or
OCD ;-)
> 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
current OpenPsi code to tell).
> 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.
be clearly taken away and put in another directory. If it's abstract
enough it could even live in the AtomSpace repo. That would be
convenient as the URE needs such a decision code. Currently I'm using my
own code
https://github.com/opencog/atomspace/blob/master/opencog/rule-engine/backwardchainer/MixtureModel.h
https://github.com/opencog/atomspace/blob/master/opencog/rule-engine/backwardchainer/ActionSelection.h
but ideally it should be merged into a generic decision component.
Nil
Nil Geisweiller
Mar 18, 2018, 4:30:20 AM3/18/18
to ope...@googlegroups.com
Hehe :-D
Maybe Linas means incompressible things.
Nil
> > email to opencog+u...@googlegroups.com
> <mailto:opencog%2Bunsu...@googlegroups.com>.
> > To post to this group, send email to ope...@googlegroups.com <mailto:ope...@googlegroups.com>.
> >
> > For more options, visit https://groups.google.com/d/optout <https://groups.google.com/d/optout>.
> <mailto:opencog%2Bunsu...@googlegroups.com>.
> <https://groups.google.com/d/msgid/opencog/CACYTDBfVYuNtVynNwbsDJFHFLQ7t5sR45Lc00ab-MxPb1_Rx0A%40mail.gmail.com>.
> <mailto:opencog+u...@googlegroups.com>.
> <https://groups.google.com/d/msgid/opencog/CAHrUA34iYs9Fdx1X8eGmDj_tG8QXdQKXTzaQZLYi9Eni1OGCqA%40mail.gmail.com?utm_medium=email&utm_source=footer>.
Maybe Linas means incompressible things.
Nil
> <mailto:opencog%2Bunsu...@googlegroups.com>.
> > To post to this group, send email to ope...@googlegroups.com <mailto:ope...@googlegroups.com>.
> > Visit this group at https://groups.google.com/group/opencog
> <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
> <https://groups.google.com/d/msgid/opencog/CAHrUA370iHqyqjsGLJQBU9BSMq%3Dgk4tLRGmEhT2u65NAt7nP%3Dg%40mail.gmail.com>.
> >
> https://groups.google.com/d/msgid/opencog/CAHrUA370iHqyqjsGLJQBU9BSMq%3Dgk4tLRGmEhT2u65NAt7nP%3Dg%40mail.gmail.com
> >
> > For more options, visit https://groups.google.com/d/optout <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+u...@googlegroups.com
>
>
> --
> 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,
> <mailto:opencog%2Bunsu...@googlegroups.com>.
> To post to this group, send email to ope...@googlegroups.com
> <mailto:ope...@googlegroups.com>.
> Visit this group at https://groups.google.com/group/opencog
> <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
> <https://groups.google.com/d/msgid/opencog/CACYTDBfVYuNtVynNwbsDJFHFLQ7t5sR45Lc00ab-MxPb1_Rx0A%40mail.gmail.com>.
> For more options, visit https://groups.google.com/d/optout
> <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+u...@googlegroups.com
>
>
>
> --
> 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
> <mailto:opencog+u...@googlegroups.com>.
> To post to this group, send email to ope...@googlegroups.com
> <mailto:ope...@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
> To view this discussion on the web visit
> <https://groups.google.com/d/msgid/opencog/CAHrUA34iYs9Fdx1X8eGmDj_tG8QXdQKXTzaQZLYi9Eni1OGCqA%40mail.gmail.com?utm_medium=email&utm_source=footer>.
Nil Geisweiller
Mar 18, 2018, 4:37:27 AM3/18/18
to linasv...@gmail.com, Alexey Potapov, opencog, Nil Geisweiller, vsb...@gmail.com
On 03/17/2018 05:02 PM, Linas Vepstas wrote:
> 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...)
That guy might not be able to write many books but he sure knows how to
> 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...)
make sushis. How many "things" does he know to be so good at it? How
many incompressible bits?
https://www.youtube.com/watch?v=R2L5IrkQTV0
Nil
Linas Vepstas
Mar 18, 2018, 7:25:26 PM3/18/18
to Nil Geisweiller, opencog, Ben Goertzel, vsb...@gmail.com
I think the abstract part of OpenPsi, provisionally called OCD, should be clearly taken away and put in another directory. If it's abstract enough it could even live in the AtomSpace repo. That would be convenient as the URE needs such a decision code.
Yes. Last I tried to work with it, it had some very awkward corners (the "demands" part was badly integrated), yet other parts were clean and well-designed/coded. It was certainly abstract enough to be a part of the atomspace. However, untangling the tangled bits from the clean bits might be quite hard/time-consuming.
--linas
Linas Vepstas
Mar 18, 2018, 7:50:53 PM3/18/18
to opencog
On Sun, Mar 18, 2018 at 4:30 PM, 'Nil Geisweiller' via opencog <ope...@googlegroups.com> wrote:
Hehe :-D
Maybe Linas means incompressible things.
Some examples:
- Link grammar knows 10K words. Link grammar is not intelligent
- My dog knows 10 words. Humans are not 10K / 10 = 1000 times smarter than a dog.
- The book: "Everything I need to know I learned in 2nd grade" list things like "don't take other peoples toys" and "don't push". The book lists maybe 12 things, that you should have learned in second grade, but apparently many adults did not.
-- There are 10 commandments, not 10000 commandments.
-- Any book on "Executive Management Tips from Great CEO's" or "Defensive Strategies for Basketball", or "How to Sew a Quilt" or "Music and the Brain: What Scientists Know about Music" will list 10 to 20 items, not 10000 of them.
-- School exams contain 5-20 questions, not 10000 questions.
That's the typical human-scale number of conceptual ideas that humans work with: dozens. Over a lifetime, you can absorb many, many of these knowledge-bundles, but you cannot absorb one thousand of them.
--linas
<mailto:opencog%2Bunsubscribe@googlegroups.com>.> email to opencog+unsubscribe@googlegroups.com
> To post to this group, send email to ope...@googlegroups.com <mailto:opencog@googlegroups.com>.
> Visit this group at https://groups.google.com/group/opencog
<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
<https://groups.google.com/d/msgid/opencog/CAHrUA370iHqyqjsGLJQBU9BSMq%3Dgk4tLRGmEhT2u65NAt7nP%3Dg%40mail.gmail.com>.
>
> For more options, visit https://groups.google.com/d/optout <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+unsubscribe@googlegroups.com
<mailto:opencog%2Bunsubscribe@googlegroups.com>.
To post to this group, send email to ope...@googlegroups.com
<mailto:opencog@googlegroups.com>.
Visit this group at https://groups.google.com/group/opencog
<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
<https://groups.google.com/d/msgid/opencog/CACYTDBfVYuNtVynNwbsDJFHFLQ7t5sR45Lc00ab-MxPb1_Rx0A%40mail.gmail.com>.
For more options, visit https://groups.google.com/d/optout
<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+unsubscribe@googlegroups.com <mailto:opencog+unsubscribe@googlegroups.com>.
To post to this group, send email to ope...@googlegroups.com <mailto: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 <https://groups.google.com/d/msgid/opencog/CAHrUA34iYs9Fdx1X8eGmDj_tG8QXdQKXTzaQZLYi9Eni1OGCqA%40mail.gmail.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout.
--
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+unsubscribe@googlegroups.com.
To post to this group, send email to ope...@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/69c415fc-eba6-a1f2-77bc-d63c78d6d910%40gmail.com.
Ben Goertzel
Mar 18, 2018, 9:38:32 PM3/18/18
to opencog
Many of these examples have to do with the 7+/-2 limitation of human
(and many other animals') short-term/working memory capacity, which is
a significant factor in human cognition but doesn't constrain human
long-term memory capacity...
ben
>>> > email to opencog+u...@googlegroups.com
>>> <mailto:opencog%2Bunsu...@googlegroups.com>.
>>> <mailto:opencog%2Bunsu...@googlegroups.com>.
>>> <mailto:opencog+u...@googlegroups.com>.
(and many other animals') short-term/working memory capacity, which is
a significant factor in human cognition but doesn't constrain human
long-term memory capacity...
ben
>>> <mailto:opencog%2Bunsu...@googlegroups.com>.
>>> > To post to this group, send email to ope...@googlegroups.com
>>> <mailto:ope...@googlegroups.com>.
>>> > Visit this group at https://groups.google.com/group/opencog
>>> <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
>>>
>>> <https://groups.google.com/d/msgid/opencog/CAHrUA370iHqyqjsGLJQBU9BSMq%3Dgk4tLRGmEhT2u65NAt7nP%3Dg%40mail.gmail.com>.
>>> >
>>> > For more options, visit https://groups.google.com/d/optout
>>> <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+u...@googlegroups.com
>>> <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
>>>
>>> <https://groups.google.com/d/msgid/opencog/CAHrUA370iHqyqjsGLJQBU9BSMq%3Dgk4tLRGmEhT2u65NAt7nP%3Dg%40mail.gmail.com>.
>>> >
>>> > For more options, visit https://groups.google.com/d/optout
>>> <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,
>>> <mailto:opencog%2Bunsu...@googlegroups.com>.
>>> To post to this group, send email to ope...@googlegroups.com
>>> <mailto:ope...@googlegroups.com>.
>>> Visit this group at https://groups.google.com/group/opencog
>>> <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
>>>
>>> <https://groups.google.com/d/msgid/opencog/CACYTDBfVYuNtVynNwbsDJFHFLQ7t5sR45Lc00ab-MxPb1_Rx0A%40mail.gmail.com>.
>>> For more options, visit https://groups.google.com/d/optout
>>> <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+u...@googlegroups.com
>>> <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
>>>
>>> <https://groups.google.com/d/msgid/opencog/CACYTDBfVYuNtVynNwbsDJFHFLQ7t5sR45Lc00ab-MxPb1_Rx0A%40mail.gmail.com>.
>>> For more options, visit https://groups.google.com/d/optout
>>> <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
>>> <mailto:opencog+u...@googlegroups.com>.
>>> To post to this group, send email to ope...@googlegroups.com
>>> <mailto:ope...@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
>>> <https://groups.google.com/d/msgid/opencog/CAHrUA34iYs9Fdx1X8eGmDj_tG8QXdQKXTzaQZLYi9Eni1OGCqA%40mail.gmail.com?utm_medium=email&utm_source=footer>.
>>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>> --
>> 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+u...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/opencog/CAHrUA34iYs9Fdx1X8eGmDj_tG8QXdQKXTzaQZLYi9Eni1OGCqA%40mail.gmail.com
>>> <https://groups.google.com/d/msgid/opencog/CAHrUA34iYs9Fdx1X8eGmDj_tG8QXdQKXTzaQZLYi9Eni1OGCqA%40mail.gmail.com?utm_medium=email&utm_source=footer>.
>>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>> --
>> 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
>> To post to this group, send email to ope...@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/69c415fc-eba6-a1f2-77bc-d63c78d6d910%40gmail.com.
>>
>> For more options, visit https://groups.google.com/d/optout.
>
>
>
>
> --
> cassette tapes - analog TV - film cameras - you
>
>> 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/69c415fc-eba6-a1f2-77bc-d63c78d6d910%40gmail.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+u...@googlegroups.com.
> 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
> To post to this group, send email to ope...@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/CAHrUA342HRnbZuWjs%2BJ3VeR%3DUvuPN7jF%2B6veNEJn_BUBopyw%2Bg%40mail.gmail.com.
> Visit this group at https://groups.google.com/group/opencog.
> To view this discussion on the web visit
Reply all
Reply to author
Forward
0 new messages