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.
