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?
On Wed, Oct 12, 2016 at 4:08 PM, Linas Vepstas <linasveps...@gmail.com> wrote: > > > On Wed, Oct 12, 2016 at 12:53 PM, Nil Geisweiller <ngeis...@googlemail.com> > 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 >>> <ngeis...@googlemail.com <mailto:ngeis...@googlemail.com>> 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 >>> <ngeis...@googlemail.com <mailto:ngeis...@googlemail.com> >>> <mailto:ngeis...@googlemail.com >>> <mailto:ngeis...@googlemail.com>>> 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 >>> <ngeis...@googlemail.com >>> <mailto:ngeis...@googlemail.com> <mailto:ngeis...@googlemail.com >>> <mailto:ngeis...@googlemail.com>> >>> <mailto:ngeis...@googlemail.com >>> <mailto:ngeis...@googlemail.com> >>> >>> <mailto:ngeis...@googlemail.com >>> <mailto:ngeis...@googlemail.com>>>> 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>>> 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 opencog+unsubscr...@googlegroups.com. > To post to this group, send email to opencog@googlegroups.com. > Visit this group at https://groups.google.com/group/opencog. > To view this discussion on the web visit > https://groups.google.com/d/msgid/opencog/CAHrUA35RygO2MWjZJ2MfEA2TCvBC8kjvFDVvj2-CNmqP2e9PLQ%40mail.gmail.com. > > For more options, visit https://groups.google.com/d/optout. -- Ben Goertzel, PhD http://goertzel.org Super-benevolent super-intelligence is the thought the Global Brain is currently struggling to form... -- You received this message because you are subscribed to the Google Groups "opencog" group. To unsubscribe from this group and stop receiving emails from it, send an email to opencog+unsubscr...@googlegroups.com. To post to this group, send email to opencog@googlegroups.com. Visit this group at https://groups.google.com/group/opencog. To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/CACYTDBe%3DzQ2XZ1HxtUfujgB_LvRFmig7eia_KOxh8dSZsLSn3A%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
