Variables, names, etc.
119 views
Skip to first unread message
Ben Goertzel
Sep 2, 2015, 7:51:20 AM9/2/15
to opencog
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
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
Ben Goertzel
Sep 2, 2015, 7:52:17 AM9/2/15
to opencog
On Wed, Sep 2, 2015 at 7:51 PM, Ben Goertzel <b...@goertzel.org> wrote:
> 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...
Note, Nil, that eliminating VariableNodes wouldn't really remove this
> 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...
problem. Variable-free representations can also have redundant
representations of the same knowledge, of course..
-- ben
Cassio Pennachin
Sep 2, 2015, 9:25:08 AM9/2/15
to opencog
Hi,
> 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**.
Agree, this is what I've been suggesting all along...
> 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.
Yes, and should be fairly simple to do, and also takes care of pretty printing.
> There remains the problem of merging, upon loading into an Atomspace
> or backing store, two scoped structures that are identical up to
> variable relabelings....
Yes, this is the more important (and difficult) question. I don't have a good solution in mind yet, will look at the algorithm you proposed.
Cheers,
Cassio
Ben Goertzel
Sep 2, 2015, 11:37:19 AM9/2/15
to opencog
>> There remains the problem of merging, upon loading into an Atomspace
>> or backing store, two scoped structures that are identical up to
>> variable relabelings....
>
> Yes, this is the more important (and difficult) question. I don't have a
> good solution in mind yet, will look at the algorithm you proposed.
The section "canonical labeling" on page 315 of the paper I linked,
>> or backing store, two scoped structures that are identical up to
>> variable relabelings....
>
> Yes, this is the more important (and difficult) question. I don't have a
> good solution in mind yet, will look at the algorithm you proposed.
gives an approach to associating an int sequence with a graph, which
is invariant under graph isomorphism.... This is not exactly the same
problem we have, but it's similar.... The basic idea is to make a
sequence of ints that encodes the structure of the hypergraph rooted
at the scoping link, and then do comparison on this int sequence
instead of pattern matching for the case of matching a scoping link
against others in an atomspace/backing-store....
Linas Vepstas
Sep 2, 2015, 2:30:21 PM9/2/15
to opencog
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
--
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 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.
Ben Goertzel
Sep 2, 2015, 10:19:14 PM9/2/15
to opencog
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
> https://groups.google.com/d/msgid/opencog/CAHrUA36ordPyAo1R%3DVrF7HATjwOYqb0FiETYmYkuE7Om4fLg5Q%40mail.gmail.com.
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
Nil Geisweiller
Sep 3, 2015, 6:20:33 AM9/3/15
to ope...@googlegroups.com
Hmmm, another subtlety has popped up in my head regarding Issue 1 (VN
Re-use). We might not always want to forbid 2 scope links to refer to
the same variables.
Consider the following (anonymous function x+3)
LambdaLink
VariableNode "$X"
PlusLink
VariableNode "$X"
NumberNode 3
The user might want to define another function reusing its body
LambdaLink
VariableNode "$X"
TimesLink
NumberNode 2
PlusLink
VariableNode "$X"
NumberNode 3
as you can see the same sub-hypergraph x+3 is being used to define 2
functions
\x -> x+3
and
\x -> 2*(x+3)
Do we want to allow that, is it any useful (well, it certainly is to
save space)? Or should the user be forced to create 2 distinct
hypergraphs with different variable names?
Maybe the scoped-variable-uniqueness rule must be relaxed... What about:
====== Renaming rule ======
Given a scope link, its variables should be uniquely renamed, iff its
body does not contain already scoped parts if those parts are more than
single variables.
===========================
It makes sense because doing otherwise would also change existing
hypergraphs, unless of course those existing hypergraphs are
copy/paste/variable-rename, which we may not want to
1. save space,
2. have the same variable semantically tied to multiple scope links.
Nil
Re-use). We might not always want to forbid 2 scope links to refer to
the same variables.
Consider the following (anonymous function x+3)
LambdaLink
VariableNode "$X"
PlusLink
VariableNode "$X"
NumberNode 3
The user might want to define another function reusing its body
LambdaLink
VariableNode "$X"
TimesLink
NumberNode 2
PlusLink
VariableNode "$X"
NumberNode 3
as you can see the same sub-hypergraph x+3 is being used to define 2
functions
\x -> x+3
and
\x -> 2*(x+3)
Do we want to allow that, is it any useful (well, it certainly is to
save space)? Or should the user be forced to create 2 distinct
hypergraphs with different variable names?
Maybe the scoped-variable-uniqueness rule must be relaxed... What about:
====== Renaming rule ======
Given a scope link, its variables should be uniquely renamed, iff its
body does not contain already scoped parts if those parts are more than
single variables.
===========================
It makes sense because doing otherwise would also change existing
hypergraphs, unless of course those existing hypergraphs are
copy/paste/variable-rename, which we may not want to
1. save space,
2. have the same variable semantically tied to multiple scope links.
Nil
Nil Geisweiller
Sep 3, 2015, 6:41:28 AM9/3/15
to ope...@googlegroups.com
What about we keep both alpha-conversion and somewhat enforced variable
name uniqueness?
Ideally I think should have something like:
1. The system should not break if the uniqueness of variable across
scope links is not met.
2. For having an atomspace with greater semantics vs structure
alignment, it should be recommended that different variable names be
used in different scoped hypergraphs (so don't use $X for everything).
3. For having faster execution, it should be recommended that different
variable names be using in different scoped hypergraphs.
So basically it suggests to encourage variable name uniqueness but still
have alpha-conversion implemented and used to save the day if necessary.
I fear that otherwise it's gonna lead to something too brittle. And as
Linas seems to suggest, alpha-conversion shouldn't be hacked in the URE,
it should be a generic function (probably in the execute module) that
cleanly take care of all alpha-conversions.
Nil
name uniqueness?
Ideally I think should have something like:
1. The system should not break if the uniqueness of variable across
scope links is not met.
2. For having an atomspace with greater semantics vs structure
alignment, it should be recommended that different variable names be
used in different scoped hypergraphs (so don't use $X for everything).
3. For having faster execution, it should be recommended that different
variable names be using in different scoped hypergraphs.
So basically it suggests to encourage variable name uniqueness but still
have alpha-conversion implemented and used to save the day if necessary.
I fear that otherwise it's gonna lead to something too brittle. And as
Linas seems to suggest, alpha-conversion shouldn't be hacked in the URE,
it should be a generic function (probably in the execute module) that
cleanly take care of all alpha-conversions.
Nil
Ben Goertzel
Sep 3, 2015, 7:02:01 AM9/3/15
to opencog
This is one viable possibility.
The other non-brittle possibility is to make the system refuse to
create a second scoping link for a VariableNode with a certain name,
right? Then once one created and scoped "$X", nobody else could
create another scoping link for "$X".... But this would require a
change to addAtom or whatever in its handling of VariableNodes...
However, if you and Linas are in favor of allowing multiple scopings
for the same VariableNode, then William and I can presumably go along
with it, and William can implement an alpha-conversion method....
Let g(L) denote the Atom-subhypergraph rooted at L, created by
following incoming sets
As I understand it, one would call "alpha-convert" on a scoping link
L, and it would create a copy of L, L*. To produce g(L*) from
g(L), one would
-- rename all the variables scoped by L with names that are new in the Atomspace
-- call alpha-convert on any other scoping links M in g(L), and then
put g(M*) into g(L*), in the same place that g(M) goes within g(L).
This step recurses...
Then chainers or other methods could proceed by first alpha-converting
their premises, and then doing inference on the Atoms thus produced,
instead of the original premises... (ignoring the original premises
thereafter)
Does that sound right?
-- Ben
> https://groups.google.com/d/msgid/opencog/55E823D6.4030602%40gmail.com.
The other non-brittle possibility is to make the system refuse to
create a second scoping link for a VariableNode with a certain name,
right? Then once one created and scoped "$X", nobody else could
create another scoping link for "$X".... But this would require a
change to addAtom or whatever in its handling of VariableNodes...
However, if you and Linas are in favor of allowing multiple scopings
for the same VariableNode, then William and I can presumably go along
with it, and William can implement an alpha-conversion method....
Let g(L) denote the Atom-subhypergraph rooted at L, created by
following incoming sets
As I understand it, one would call "alpha-convert" on a scoping link
L, and it would create a copy of L, L*. To produce g(L*) from
g(L), one would
-- rename all the variables scoped by L with names that are new in the Atomspace
-- call alpha-convert on any other scoping links M in g(L), and then
put g(M*) into g(L*), in the same place that g(M) goes within g(L).
This step recurses...
Then chainers or other methods could proceed by first alpha-converting
their premises, and then doing inference on the Atoms thus produced,
instead of the original premises... (ignoring the original premises
thereafter)
Does that sound right?
-- Ben
Nil Geisweiller
Sep 3, 2015, 7:20:55 AM9/3/15
to ope...@googlegroups.com
On 09/03/2015 01:01 PM, Ben Goertzel wrote:
> This is one viable possibility.
>
> The other non-brittle possibility is to make the system refuse to
> create a second scoping link for a VariableNode with a certain name,
> right? Then once one created and scoped "$X", nobody else could
> create another scoping link for "$X".... But this would require a
> change to addAtom or whatever in its handling of VariableNodes...
say add_link should refuse to add a scope link using already scoped
variables. This constraint may add some space overhead, but do we care
in practice? Probably not, I don't know.
Then it's up to the user (or a process using the AtomSpace API) to make
sure the names are unique, otherwise nothing can get added...
I personally prefer that over the AtomSpace silently renaming the
variables...
>
> However, if you and Linas are in favor of allowing multiple scopings
> for the same VariableNode, then William and I can presumably go along
> with it, and William can implement an alpha-conversion method....
>
> Let g(L) denote the Atom-subhypergraph rooted at L, created by
> following incoming sets
>
> As I understand it, one would call "alpha-convert" on a scoping link
> L, and it would create a copy of L, L*. To produce g(L*) from
> g(L), one would
>
> -- rename all the variables scoped by L with names that are new in the Atomspace
>
> -- call alpha-convert on any other scoping links M in g(L), and then
> put g(M*) into g(L*), in the same place that g(M) goes within g(L).
> This step recurses...
>
> Then chainers or other methods could proceed by first alpha-converting
> their premises, and then doing inference on the Atoms thus produced,
> instead of the original premises... (ignoring the original premises
> thereafter)
>
> Does that sound right?
Nil
Linas Vepstas
Sep 3, 2015, 6:35:41 PM9/3/15
to opencog
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
To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/CACYTDBeup8%3DNaRHvXfvvBSO8Q1h5awVZT7%3Dm_SyKtEzF3YhyCw%40mail.gmail.com.
Linas Vepstas
Sep 3, 2015, 6:44:33 PM9/3/15
to opencog
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
Ben Goertzel
Sep 3, 2015, 9:09:41 PM9/3/15
to opencog
Hi,
>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.
In the medium term we want an automatic solution. In the immediate term
we can make do with a convention if need be, I think...
> 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.
I don't think having the user name a VariableNode, and the system
rename it, is a good idea -- I agree this can cause confusion...
What I was thinking was something more like this:
(define vx cog-new-var)
(define fa (ForAllLink vx ...))
i.e. when you create a new VariableNode in the shell, it is
automatically assigned a name...
You could then find the name via
cog-name vx
if you need it for some reason (though you generally won't)
But having VariableNode names be purely internal, would be a step
toward removing VariableNode names entirely if we want to do that
later...
If you badly need to associate that VariableNode with some special
name (e.g. to put "E=mc^2" in the Atomspace or something) you can use
a ReferenceLink to make a structure like
ReferenceLink
CharacterNode "E"
vx
or something
A disadvantage of this approach is that existing scripts for creating
Atoms would not work, unless we either
-- created a script to transform old scripts into the new format,
or
-- added functionality for automatically renaming user-named
VariableNodes, but labeled this functionality as "deprecated out of
the box", i.e. to be used only w/ legacy scripts...
OTOH if we make the chainer assume scoping links are associated with
uniquely named VariableNodes, then the chainer will not work correctly
on Atoms created by these "legacy" scripts.. because they do not
follow the convention.... I guess this may be a practical argument
for implementing alpha-conversion .. hmmm...
> 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?
Hmmm.... i'll leave that to William...
> 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.
Maybe you're right...
Maybe creating and collecting temporary BindLinks *is* a bottleneck
for the URE right now, actually, but that's a separate issue...
> 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.
Ah, I see.... So if we enabled code to avoid redundant scoping links
in the Atomspace, we would then want to enable this functionality in
the backing store and use it to avoid redundant scoping links as well.
Although this would make storing scoping links slow...
> 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.
As a semi-aside -- on a conceptual level, when I originally thought
about this stuff in the 90s I was heavily influenced by Gul Agha's
idea of actors, e.g.
(the original thesis)
https://www.cypherpunks.to/erights/history/actors/AITR-844.pdf
(a brief summary)
http://arxiv.org/pdf/1008.1459.pdf
>So, ideas like "variables without names" or, more
> generally "atoms without names"
I guess you mean "nodes without names" --- links are atoms but do not
have names now!
> cannot be implemented until the Handle mess
> is diagnosed and fixed.
Makes sense.... Perhaps Nil can fix this later in the year after he
finishes his work with the URE innards ... after we all agree on what
to do ;p
> 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.
Well, assume we make flexible property tables for Atoms as previously
discussed...
In that case, why can't we just
-- use the AtomPtr internally for referencing Atoms
-- have the UUID be an optional property that an Atom gets when it
needs to be saved to a backing store, or communicated to another
Atomspace ... (We may want a better UUID allocation scheme but that's
a discrete issue for which there are many known solutions...)
-- have the name be an optional property that some Atoms have, if they
need to be indexed directly relative to external resources (e.g.
dictionaries, calculators, program code repositories...).
What else is needed?
-- Ben
>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.
we can make do with a convention if need be, I think...
> 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.
rename it, is a good idea -- I agree this can cause confusion...
What I was thinking was something more like this:
(define vx cog-new-var)
(define fa (ForAllLink vx ...))
i.e. when you create a new VariableNode in the shell, it is
automatically assigned a name...
You could then find the name via
cog-name vx
if you need it for some reason (though you generally won't)
But having VariableNode names be purely internal, would be a step
toward removing VariableNode names entirely if we want to do that
later...
If you badly need to associate that VariableNode with some special
name (e.g. to put "E=mc^2" in the Atomspace or something) you can use
a ReferenceLink to make a structure like
ReferenceLink
CharacterNode "E"
vx
or something
A disadvantage of this approach is that existing scripts for creating
Atoms would not work, unless we either
-- created a script to transform old scripts into the new format,
or
-- added functionality for automatically renaming user-named
VariableNodes, but labeled this functionality as "deprecated out of
the box", i.e. to be used only w/ legacy scripts...
OTOH if we make the chainer assume scoping links are associated with
uniquely named VariableNodes, then the chainer will not work correctly
on Atoms created by these "legacy" scripts.. because they do not
follow the convention.... I guess this may be a practical argument
for implementing alpha-conversion .. hmmm...
> 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.
Maybe creating and collecting temporary BindLinks *is* a bottleneck
for the URE right now, actually, but that's a separate issue...
> 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.
in the Atomspace, we would then want to enable this functionality in
the backing store and use it to avoid redundant scoping links as well.
Although this would make storing scoping links slow...
> 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.
about this stuff in the 90s I was heavily influenced by Gul Agha's
idea of actors, e.g.
(the original thesis)
https://www.cypherpunks.to/erights/history/actors/AITR-844.pdf
(a brief summary)
http://arxiv.org/pdf/1008.1459.pdf
>So, ideas like "variables without names" or, more
> generally "atoms without names"
have names now!
> cannot be implemented until the Handle mess
> is diagnosed and fixed.
finishes his work with the URE innards ... after we all agree on what
to do ;p
> 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.
discussed...
In that case, why can't we just
-- use the AtomPtr internally for referencing Atoms
-- have the UUID be an optional property that an Atom gets when it
needs to be saved to a backing store, or communicated to another
Atomspace ... (We may want a better UUID allocation scheme but that's
a discrete issue for which there are many known solutions...)
-- have the name be an optional property that some Atoms have, if they
need to be indexed directly relative to external resources (e.g.
dictionaries, calculators, program code repositories...).
What else is needed?
-- Ben
Ben Goertzel
Sep 3, 2015, 9:11:17 PM9/3/15
to opencog
That could immediately be made to happen with UUIDs, right? Changing
the name could be done without changing the UUID, if one wanted...
> https://groups.google.com/d/msgid/opencog/CAHrUA34G4kW_Rd7G%3DDjBi2K%3DeWFcCQ1zTPpk%3DeMr%2B1_WN4n9vA%40mail.gmail.com.
the name could be done without changing the UUID, if one wanted...
Ben Goertzel
Sep 3, 2015, 9:20:23 PM9/3/15
to opencog
Nil,
> Consider the following (anonymous function x+3)
>
> LambdaLink
> VariableNode "$X"
> PlusLink
> VariableNode "$X"
> NumberNode 3
>
> The user might want to define another function reusing its body
>
> LambdaLink
> VariableNode "$X"
> TimesLink
> NumberNode 2
> PlusLink
> VariableNode "$X"
> NumberNode 3
>
> as you can see the same sub-hypergraph x+3 is being used to define 2
> functions
>
> \x -> x+3
>
> and
>
> \x -> 2*(x+3)
>
> Do we want to allow that, is it any useful (well, it certainly is to save
> space)? Or should the user be forced to create 2 distinct hypergraphs with
> different variable names?
Well the user could also do something like
DefineLink
DefinedSchemaNode "add3"
VariableNode "$X"
LambdaLink
VariableNode "$Y"
TimesLink
NumberNode 2
ExecutionOutputLink
DefinedSchemaNode "add3"
Variablenode "$Y"
In this case "x+3" is so small it's not worth the trouble, but for a
longer subroutine it would be....
So the user is not FORCED to copy-paste code, they can always re-use
existing code as a subroutine by making it a defined schema. This is
how ordinary programming works, in most languages, right? The same
block of code is not referred to in two different functions
*directly*, but if you want to reuse a block of code, you wrap it in a
function and then refer to that function wherever you need to....
> ====== Renaming rule ======
>
> Given a scope link, its variables should be uniquely renamed, iff its body
> does not contain already scoped parts if those parts are more than single
> variables.
I don't see the point here.... Then we could still have confusions
due to name re-use, I think...
As far as I can tell we need to either
-- enforce VariableNode name uniqueness (and avoid cut-and-paste via
labeled functions like in programming languages)
or
-- introduce alpha-conversion
I note that even with alpha-conversion, explicitly using labeled
functions to avoid cut-and-paste may have advantages...
ben
> Consider the following (anonymous function x+3)
>
> LambdaLink
> VariableNode "$X"
> PlusLink
> VariableNode "$X"
> NumberNode 3
>
> The user might want to define another function reusing its body
>
> LambdaLink
> VariableNode "$X"
> TimesLink
> NumberNode 2
> PlusLink
> VariableNode "$X"
> NumberNode 3
>
> as you can see the same sub-hypergraph x+3 is being used to define 2
> functions
>
> \x -> x+3
>
> and
>
> \x -> 2*(x+3)
>
> Do we want to allow that, is it any useful (well, it certainly is to save
> space)? Or should the user be forced to create 2 distinct hypergraphs with
> different variable names?
DefineLink
DefinedSchemaNode "add3"
VariableNode "$X"
LambdaLink
VariableNode "$X"
PlusLink
VariableNode "$X"
NumberNode 3
and then
VariableNode "$X"
PlusLink
VariableNode "$X"
NumberNode 3
LambdaLink
VariableNode "$Y"
TimesLink
NumberNode 2
ExecutionOutputLink
DefinedSchemaNode "add3"
Variablenode "$Y"
In this case "x+3" is so small it's not worth the trouble, but for a
longer subroutine it would be....
So the user is not FORCED to copy-paste code, they can always re-use
existing code as a subroutine by making it a defined schema. This is
how ordinary programming works, in most languages, right? The same
block of code is not referred to in two different functions
*directly*, but if you want to reuse a block of code, you wrap it in a
function and then refer to that function wherever you need to....
> ====== Renaming rule ======
>
> Given a scope link, its variables should be uniquely renamed, iff its body
> does not contain already scoped parts if those parts are more than single
> variables.
due to name re-use, I think...
As far as I can tell we need to either
-- enforce VariableNode name uniqueness (and avoid cut-and-paste via
labeled functions like in programming languages)
or
-- introduce alpha-conversion
I note that even with alpha-conversion, explicitly using labeled
functions to avoid cut-and-paste may have advantages...
ben
Nil Geisweiller
Sep 4, 2015, 2:35:24 AM9/4/15
to ope...@googlegroups.com
Ben,
Good point. I thought "here's something we can do in atomese that we
can't do in a classical programming language!", but as you point out it
wouldn't save memory any much memory.
Nil
can't do in a classical programming language!", but as you point out it
wouldn't save memory any much memory.
Nil
Nil Geisweiller
Sep 4, 2015, 3:17:08 AM9/4/15
to ope...@googlegroups.com
On 09/04/2015 03:09 AM, Ben Goertzel wrote:
>> 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.
>
> I don't think having the user name a VariableNode, and the system
> rename it, is a good idea -- I agree this can cause confusion...
>
> What I was thinking was something more like this:
>
> (define vx cog-new-var)
> (define fa (ForAllLink vx ...))
> If you badly need to associate that VariableNode with some special
> name (e.g. to put "E=mc^2" in the Atomspace or something) you can use
> a ReferenceLink to make a structure like
>
> ReferenceLink
> CharacterNode "E"
> vx
>
> or something
prepend that string to the generated variable node name?
>
> A disadvantage of this approach is that existing scripts for creating
> Atoms would not work, unless we either
>
> -- created a script to transform old scripts into the new format,
>
> or
>
> -- added functionality for automatically renaming user-named
> VariableNodes, but labeled this functionality as "deprecated out of
> the box", i.e. to be used only w/ legacy scripts...
>
> OTOH if we make the chainer assume scoping links are associated with
> uniquely named VariableNodes, then the chainer will not work correctly
> on Atoms created by these "legacy" scripts.. because they do not
> follow the convention.... I guess this may be a practical argument
> for implementing alpha-conversion .. hmmm...
adding the code in ScopeLink class to forbid same variables. William
could already use that to work around his problems (a few PLN rules as
far as I understand) without having to change 100+ scm files.
Then if overtime we realize forbidding same variable names in scope link
is a must have we add the forbidding code in ScopeLink and can write
that script to convert all the VariableNode uses into cog-new-var.
Nil
Ben Goertzel
Sep 4, 2015, 3:21:51 AM9/4/15
to opencog
If we don't have alpha-conversion, then PLN (and other comparable URE
applications) will screw up when they encounter pairs of scoping links
that re-use the same VariableNode name
I think this is an accident waiting to happen. I think we need to either
-- implement alpha-conversion
-- get rid of VariableNode re-use
In terms of conserving William's time, it may actually be faster for
him to implement alpha-conversion in the URE, than deal with getting
rid of VariableNode re-use in a nice way that doesn't just break all
the previously written Scheme scripts...
-- Ben
applications) will screw up when they encounter pairs of scoping links
that re-use the same VariableNode name
I think this is an accident waiting to happen. I think we need to either
-- implement alpha-conversion
-- get rid of VariableNode re-use
In terms of conserving William's time, it may actually be faster for
him to implement alpha-conversion in the URE, than deal with getting
rid of VariableNode re-use in a nice way that doesn't just break all
the previously written Scheme scripts...
-- Ben
> --
> 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 http://groups.google.com/group/opencog.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/opencog/55E94572.7090404%40gmail.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 http://groups.google.com/group/opencog.
> To view this discussion on the web visit
Nil Geisweiller
Sep 4, 2015, 3:33:27 AM9/4/15
to ope...@googlegroups.com
Ben,
On 09/04/2015 09:21 AM, Ben Goertzel wrote:
> If we don't have alpha-conversion, then PLN (and other comparable URE
> applications) will screw up when they encounter pairs of scoping links
> that re-use the same VariableNode name
I'm not entirely sure of that. It seems to me alpha-conversion, done on
fly while running the pattern matcher or executing some schema shouldn't
even interfere with the AtomSpace, it's just up to the pattern matcher
and execution module to take care of variable substitution in a sensible
way. But maybe I'm not seeing the problem. Do you have an example in
mind (beside William's example in PR
https://github.com/opencog/atomspace/pull/241 where the problem is about
scope link creation)?
Nil
On 09/04/2015 09:21 AM, Ben Goertzel wrote:
> If we don't have alpha-conversion, then PLN (and other comparable URE
> applications) will screw up when they encounter pairs of scoping links
> that re-use the same VariableNode name
fly while running the pattern matcher or executing some schema shouldn't
even interfere with the AtomSpace, it's just up to the pattern matcher
and execution module to take care of variable substitution in a sensible
way. But maybe I'm not seeing the problem. Do you have an example in
mind (beside William's example in PR
https://github.com/opencog/atomspace/pull/241 where the problem is about
scope link creation)?
Nil
Nil Geisweiller
Sep 4, 2015, 3:47:21 AM9/4/15
to ope...@googlegroups.com
On 09/04/2015 09:33 AM, Nil Geisweiller wrote:
> Ben,
>
> On 09/04/2015 09:21 AM, Ben Goertzel wrote:
>> If we don't have alpha-conversion, then PLN (and other comparable URE
>> applications) will screw up when they encounter pairs of scoping links
>> that re-use the same VariableNode name
>
> I'm not entirely sure of that. It seems to me alpha-conversion, done on
> fly while running the pattern matcher or executing some schema shouldn't
> even interfere with the AtomSpace, it's just up to the pattern matcher
> and execution module to take care of variable substitution in a sensible
> way. But maybe I'm not seeing the problem. Do you have an example in
> mind (beside William's example in PR
> https://github.com/opencog/atomspace/pull/241 where the problem is about
> scope link creation)?
http://dictionary.reference.com/browse/name+capture, and that is
typically why we do alpha-conversion. The problem here is in the rule
itself, doing the wrong thing which leads to name capture, not the
AtomSpace itself. So cog-new-var is a convenient way to the user to do
the right thing. The rest of the atomspace taking care of computing and
rewriting terms (the execution module and the pattern matcher) should
also do the right thing like avoiding name capture. Do they? I don't
know for sure because I don't know the code well enough, but they should
and that's it...
Well, maybe I'm missing something ;-)
Nil
William Ma
Sep 4, 2015, 4:27:24 AM9/4/15
to opencog
way. But maybe I'm not seeing the problem. Do you have an example in
mind (beside William's example in PR
https://github.com/opencog/atomspace/pull/241 where the problem is about
scope link creation)?
In my example, the two MemberLink at the top doesn't even have to be outputted by a rule. If it's created by another person/process it's equally problematic.
For BC, the code already generate the new variables in the updated Rule's standardize-apart code (FC will also need to use it eventually). However, it won't solve the case when the same VariableNode in the AtomSpace is already inside multiple scope.
It should also be possible when PM matched a variable to another VariableNode in the atomspace, to go up to its antecedent to see what "type" the VariableNode is, so that BC can chain solve the variables (kind of hard to describe, but that's what BC do). With the VariableNode inside multiple scope, this won't be possible. Right now BC just assumes the random VariableNodes it encountered are untyped.
Ben Goertzel
Sep 4, 2015, 6:49:08 AM9/4/15
to opencog
Hmm, yes, William also has a point here...
In the current situation, where we can re-use the (VariableNode "$X")
in many places, the different uses of (VariableNode "$X") are
generally going to have different types...
Going back to the analogy of programming languages, in most
programming languages, one can re-use a variable name inside different
functions... but not inside the same function...
So if we consider "the Atom-graph headed by a particular scoping link"
as analogous to a function in a program, then we have a similar
situation where we can re-use a variable-name inside different
functions...
Consider, though: When one has a link L that links to a (VariableNode
"$X") -- in order to determine the scope within which (VariableNode
"$X") is considered, a bunch of link-following must be done to find
the scoping links that heads an Atom-graph containing L. For
instance, this link-following must be done to find the type which
(VariableNode "$X") should be assigned, in the context of L.
On the other hand, if VariableNodes had to be associated with unique
scoping links, then if when one has a link L that links to a
(VariableNode "$X") , one can immediately find the scope within which
(VariableNode "$X") is considered (because it's the only scoping link
connected to (VariableNode "$X"), and thus immediately find the type
of (VariableNode $X)...
This seems another way in which allowing the same (VariableNode "$X")
to be used in multiple senses (i.e. in multiple scopes, with
multiple types) creates confusion...
In a programming language, one has well-defined scopes (e.g.
functions) and then a variable name only has to be unique within that
scope. But one never has to do a lot of work to figure out what scope
one is operating inside.
Whether the above complexities actually cause any hassles for PLN, I'm
not sure... maybe, maybe not...
But I'm sure that if VariableNodes had unique scoping links, things
would be simpler and there would be way fewer confusing complexities
to think about !!
-- Ben
In the current situation, where we can re-use the (VariableNode "$X")
in many places, the different uses of (VariableNode "$X") are
generally going to have different types...
Going back to the analogy of programming languages, in most
programming languages, one can re-use a variable name inside different
functions... but not inside the same function...
So if we consider "the Atom-graph headed by a particular scoping link"
as analogous to a function in a program, then we have a similar
situation where we can re-use a variable-name inside different
functions...
Consider, though: When one has a link L that links to a (VariableNode
"$X") -- in order to determine the scope within which (VariableNode
"$X") is considered, a bunch of link-following must be done to find
the scoping links that heads an Atom-graph containing L. For
instance, this link-following must be done to find the type which
(VariableNode "$X") should be assigned, in the context of L.
On the other hand, if VariableNodes had to be associated with unique
scoping links, then if when one has a link L that links to a
(VariableNode "$X") , one can immediately find the scope within which
(VariableNode "$X") is considered (because it's the only scoping link
connected to (VariableNode "$X"), and thus immediately find the type
of (VariableNode $X)...
This seems another way in which allowing the same (VariableNode "$X")
to be used in multiple senses (i.e. in multiple scopes, with
multiple types) creates confusion...
In a programming language, one has well-defined scopes (e.g.
functions) and then a variable name only has to be unique within that
scope. But one never has to do a lot of work to figure out what scope
one is operating inside.
Whether the above complexities actually cause any hassles for PLN, I'm
not sure... maybe, maybe not...
But I'm sure that if VariableNodes had unique scoping links, things
would be simpler and there would be way fewer confusing complexities
to think about !!
-- Ben
> --
> 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 http://groups.google.com/group/opencog.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/opencog/d3ef9ed1-5355-4e23-9eb9-13e96efb02c3%40googlegroups.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 http://groups.google.com/group/opencog.
> To view this discussion on the web visit
Linas Vepstas
Sep 5, 2015, 5:47:25 PM9/5/15
to opencog
On Thu, Sep 3, 2015 at 8:09 PM, Ben Goertzel <b...@goertzel.org> wrote:
> 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.
I don't think having the user name a VariableNode, and the system
rename it, is a good idea -- I agree this can cause confusion...
What I was thinking was something more like this:
(define vx cog-new-var)
(define fa (ForAllLink vx ...))
i.e. when you create a new VariableNode in the shell, it is
automatically assigned a name...
That would be a reasonable convention.
A disadvantage of this approach is that existing scripts for creating
Atoms would not work,
How many of these are there? The unit tests do not need to be
altered at all ... there are some examples ... what else is there? Certainly, nothing that would have PLN run on it ... unless there's a bunch in the genetic data that you have?
> 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.
Ah, I see.... So if we enabled code to avoid redundant scoping links
in the Atomspace, we would then want to enable this functionality in
the backing store and use it to avoid redundant scoping links as well.
Although this would make storing scoping links slow...
You keep thinking and saying "slow" but should really measure the throughput and the latency to get a better idea. Both python and scheme are also slow, placing quite hefty latencies to get into and out of the interpreter. I doubt SQL is all that much slower. Touching atoms "in bulk" is fastest for all three, and get incoming set is a bulk transfer.
Writes are asynchronous (thus they are "instant"): to store an atom, its placed on a queue and some other thread stores it later.
Ahhh Carl Hewitt. He also believes that the Actor model describes quantum mechanics, and started editing all of the wikipedia quantum articles to state this. This eventually lead to a massive explosion resulting in his being banned.
Well, if you don't know the name of a node, you loose the ability to search for it by name.
I guess we could turn on, right now, the ability to have multiple copies of nodes that don't have names. They would simply not be indexed. They would not be singletons -- each one would be, by definition, different from the others.
I'm not sure what this gets you .. well, I guess that "cog-new-var" as proposed at the top becomes trivial :-)
-- linas
Linas Vepstas
Sep 5, 2015, 5:49:55 PM9/5/15
to opencog
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
To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/CACYTDBeYi-X9VcDTa9%2B2jUvdX2TRs7vSUv85%3DPDRJ%3DfDeACxPQ%40mail.gmail.com.
Ben Goertzel
Sep 7, 2015, 4:40:14 AM9/7/15
to opencog
So -- it seems we have agreement that enabling
> something more like this:
>
> (define vx cog-new-var)
> (define fa (ForAllLink vx ...))
>
> i.e. when you create a new VariableNode in the shell, it is
> automatically assigned a name...
is an OK idea.... Adopting this convention would, in effect, cause
the Atomspace not to have multiple VariableNodes with the same name in
it --- except in cases where we were loading some Atoms from a backing
store (or elsewhere) into an already-existing Atomspace...
However, this would mean that if we want to use PLN on the output of
R2L or of the bio-database-conversion scripts, we would need to change
these to use cog-new-var rather than to create multiple variables with
the same name...
For the case of loading Atoms from a backing-store, we would need to
implement the PM-based scoping-link revision that I mentioned. Linas
indicates that even for saving, this can work OK with the
backing-store now, if the right options are enabled...
After all the discussion, the above remains my preferred course of action.
-- Ben
> https://groups.google.com/d/msgid/opencog/CAHrUA37kvF5HOCod49q5%2BtGLZm7t-VHoffy8LFAkAQd4FEmLhA%40mail.gmail.com.
> something more like this:
>
> (define vx cog-new-var)
> (define fa (ForAllLink vx ...))
>
> i.e. when you create a new VariableNode in the shell, it is
> automatically assigned a name...
the Atomspace not to have multiple VariableNodes with the same name in
it --- except in cases where we were loading some Atoms from a backing
store (or elsewhere) into an already-existing Atomspace...
However, this would mean that if we want to use PLN on the output of
R2L or of the bio-database-conversion scripts, we would need to change
these to use cog-new-var rather than to create multiple variables with
the same name...
For the case of loading Atoms from a backing-store, we would need to
implement the PM-based scoping-link revision that I mentioned. Linas
indicates that even for saving, this can work OK with the
backing-store now, if the right options are enabled...
After all the discussion, the above remains my preferred course of action.
-- Ben
Nil Geisweiller
Sep 7, 2015, 5:42:53 AM9/7/15
to ope...@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
> <linasv...@gmail.com <mailto:linasv...@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
> <linasv...@gmail.com <mailto:linasv...@gmail.com>>
> <linasv...@gmail.com <mailto:linasv...@gmail.com>>
> <mailto:opencog%2Bunsu...@googlegroups.com>.
> <https://groups.google.com/d/msgid/opencog/CAHrUA37kvF5HOCod49q5%2BtGLZm7t-VHoffy8LFAkAQd4FEmLhA%40mail.gmail.com?utm_medium=email&utm_source=footer>.
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
> <linasv...@gmail.com <mailto:linasv...@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
> >>> >> To post to this group, send email to
> ope...@googlegroups.com <mailto:ope...@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+u...@googlegroups.com
> <mailto:opencog%2Bunsu...@googlegroups.com>.
> >>> >> 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
> >>> > 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
> <mailto:ope...@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+u...@googlegroups.com
> <mailto:opencog%2Bunsu...@googlegroups.com>.
> >>> > 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+u...@googlegroups.com
> >>> To post to this group, send email to ope...@googlegroups.com
> <mailto:ope...@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+u...@googlegroups.com
> <mailto:opencog%2Bunsu...@googlegroups.com>.
> >>> 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+u...@googlegroups.com
> > To post to this group, send email to ope...@googlegroups.com
> <mailto:ope...@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.
> > 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.
> >
>
>
>
> --
> 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+u...@googlegroups.com
> <mailto:opencog%2Bunsu...@googlegroups.com>.
>
>
> --
> 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+u...@googlegroups.com
> To post to this group, send email to ope...@googlegroups.com
> <mailto:ope...@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.
>
>
> 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+u...@googlegroups.com
> <mailto: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 email to opencog+u...@googlegroups.com
> To post to this group, send email to ope...@googlegroups.com
> <mailto:ope...@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
> To view this discussion on the web visit
> <https://groups.google.com/d/msgid/opencog/CAHrUA37kvF5HOCod49q5%2BtGLZm7t-VHoffy8LFAkAQd4FEmLhA%40mail.gmail.com?utm_medium=email&utm_source=footer>.
Ben Goertzel
Sep 7, 2015, 5:47:15 AM9/7/15
to opencog
yeah... many solutions are possible if we want to change the Atomspace
API and indexes... my solution of cog-new-var was intended as a fairly
elegant short-term solution that will not require any deep changes...
we can then review possible deep changes later when we introduce Atom
signatures and revisit the UUID/Handle issue...
ben
> email to opencog+u...@googlegroups.com.
> To post to this group, send email to ope...@googlegroups.com.
API and indexes... my solution of cog-new-var was intended as a fairly
elegant short-term solution that will not require any deep changes...
we can then review possible deep changes later when we introduce Atom
signatures and revisit the UUID/Handle issue...
ben
> To post to this group, send email to ope...@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.
> To view this discussion on the web visit
Nil Geisweiller
Sep 7, 2015, 6:11:24 AM9/7/15
to ope...@googlegroups.com
On 09/06/2015 12:47 AM, Linas Vepstas wrote:
> (define vx cog-new-var)
> (define fa (ForAllLink vx ...))
>
> i.e. when you create a new VariableNode in the shell, it is
> automatically assigned a name...
>
>
> That would be a reasonable convention.
>
> A disadvantage of this approach is that existing scripts for creating
> Atoms would not work,
>
>
> How many of these are there? The unit tests do not need to be
> altered at all ... there are some examples ... what else is there?
> Certainly, nothing that would have PLN run on it ... unless there's a
> bunch in the genetic data that you have?
problem (unless we don't forbid variable reuse in scopes right away,
which I suggest for starter, just code and provide cog-new-var, and
we'll see).
Nil
> --
> You received this message because you are subscribed to the Google
> Groups "opencog" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to opencog+u...@googlegroups.com
> <mailto: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 email to opencog+u...@googlegroups.com
> To post to this group, send email to ope...@googlegroups.com
> <mailto:ope...@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/CAHrUA36dvKnjVszf7b8BcQp0pddTgoG6hN84%2BJPEP_1k2-SGqA%40mail.gmail.com
> To view this discussion on the web visit
> <https://groups.google.com/d/msgid/opencog/CAHrUA36dvKnjVszf7b8BcQp0pddTgoG6hN84%2BJPEP_1k2-SGqA%40mail.gmail.com?utm_medium=email&utm_source=footer>.
Nil Geisweiller
Sep 7, 2015, 6:12:21 AM9/7/15
to ope...@googlegroups.com
On 09/07/2015 12:47 PM, Ben Goertzel wrote:
> yeah... many solutions are possible if we want to change the Atomspace
> API and indexes... my solution of cog-new-var was intended as a fairly
> elegant short-term solution that will not require any deep changes...
> we can then review possible deep changes later when we introduce Atom
> signatures and revisit the UUID/Handle issue...
Nil
Linas Vepstas
Sep 9, 2015, 2:06:16 PM9/9/15
to opencog
FWIW, I took a quick look again at allowing nodes with no names.
Implementing this is "easy" but has the following reprecussions:
* Every node insertion has to check for this as a special case, and
handle it differently. This adds a minor performance hit.
* Nameless nodes cannot be inserted into indexes, since there is no
point: they cannot be looked up, at least, not by name.
* They present a garbage-collection issue: They cannot be removed
unless you have a pointer to them; if you loose that pointer, that's
it. You could keep an index of all un-named nodes, and periodically
sweep it for orphans. (Or have attention allocation do it?)
My quick conclusion is that they introduce too many negatives for a
questionable amount of positive usefulness. If they had a better
use-case, that would outweigh the above, then they would not be hard
to implement (err, I implemented it. its about 10 or 20 lines of
code).
--linas
On Mon, Sep 7, 2015 at 5:12 AM, 'Nil Geisweiller' via opencog
> https://groups.google.com/d/msgid/opencog/55ED6302.5030000%40gmail.com.
Implementing this is "easy" but has the following reprecussions:
* Every node insertion has to check for this as a special case, and
handle it differently. This adds a minor performance hit.
* Nameless nodes cannot be inserted into indexes, since there is no
point: they cannot be looked up, at least, not by name.
* They present a garbage-collection issue: They cannot be removed
unless you have a pointer to them; if you loose that pointer, that's
it. You could keep an index of all un-named nodes, and periodically
sweep it for orphans. (Or have attention allocation do it?)
My quick conclusion is that they introduce too many negatives for a
questionable amount of positive usefulness. If they had a better
use-case, that would outweigh the above, then they would not be hard
to implement (err, I implemented it. its about 10 or 20 lines of
code).
--linas
On Mon, Sep 7, 2015 at 5:12 AM, 'Nil Geisweiller' via opencog
Ben Goertzel
Nov 16, 2016, 9:22:04 PM11/16/16
to opencog, Nil Geisweiller
Nil,
I just dug up and looked through our dialogue on this topic from a
year ago... see below...
ben
an email to opencog+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.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
I just dug up and looked through our dialogue on this topic from a
year ago... see below...
ben
To post to this group, send email to ope...@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.
To view this discussion on the web visit
For more options, visit https://groups.google.com/d/optout.
--
Ben Goertzel, PhD
http://goertzel.org
everyone is headed, so you can go in the opposite direction. Don’t
polish the brass on the bandwagon.” – V. S. Ramachandran
Reply all
Reply to author
Forward
0 new messages