Nil, I just dug up and looked through our dialogue on this topic from a year ago... see below...
ben ---------- Forwarded message ---------- From: 'Nil Geisweiller' via opencog <opencog@googlegroups.com> Date: Mon, Sep 7, 2015 at 6:42 PM Subject: Re: [opencog-dev] Variables, names, etc. To: opencog@googlegroups.com A solution would be to have VariableNode uniqueness determined by name + scope, and to have that variable nodes indexed not just by names, but by names and scope. This would allow variable nodes with same names but different scopes to be seen as different atoms. Of course since the scope creation comes after variable node creation, this process of attaching the scope to the node variable can only be after variable node creation, but I don't think that would be a problem, a variable would be seen global till it gets a scope. But I have not a good idea of how much work on the AtomSpace core code that would take... It seems it would require to change the atomspace API to have get_variable_node(<variable name>, [scope]), as opposed to using get_node(VARIABLE_NODE, <variable name>), etc. Nil On 09/06/2015 12:49 AM, Linas Vepstas wrote: > > Well, no, cause if you did this, you would be changing the name for > everyone who is holding it, in every scope. You only want to change the > name in the local scope. > > --linas > > On Thu, Sep 3, 2015 at 8:11 PM, Ben Goertzel <b...@goertzel.org > <mailto:b...@goertzel.org>> wrote: > > That could immediately be made to happen with UUIDs, right? Changing > the name could be done without changing the UUID, if one wanted... > > On Fri, Sep 4, 2015 at 6:44 AM, Linas Vepstas > <linasveps...@gmail.com <mailto:linasveps...@gmail.com>> wrote: > > No comment about Nil's emails (viz I agree). > > > > As I re-read what I just wrote, I realize that the very first > thing I talk > > about and the very last thing are related. It would be > super-cool if there > > was an "alpha-handle" that always pointed at the same > "variable", no matter > > what alpha-renaming was done on it. > > > > Not sure how to make that work. Perhaps this "alpha-handle" is > the same > > thing as the "handle" of the opencog books??? > > > > --linas > > > > On Thu, Sep 3, 2015 at 5:35 PM, Linas Vepstas > <linasveps...@gmail.com <mailto:linasveps...@gmail.com>> > > > wrote: > >> > >> Phew, long email. > >> > >> Replying point by point: > >> > >> Adopting the convention #1 is fine by me. I did not mean to > discourage it > >> in any way. I was gravitating towards #2 only because it seemed > that > >> everyone wanted an automatic solution. > >> > >> I'd like to point out one ugly bit that comes with #2: it breaks > naive > >> expectations in the scheme/python/c++ language bindings. So, > for example: > >> > >> (define vx (VariableNode "$x")) > >> (define fa (ForAllLink (VariableNode "$x") ...) > >> > >> The propsal #2 would automatically replace (VariableNode "$x") by > >> (VariableNode "$x-666") which is fine, but when the naive > programmer tries > >> to use vx they won't get what they thought they should. This > is an issue > >> not just for scheme, but for python and C++ and haskell as > well. Its one > >> reason I did NOT like #2. > >> > >> ---- > >> However, for the garbage-collecting-in-the-chainer point: as > best as I > >> can tell, following #1 as a convention does not in any way fix > this. As > >> currently designed, the chainer creates "temporary" BindLinks, > performs a > >> query, and then (I assume) deletes the BindLinks. As best as I > understand, > >> adopting #1 will not avoid the need for these temporaries. Can > you or > >> William clarify this? > >> > >> If the temporaries cannot be avoided, then I'm not sure why > there's an > >> issue: yes, performance could be improved by avoiding copies > with renamed > >> variables in them, but its not obviously a bottleneck. > >> > >> ----- > >> For #3, Its straight-forward to run queries against the backing > store. It > >> was designed for this :-) During the matching process, there is > a step > >> where one explores "upward", i.e. by looking at each link in the > incoming > >> set of some given atom. There is a callback in the pattern > matcher called > >> "get me the incoming set of this atom" -- the default gets them > all; the PLN > >> variant uses this to sort the incoming set by AV (and skip over > low-AV > >> atoms). Well, backing store happens to have a function named > "get me the > >> incoming set of this atom" -- put the two together, and presto, > you are > >> searching everything in the backing store. > >> > >> We can argue about efficiency, etc. but as a base function, its > easy. Its > >> not turned on by default. > >> > >> ---- > >> For #4, "canonical labelling" would indeed be a pretty slick > solution. I > >> guess you could say that #1 is a manual convention > implementation of #4. > >> > >> I like #4 except that it has some of the same drawbacks as #2 > w.r.t. the > >> language bindings. > >> ---- > >> > >> Regarding variables without names, and handles. In the current > atomspace > >> implementation, handles are done completely incorrectly. Its > just .. messed > >> up in this horrible way. From what I can tell, this is due to a > lot of > >> confusion about what a "handle" is supposed to do, and what its > good for. > >> It sort-of-ish resembles what some of your books describe and/or > what some > >> of the opencog-prime wikibook pages describe. But not exactly, > it goes > >> sideways from there. So, ideas like "variables without names" > or, more > >> generally "atoms without names" cannot be implemented until the > Handle mess > >> is diagnosed and fixed. > >> > >> If you care to think about this, here are the constraints: > >> > >> a) needs to be some fast way of getting access to the atoms in a > Link. In > >> the code, this can be done with an AtomPtr. It is an ordinary c/c++ > >> pointer, i.e. fast, but reference counted, so deals with garbage > >> collection. > >> > >> b) needs to be some way of talking about atoms in some remote > location. > >> This is called the UUID and is a 64-bit int in the current > code. There is a > >> primitive allocation scheme that allows multiple > atomspaces/backing stores > >> to coordinate the allocation of UUID's, so that conflicts are > minimized (but > >> not eliminated; I can explain this -- we have no "eventually > consistent" > >> mechanism yet.) > >> > >> c) needs to be some way of .. uhh, err, I don't know, some way > of talking > >> about atoms that the PLN books and opencog books/wiki pages call > a "handle", > >> whatever that is. I'm not sure what its properties are > supposed to be. > >> Naively, this "handle" thingy sounds almost trivial. But I > never seem to > >> understand trivial things, so there we go. > >> > >> > >> -- Linas > >> > >> > >> > >> On Wed, Sep 2, 2015 at 9:19 PM, Ben Goertzel <b...@goertzel.org > <mailto:b...@goertzel.org>> wrote: > >>> > >>> Hi Linas, > >>> > >>> I'm very aware you're busy trying to get "behavior trees in > OpenCog" > >>> to work for Hanson.... However, I feel this is a subtle enough > issue > >>> that it requires more than a "knee-jerk reaction" to come to grips > >>> with it usefully... > >>> > >>> I also note that *none* of the solutions suggested for the near > term > >>> involve changes inside the Atomspace (though some would involve > >>> changes in how the Atomspace is used). > >>> > >>> Just to be sure things are clear, I will enumerate here the issues > >>> under considerations here, and then discuss possible solutions. > >>> > >>> **THE ISSUES** > >>> > >>> There are two issues, separate but related: > >>> > >>> Issue 1: VARIABLE0NODE RE-USE > >>> > >>> Suppose we have two relations > >>> > >>> A) > >>> ForAllLink > >>> VariableNode "$X" > >>> ImplicationLink > >>> EvaluationLink > >>> PredicateNode "F" > >>> VariableNode "$X" > >>> EvaluationLink > >>> PredicateNode "G" > >>> VariableNode "$X" > >>> > >>> > >>> and > >>> > >>> B) > >>> ForAllLink > >>> VariableNode "$X" > >>> ImplicationLink > >>> EvaluationLink > >>> PredicateNode "G" > >>> VariableNode "$X" > >>> EvaluationLink > >>> PredicateNode "H" > >>> VariableNode "$X" > >>> > >>> > >>> ... > >>> > >>> In the current mode of usage of the Atomspace, it's the same > >>> VariableNode $X in both cases... > >>> > >>> Note, the Atomspace doesn't *require* this mode of usage. > Instead, > >>> we could use the Atomspace in such a way that variables which are > >>> attached to different scoping links, have different names and > Handles. > >>> So this is not really a matter of the Atomspace code, but more of > >>> the Atomspace usage pattern. (More on this below) > >>> > >>> > >>> > >>> Issue 2: SCOPED-EXPRESSION REDUNDANCY > >>> > >>> Suppose we also have in the Atomspace > >>> > >>> C) > >>> ForAllLink > >>> VariableNode "$Y" > >>> ImplicationLink > >>> EvaluationLink > >>> PredicateNode "F" > >>> VariableNode "$Y" > >>> EvaluationLink > >>> PredicateNode "G" > >>> VariableNode "$Y" > >>> > >>> > >>> Then: A and C are actually the same thing. But in the current > >>> Atomspace, they appear to be the different thing, because in > one the > >>> VariableNode is named "$X" and in the other the VariableNode is > named > >>> "$Y" > >>> > >>> **POTENTIAL SOLUTIONS** > >>> > >>> 1) > >>> One possible solution to the VariableNode Re-Use problem (Issue #1 > >>> above) is to simply adopt a convention not to do that. > >>> > >>> In other words, we could simply adopt a convention that if we > have two > >>> different scoping links, then the associated VariableNodes > should have > >>> different names & Handles. > >>> > >>> I see this as somewhat similar to the issue of Atom type > signatures. > >>> The Atomspace doesn't stop us from saying both > >>> > >>> EvaluationLink > >>> PredicateNode "eat" > >>> ListLink > >>> ConceptNode "Ben" > >>> ConceptNode "Steak" > >>> > >>> and > >>> > >>> EvaluationLink > >>> PredicateNode "eat" > >>> ListLink > >>> NumberNode "666" > >>> GroundedSchemaNode "release_the_snukes.py" > >>> TextNode "Chow Mein Kampf" > >>> > >>> or whatever... We have talked about implementing Atom type > >>> signatures that would prevent this sort of willy-nilly usage of > >>> PredicateNode arguments. But for the moment, we are relying on > >>> conventions regarding Atomspace usage patterns, and simply agreeing > >>> not to do stuff like the above in most cases. > >>> > >>> An agreement to not re-use the same VariableNode in different > scoping > >>> links, could be of a similar nature for the moment. Automated > >>> enforcement of this rule could potentially be implemented later, > >>> perhaps in the same batch of (future) code changes as > enforcement of > >>> Atom type signature checking. > >>> > >>> If we adopted this solution, then developers would have use of a > >>> helper function (already written and used in the R2L code) that > simply > >>> finds a VariableNode name not already used in a given Atomspace. > >>> > >>> 2) > >>> Another possible solution to the VariableNode Re-Use Problem is > not to > >>> do anything about it --- i.e. to accept that, unlike other Node > types, > >>> we want a VariableNode with a certain name X and a certain > Handle H to > >>> have multiple different meanings and uses inside the Atomspace.... > >>> > >>> (I note this is at variance with how we use other Node types. For > >>> instance, to handle different meanings of the word "cat", we create > >>> different ConceptNodes named "cat_1", "cat_2", etc. We don't > re-use > >>> the same ConceptNode named "cat" to serve for all these different > >>> senses --- even though natural language does this. But > variables are > >>> different from ordinary concepts, of course...) > >>> > >>> In this case, the chainers have a problem --- as would any other > >>> cognitive process needing to combine multiple different scoping > links > >>> in any way that paid attention to the Atom-structures being scoped. > >>> > >>> The most straightforward way to work around this problem would > be as > >>> follows. > >>> > >>> Suppose a cognitive process (e.g. a chainer) takes two scoping > links > >>> L1 and L2 as arguments. Since we are assuming the same > VariableNode > >>> with the same name and Handle can be re-used for multiple > meanings, it > >>> can't simply combine the Atoms scoped by L1 and L2. Instead, > what it > >>> should do is, in general: Create new scoping links L1* and > L2*. For > >>> instance L1* is identical to L1 but with different names for the > >>> variables. Then it should perform its cognitive processing on L1* > >>> and L2*, deriving its conclusion (let's say L3). L3 can just > be left > >>> in the Atomspace; there's no need to change its variable names. > >>> > >>> So e.g. inside this process > >>> > >>> ForAllLink > >>> VariableNode "$X" > >>> ImplicationLink > >>> EvaluationLink > >>> PredicateNode "F" > >>> VariableNode "$X" > >>> EvaluationLink > >>> PredicateNode "G" > >>> VariableNode "$X" > >>> > >>> would be replaced by > >>> > >>> A*) > >>> ForAllLink > >>> VariableNode "$X_345" > >>> ImplicationLink > >>> EvaluationLink > >>> PredicateNode "F" > >>> VariableNode "$X_345" > >>> EvaluationLink > >>> PredicateNode "G" > >>> VariableNode "$X_345" > >>> > >>> > >>> Now, this is not incredibly hard to code, as you note. But it does > >>> mean the chainer is creating copies of everything it uses, > which then > >>> need to be thrown out and garbage-collected immediately afterwards. > >>> (Or, to save hassle, the chainer could through out the original > >>> version with the re-used VariableNode names and keep the new > version > >>> with the unique VariableNode names. This would reduce wastage of > >>> processor time overall, but not as much a simply avoiding the > re-use > >>> of VariableNode names in the first place.) > >>> > >>> > >>> 3) > >>> For Issue #2, Scoped-Expression Redundancy, the simplest > solution is: > >>> > >>> -- When a new scoped expression L is created, a PM query is run > to see > >>> if the Atomspace contains any other expressions M that are > equivalent > >>> to L up to VariableNode renamings. If so, the two are merged, > via an > >>> appropriate policy. > >>> > >>> This is straightforward in the Atomspace. It's trickier when one > >>> thinks about backing-storage. Then the simplest solution is > >>> > >>> -- When a new scoped expression L is created, a PM query is run > >>> **against the backing store** to see if the Atomspace contains any > >>> other expressions M that are equivalent to L up to VariableNode > >>> renamings. If so, the two are merged, via an appropriate policy. > >>> > >>> The issue with the above is that we can't currently run PM queries > >>> against the backing store. But as previously discussed, this > is not > >>> extremely hard to implement in the sense of the simple PM > queries that > >>> would be required here (in which there would be no execution of > schema > >>> or other complexities, only matching of Atom-structures with > >>> VariableNodes in the place of VariableNodes (heh ;p)) ... > >>> > >>> 4) > >>> If we find that using the PM is too inefficient for solving > Issue #2, > >>> then a more advanced solution is to associate with each scoping > link L > >>> some sort of "canonical label" constituting a compact structure > that > >>> uniquely identifies the structure scoped by L. This would allow > >>> faster search for M that are equivalent to L up to VariableNode > >>> renaming (and could potentially deal with other kinds of > equivalence > >>> too). > >>> > >>> But we don't need to do this, now, I just pointed it out for > general > >>> interest and future use... > >>> > >>> > >>> ... > >>> > >>> I see that you prefer Solution #2 to the VariableNode Re-Use > problem, > >>> whereas William and Cassio and I were gravitating toward Solution > >>> #1.... I just want to make clear that neither requires changes > >>> inside the Atomspace, actually... > >>> > >>> On the other hand, you haven't opined on the Scoped-Expression > >>> Redundancy Issue .... These are two quite separate issues, > though > >>> both involve some of the same issues, right? > >>> > >>> I also questioned, in my prior email, whether VariableNodes > actually > >>> need names, given that they are uniquely identified by > Handles. But > >>> this is more a suggestion for future architecture re-thinking, > not a > >>> suggestion for immediate changes. I note that the reason > >>> VariableNodes have names is because me, Cassio, Senna and Thiago > >>> fairly hastily chose to do it that way in 2001 ---- we really > didn't > >>> think through all these issues in such depth at that time. You've > >>> already (Linas) undone a fair bit of stuff we decided at that time > >>> when we first created the Atomspace.... VariableNodes aren't > sacred > >>> either... > >>> > >>> -- Ben > >>> > >>> > >>> -- Ben > >>> > >>> > >>> > >>> > >>> On Thu, Sep 3, 2015 at 2:30 AM, Linas Vepstas > <linasveps...@gmail.com <mailto:linasveps...@gmail.com>> > > >>> wrote: > >>> > My knee-jerk reaction is that you are wildly over-engineering > to solve > >>> > a > >>> > rather narrow problem. > >>> > > >>> > At this time, the chainers form a small eco-system of their > own. In > >>> > that > >>> > eco-system, write some handy-dandy utility that issues > variable names > >>> > in > >>> > sequential order: v1, v2, v3... You don't have to redesign the > >>> > atomspace > >>> > from the ground-up to do this. Just use this simple, > low-brow method > >>> > for > >>> > now, and get back to working on the chainers. The chainers will > >>> > probably > >>> > get snagged on other problems. Keep iterating until the > chainers work > >>> > well, until they are done. > >>> > > >>> > At this point, you will discover one of two things: (a) the > unique > >>> > variable-name idea was awesome and is a panacea for all > problems (b) > >>> > It was > >>> > pretty useless, because some other (as yet unknown) problems > x,y,z make > >>> > it > >>> > irrelevant. Or maybe this: (c) a better solution is to do p,q,r > >>> > instead. If > >>> > it turns out that (a) is the case, then you can go back and > retrofit > >>> > this as > >>> > a core feature-function that the atomspace must have. > >>> > > >>> > Yeah, I understand that, right now, doing alpha-conversion > deep in the > >>> > chainer code is painful and tedious. So write a little > utility that > >>> > does > >>> > all the conversion before it gets to the chainer. That > utility won't > >>> > be > >>> > much fun, either, and it might even feel hacky. But, trust > me, it will > >>> > be a > >>> > lot less hacky than tearing into the guts of the atomsapce, > trying to > >>> > staple > >>> > in some brand-new gotta-have feature. Based on experience, > its that > >>> > case > >>> > (c) often shows up. Quite often, you can't even see the best > solution > >>> > until > >>> > you've been at it for a while. > >>> > > >>> > -- Linas > >>> > > >>> > On Wed, Sep 2, 2015 at 6:51 AM, Ben Goertzel > <b...@goertzel.org <mailto:b...@goertzel.org>> wrote: > >>> >> > >>> >> Nil, Cassio, Linas, etc., > >>> >> > >>> >> William and I discussed this a bit more at the office today... > >>> >> > >>> >> One conclusion I came to is that the requirement for nodes > to have > >>> >> names is kind of pointless. I mean, a ConceptNode created via > >>> >> blending doesn't really need a string name. And a VariableNode > >>> >> certainly shouldn't need a string name. This goes along > with my idea > >>> >> of associating Atoms with property lists... Some Atoms > could have a > >>> >> string name as a property, others not. > >>> >> > >>> >> Given that the current code requires nodes to have names, we > have to > >>> >> give our VariableNodes names. But then I suggest that, > for the time > >>> >> being, each time a new scoping link associated with a > VariableNode is > >>> >> created, this VariableNode should be assigned a new name > that is **not > >>> >> already used in the Atomspace in question**. > >>> >> > >>> >> (Otherwise, because of the requirement that two > VariableNodes with the > >>> >> same name must be the same entity with the same Handle, we get > >>> >> needlessly confusing situations such as William has been > running into. > >>> >> To avoid errors one needs to do alpha-conversion inside every > >>> >> inference, which means every inference has to create new > VariableNodes > >>> >> and then throw them out after the inference, which just > seems complex > >>> >> and unnecessary...) > >>> >> > >>> >> If one wants to have a nice simple name for a certain > VariableNode in > >>> >> one's Scheme, python or Haskell code, etc., that's OK. But this > >>> >> should be just for human usage.... > >>> >> > >>> >> In other words, I think that when > >>> >> > >>> >> " > >>> >> BindLink > >>> >> VariableNode $X > >>> >> InheritanceLink > >>> >> $X > >>> >> ConceptNode "cheeseburger" > >>> >> ExecutionLink > >>> >> GroundedSchemaNode "do_cheeseburger_stuff.py" > >>> >> $X > >>> >> " > >>> >> > >>> >> is loaded into the Atomspace, what should happen is that > >>> >> > >>> >> -- a new name is generated for the VariableNode labeled > "$X", which is > >>> >> unique for the Atomspace > >>> >> > >>> >> -- then the Atom-structure headed by the BindLink is loaded > into the > >>> >> Atomspace, using the new name for $X throughout > >>> >> > >>> >> ... > >>> >> > >>> >> Amen points out that this may make things ugly when printing > >>> >> structures from the Atomspace, that involve VariableNodes. > This is > >>> >> true, but could be solved by some pretty-printing postprocessing > >>> >> script as needed.. > >>> >> > >>> >> There remains the problem of merging, upon loading into an > Atomspace > >>> >> or backing store, two scoped structures that are identical up to > >>> >> variable relabelings.... Key to understand here is that, since > >>> >> VariableNodes don't really need names anyway, the names > should play no > >>> >> role in this merging process. Rather, the merging process > needs to > >>> >> pay attention to whether the Atom-dags rooted by two Scoping > links are > >>> >> identical-up-to-variable-renamings or not... > >>> >> > >>> >> Given a Scoping link L and associated Atom-dag rooted by it, > how can > >>> >> we tell if there is some other Scoping Link M that is > equivalent to L > >>> >> up to variable-relabeling, in a given Atomspace or backing > store? > >>> >> The straightforward way is to do a pattern matcher query > based on L. > >>> >> But this can be time-consuming. Also, currently there is no > way to > >>> >> run a PM query against the backing store. Running basic PM > queries > >>> >> against the Neo4j backing store should be relatively easy to > enable, > >>> >> as simple PM queries can be translated into Cypher. > Probably basic > >>> >> PM queries could be translated into postgres queries without > too much > >>> >> pain as well.. > >>> >> > >>> >> An alternative that William and I discussed would be to use > some sort > >>> >> of "canonical label" for the Atom-dag rooted by the scoping > link L. > >>> >> For instance, an algorithm for computing canonical labels for > >>> >> subgraphs, in a different context, is described in here: > >>> >> > >>> >> http://glaros.dtc.umn.edu/gkhome/fetch/papers/fsgICDM01.pdf > >>> >> > >>> >> An index of Scoping links, keyed by canonical labels, would > then be > >>> >> maintained. Then when inserting L, instead of a PM query, a > >>> >> comparison against this index would be done. Here the cost > is pushed > >>> >> into computing canonical labels for the Atom-dags rooted by > scoping > >>> >> links. Whether this is a good cost trade-off isn't obvious > in every > >>> >> case, but it probably is for small and frequently-referenced > >>> >> variable-bearing expressions... > >>> >> > >>> >> If we do not use either the PM or canonical labeling for > handling > >>> >> merging of variable-bearing structures upon insertion into an > >>> >> ATomspace or backing store, we will wind up with > >>> >> Atomspaces/backing-stores containing multiple redundant > expressions, > >>> >> differing only via arbitrary variable relabelings... > >>> >> > >>> >> -- Ben > >>> >> > >>> >> > >>> >> > >>> >> > >>> >> -- > >>> >> Ben Goertzel, PhD > >>> >> http://goertzel.org > >>> >> > >>> >> "The reasonable man adapts himself to the world: the > unreasonable one > >>> >> persists in trying to adapt the world to himself. Therefore all > >>> >> progress depends on the unreasonable man." -- George Bernard > Shaw > >>> >> > >>> >> -- > >>> >> You received this message because you are subscribed to the > Google > >>> >> Groups > >>> >> "opencog" group. > >>> >> To unsubscribe from this group and stop receiving emails > from it, send > >>> >> an > >>> >> email to opencog+unsubscr...@googlegroups.com > <mailto:opencog%2bunsubscr...@googlegroups.com>. > >>> >> To post to this group, send email to > opencog@googlegroups.com <mailto:opencog@googlegroups.com>. > >>> >> Visit this group at http://groups.google.com/group/opencog. > >>> >> To view this discussion on the web visit > >>> >> > >>> >> > > https://groups.google.com/d/msgid/opencog/CACYTDBf12cj9O4FP1To39R3scoHOdZdKHKS6vuKWVokF3Fr-QA%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+unsubscr...@googlegroups.com > <mailto:opencog%2bunsubscr...@googlegroups.com>. > >>> > To post to this group, send email to opencog@googlegroups.com > <mailto:opencog@googlegroups.com>. > >>> > Visit this group at http://groups.google.com/group/opencog. > >>> > To view this discussion on the web visit > >>> > > >>> > > > https://groups.google.com/d/msgid/opencog/CAHrUA36ordPyAo1R%3DVrF7HATjwOYqb0FiETYmYkuE7Om4fLg5Q%40mail.gmail.com. > >>> > > >>> > For more options, visit https://groups.google.com/d/optout. > >>> > >>> > >>> > >>> -- > >>> Ben Goertzel, PhD > >>> http://goertzel.org > >>> > >>> "The reasonable man adapts himself to the world: the > unreasonable one > >>> persists in trying to adapt the world to himself. Therefore all > >>> progress depends on the unreasonable man." -- George Bernard Shaw > >>> > >>> -- > >>> You received this message because you are subscribed to the > Google Groups > >>> "opencog" group. > >>> To unsubscribe from this group and stop receiving emails from > it, send an > >>> email to opencog+unsubscr...@googlegroups.com > <mailto:opencog%2bunsubscr...@googlegroups.com>. > >>> To post to this group, send email to opencog@googlegroups.com > <mailto:opencog@googlegroups.com>. > >>> Visit this group at http://groups.google.com/group/opencog. > >>> To view this discussion on the web visit > >>> > > https://groups.google.com/d/msgid/opencog/CACYTDBeup8%3DNaRHvXfvvBSO8Q1h5awVZT7%3Dm_SyKtEzF3YhyCw%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+unsubscr...@googlegroups.com > <mailto:opencog%2bunsubscr...@googlegroups.com>. > > To post to this group, send email to opencog@googlegroups.com > <mailto:opencog@googlegroups.com>. > > Visit this group at http://groups.google.com/group/opencog. > > To view this discussion on the web visit > > > > https://groups.google.com/d/msgid/opencog/CAHrUA34G4kW_Rd7G%3DDjBi2K%3DeWFcCQ1zTPpk%3DeMr%2B1_WN4n9vA%40mail.gmail.com. > > > > For more options, visithttps://groups.google.com/d/optout. > > > > -- > Ben Goertzel, PhD > http://goertzel.org > > "The reasonable man adapts himself to the world: the unreasonable one > persists in trying to adapt the world to himself. Therefore all > progress depends on the unreasonable man." -- George Bernard Shaw > > -- > You received this message because you are subscribed to the Google > Groups "opencog" group. > To unsubscribe from this group and stop receiving emails from it, > send an email to opencog+unsubscr...@googlegroups.com > <mailto:opencog%2bunsubscr...@googlegroups.com>. > To post to this group, send email to opencog@googlegroups.com > <mailto:opencog@googlegroups.com>. > Visit this group at http://groups.google.com/group/opencog. > To view this discussion on the web visit > > https://groups.google.com/d/msgid/opencog/CACYTDBeYi-X9VcDTa9%2B2jUvdX2TRs7vSUv85%3DPDRJ%3DfDeACxPQ%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+unsubscr...@googlegroups.com > <mailto:opencog+unsubscr...@googlegroups.com>. > To post to this group, send email to opencog@googlegroups.com > <mailto:opencog@googlegroups.com>. > Visit this group at http://groups.google.com/group/opencog. > To view this discussion on the web visit > https://groups.google.com/d/msgid/opencog/CAHrUA37kvF5HOCod49q5%2BtGLZm7t-VHoffy8LFAkAQd4FEmLhA%40mail.gmail.com > <https://groups.google.com/d/msgid/opencog/CAHrUA37kvF5HOCod49q5%2BtGLZm7t-VHoffy8LFAkAQd4FEmLhA%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+unsubscr...@googlegroups.com. To post to this group, send email to opencog@googlegroups.com. Visit this group at http://groups.google.com/group/opencog. To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/55ED5C19.1000608%40gmail.com. For more options, visit https://groups.google.com/d/optout. -- Ben Goertzel, PhD http://goertzel.org “I tell my students, when you go to these meetings, see what direction everyone is headed, so you can go in the opposite direction. Don’t polish the brass on the bandwagon.” – V. S. Ramachandran -- You received this message because you are subscribed to the Google Groups "opencog" group. To unsubscribe from this group and stop receiving emails from it, send an email to opencog+unsubscr...@googlegroups.com. To post to this group, send email to opencog@googlegroups.com. Visit this group at https://groups.google.com/group/opencog. To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/CACYTDBcJLmyFWArd420EUkK46iB_i6NPhj%2BQBgcMztpx4%3DwhYA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
