On 10/16/2016 07:32 AM, Linas Vepstas wrote:
Shortly after sending this message, I decided that it was a bad idea to
let a sleeping bug lie. I am totally and completly confused by
ImplicationLink. I flat out do not understand it, at all, not one whit.
Consider this:
(ImplicationLink (VariableNode "$X") (PredicateNode "is-human"))
In C++ I can cast this to a ScopeLink, and then as the ScopeLink "what
are your variables?" and I get back the answer "None".
The answer is correct, $X is not scoped under the ImplicationLink. The
ONLY way to have variables scoped under an ImplicationLink is to use the
form
Implication
<variable declaration>
<implicant>
<implicand>
Here specifically $X has got to be something akin to a PredicateNode, a
Lambda or anything that acts is like a predicate, i.e. a function with
co-domain TV.
That's it, game over. My brain no longer functions. What does it mean,
to have a link that has variables, to not have variables in it???
The variable may still be scoped but not in the ImplicationLink.
My knee-jerk reaction is that the code is buggy, that it is a mistake to
have ImplicationLink inherit from ScopeLink, that some chain of
The code is/should-be not buggy.
accidents lead to this point. The wikipage is utterly
incomprehensible: I don't understand it either. What is Implication?
Can we fix this so it makes sense in some way?
Oh, perhaps the confusion comes from this: unlike most scope links, when
an ImplicationLink has no variable declaration it is not assumed that
all free variables are under its scope.
I've added a note about it in the wiki.
Maybe we should split this in two link types.
ImplicationLink
ImplicationScopeLink
The ImplicationLink would be used only with the form
ImplicationLink
<implicant>
<implicand>
and ImplicationScopeLink only with these forms
ImplicationScopeLink
<variable declaration>
<implicant-body>
<implicand-body>
ImplicationScopeLink
<implicant-body>
<implicand-body>
Only ImplicationScopeLink would inherit ScopeLink and would implicitly
scopes the free variables when the variable declaration is missing, like
the other scope links.
What do you think?
Nil
--linas
On Sat, Oct 15, 2016 at 10:11 PM, Linas Vepstas <[email protected]
<mailto:[email protected]>> wrote:
OK, I'll defer the conversation. Sooner or later, Amen will open
another bug report once again titled "question: feature or bug?" and
I guess we can deal with it then.
--linas
On Thu, Oct 13, 2016 at 12:56 AM, 'Nil Geisweiller' via opencog
<[email protected] <mailto:[email protected]>> wrote:
On 10/13/2016 02:38 AM, Ben Goertzel wrote:
Wait ... we can have nested ScopeLinks, so that a variable
embedded in
two ScopeLInks can be bound by the outer one or the inner
one... no?
Yes, no problem, if a variable is scoped by both then the inner
one will cover the outer one.
Anyway, I don't see a problem with having a C++ ImplicationLink
class inherit the ScopeLink class. The only think to take care
of is to have no variable extracted when there are 2 arguments,
that is when using the non sugar for of the ImplicationLink
ImplicationLink
P
Q
I think that is what the code does, but if it doesn't or its
buggy it should be fixed, I'm happy to fix it as soon as unit
test fails because of it.
Nil
On Wed, Oct 12, 2016 at 4:08 PM, Linas Vepstas
<[email protected] <mailto:[email protected]>> wrote:
On Wed, Oct 12, 2016 at 12:53 PM, Nil Geisweiller
<[email protected] <mailto:[email protected]>>
wrote:
On 10/12/2016 06:55 PM, Linas Vepstas wrote:
Well, yes, but Nil,, look at the core issue: the
variable X in the
Implication link is bound, but the unit test is
pretending that its
free. My question is: are you *sure* you really
want the
implicationLink to inherit from Scope Link (and
thus, always bind it's
variables)?
X is supposed to be free in the ImplicationLink,
Really? The C++ code has ImplicationLink inheriting
from ScopeLink, thus
making it bound. Perhaps ImplicationLink should not
inherit from ScopeLink?
?
bound to the PutLink. Yes I am sure I want it free
in the ImplicationLink.
Having ImplicationLink inherit Scope should not
prevent that. The syntax
itself is ambiguity free, if there are ambiguities
in the code it's a bug
and it should be fixed.
Again, I'm happy to fix anything related to that
once the issue reappears.
Nil
--linas
On Wed, Oct 12, 2016 at 10:39 AM, Nil Geisweiller
<[email protected]
<mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>>> wrote:
OK, when they fail again I guess you might
feel free to push to the
master, as we're apparently using as a dev
branch, and then I'll fix
that.
Nil
On 10/12/2016 06:17 PM, Linas Vepstas wrote:
No, actually, I worked around that.
The only reason that PutLinkUTest
currently passes is because
PutLink
fails to treat ScopeLinks correctly.
When that gets fixed, the
unit
test will fail ... the issue remains
the same.
--linas
On Tue, Oct 11, 2016 at 11:57 PM, Nil
Geisweiller
<[email protected]
<mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>>
<mailto:[email protected]
<mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>>>> wrote:
Are these unit tests still failing?
Nil
On 10/11/2016 08:36 PM, Linas
Vepstas wrote:
47 unit tests fail ... I'm
not sure if they all fail
for the same
reason, though.
For example PutLink
(PutLink
(LambdaLink
(VariableList
(TypedVariableLink
(VariableNode "$X")
(TypeNode
"PredicateNode")
)
(TypedVariableLink
(VariableNode "$Y")
(TypeNode
"PredicateNode")
)
)
(AndLink
(EvaluationLink
(PredicateNode
"acquainted")
(ListLink
(VariableNode "$X")
(VariableNode "$Y")
)
)
(ImplicationLink
(VariableNode
"$X") ; this is
alpha-converted to $foo1233
(PredicateNode
"is-human")
)
(ImplicationLink
(VariableNode "$X")
; this is
alpha-converted to $bar456
(PredicateNode
"is-human")
)
)
)
(ListLink
(PredicateNode "is-Self")
(PredicateNode "is-Bob")
)
)
So, because the implication
link is scoped, the result
of the
variable
substitution is
(AndLink
(ImplicationLink
(VariableNode "$foo123")
(PredicateNode "is-human")
)
(ImplicationLink
(VariableNode "$bar456")
(PredicateNode "is-human")
)
(EvaluationLink
(PredicateNode
"acquainted")
(ListLink
(PredicateNode "is-Self")
(PredicateNode "is-Bob")
)
)
)
which is not what the unit
test expects. The problem
with using
either
ScopeLink or LambdaLink is
that it becomes impossible
to have a
stable
variable name -- it can be
alpha-converted to anything,
so any
algo that
depends on having a fixed,
well-known variable name
will fail.
In this case -- I am not sure
-- if you want
ImplicationLink to be
scoped, then the unit test is
wrong. But is the unit
test is right,
then implication link must
not be scoped. I cannot
tell which
one is
wanted.
--linas
On Tue, Oct 11, 2016 at 12:12
PM, Nil Geisweiller
<[email protected]
<mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>>
<mailto:[email protected]
<mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>>>
<mailto:[email protected]
<mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>>
<mailto:[email protected]
<mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>>>>> wrote:
Linas,
I don't have time to get
into that right now. If
you can
point to
where exactly it breaks
(like a unit test on your
branch)
it would
help. In any case I look
carefully into that and
reply
tomorrow.
Nil
On 10/11/2016 06:55 PM,
Linas Vepstas wrote:
You made it inherit
from ScopeLink, thus
making the
variables in it
implicitly scoped.
Then you added the file
ImplicationLink.cc,
and have
notes in there,
complaining about how
variables are
implcitly
scoped.
The wiki page for it,
http://wiki.opencog.org/w/ImplicationLink
<http://wiki.opencog.org/w/ImplicationLink>
<http://wiki.opencog.org/w/ImplicationLink
<http://wiki.opencog.org/w/ImplicationLink>>
<http://wiki.opencog.org/w/ImplicationLink
<http://wiki.opencog.org/w/ImplicationLink>
<http://wiki.opencog.org/w/ImplicationLink
<http://wiki.opencog.org/w/ImplicationLink>>>
<http://wiki.opencog.org/w/ImplicationLink
<http://wiki.opencog.org/w/ImplicationLink>
<http://wiki.opencog.org/w/ImplicationLink
<http://wiki.opencog.org/w/ImplicationLink>>
<http://wiki.opencog.org/w/ImplicationLink
<http://wiki.opencog.org/w/ImplicationLink>
<http://wiki.opencog.org/w/ImplicationLink
<http://wiki.opencog.org/w/ImplicationLink>>>> still
says things that are
wrong (re alpha
conversion -- each
lambda gets
alpha converted, so
the "sugar syntax" section
cannot
possibly
be right).
I'm asking, because
I'm trying to fix #910 by
doing the
alpha
conversion
correctly, and the
result of the fix is that
unit tests
with
implication
links in them now
fail. The whole thing
smells bad.
Either
ImplicationLinks do inherit from
ScopeLink, in which
case, there
should be no
complaints about how the
ScopeLink works:
it does
the right
thing. If you don't
like what the scopeLink
does, then
ImplicationLinks
should NOT inherit
from it ...
In either case, the
wiki page needs fixing,
because the
alpha
conversion
conversation we had
recently renders that page
incoherent.
I don't really care,
one way or the other, but
I do need to
understand
the intended design
well enough to be able to
fix bugs, and
right now, I
don't understand
what ImplicationLink is, or
how its
supposed to
work.
--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 [email protected]
<mailto:opencog%[email protected]>.
To post to this group, send email to
[email protected] <mailto:[email protected]>.
Visit this group at
https://groups.google.com/group/opencog
<https://groups.google.com/group/opencog>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/opencog/CAHrUA35RygO2MWjZJ2MfEA2TCvBC8kjvFDVvj2-CNmqP2e9PLQ%40mail.gmail.com
<https://groups.google.com/d/msgid/opencog/CAHrUA35RygO2MWjZJ2MfEA2TCvBC8kjvFDVvj2-CNmqP2e9PLQ%40mail.gmail.com>.
For more options, visit
https://groups.google.com/d/optout
<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 [email protected]
<mailto:opencog%[email protected]>.
To post to this group, send email to [email protected]
<mailto:[email protected]>.
Visit this group at https://groups.google.com/group/opencog
<https://groups.google.com/group/opencog>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/opencog/57FF2210.9090304%40gmail.com
<https://groups.google.com/d/msgid/opencog/57FF2210.9090304%40gmail.com>.
For more options, visit https://groups.google.com/d/optout
<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 [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/opencog.
To view this discussion on the web visit
https://groups.google.com/d/msgid/opencog/58046BE4.7090000%40gmail.com.
For more options, visit https://groups.google.com/d/optout.
