Too ugly... More later...
On Nov 16, 2016 8:43 PM, "'Nil Geisweiller' via opencog" < [email protected]> wrote: > Another option would be to defined quoted atom types corresponding to all > scope links, like > > QuotedImplicationScopeLink > > Or > > ImplicationScopeLocalQuoteLink > > which would inherit a LocalQuoteLink. > > It has the advantage of being compact, unambiguous and circumvent the > alpha-conversion issue altogether. > > What do you think? > > Nil > > On 11/16/2016 01:34 PM, Nil Geisweiller wrote: > >> I'm back to this issue. >> >> The notion of LocalQuote is indeed incompatible with systematic >> alpha-conversion. >> >> Consider this pattern >> >> (Get >> (VariableList >> (TypedVariable >> (Variable "$X") >> (Type "TypedVariableLink")) >> (TypedVariable >> (Variable "$P") >> (Type "PredicateNode")) >> (TypedVariable >> (Variable "$Q") >> (Type "PredicateNode")) >> (LocalQuote >> (ImplicationScope >> (Variable "$X") >> (Variable "$P") >> (Variable "$Q")))) >> >> This fetches ImplicationScope links. >> >> If the following >> >> (ImplicationScope >> (Variable "$X") >> (Variable "$P") >> (Variable "$Q")) >> >> happen to be alpha-equivalent to something with different variable names >> it will render the Bind link invalid. >> >> Indeed alpha-conversion shouldn't be triggered in that case, the right >> idea is that the ImplicationScope, when quoted corresponds to a >> DIFFERENT atom than the one not being quoted. Also of course if we >> decide to not perform systematic alpha-conversion then this problem >> doesn't arise. >> >> I'm re-iterating my question. Do we really want automatic >> alpha-conversion to begin with? >> >> If the answer is yes then I suppose we need a way to tell that the >> quoted version is different than then unquoted version. >> >> Nil >> >> On 10/22/2016 03:34 AM, Ben Goertzel wrote: >> >>> Nil, >>> >>> Just brainstorming here, but perhaps the command for adding an Atom >>> should have an option that the user can set, which determines whether >>> the results would be alpha-converted or not >>> >>> The default would be to do the alpha-conversion (which would be >>> appropriate if the variable names are say randomly generated, and thus >>> of no particular importance to the user -- the alpha conversion is >>> then just preventing odd collisions between randomly generated >>> variable names created by two different processes) >>> >>> However, if the user wants they can override this default and specify >>> "no alpha conversion", and then it is their responsibility to check >>> and be sure their chosen VariableNode names are not going to be used >>> in a way that creates some conflict ... >>> >>> This option would need to be added to Scheme, python, Haskell >>> bindings, but also to the core API for adding scoped links, I guess... >>> >>> I am only about 83.456% sure I understand the problem here... >>> >>> -- Ben >>> >>> >>> >>> On Fri, Oct 21, 2016 at 11:55 PM, 'Nil Geisweiller' via opencog >>> <[email protected]> wrote: >>> >>>> Hi, >>>> >>>> I start to think that automatic alpha-conversion is evil. >>>> >>>> First let me recall what it does. Say you've added >>>> >>>> (Scope (VariableList (Variable "$X") (Variable "$Y")) >>>> (And (Variable "$X") (Variable "$Y"))) >>>> >>>> and you subsequently add >>>> >>>> (Scope (And (Variable "$gold") (Variable "$silver"))) >>>> >>>> then recalling the handle of that last addition, you'd get the first >>>> alpha-equivalent scope, which is >>>> >>>> (Scope (VariableList (Variable "$X") (Variable "$Y")) >>>> (And (Variable "$X") (Variable "$Y"))) >>>> >>>> This is rather confusing to the user, but even worse the pattern matcher >>>> behaves differently with the former or the latter. If you use the >>>> former to >>>> match grounds containing variables "$X" and "$Y" it may not work due >>>> to the >>>> pattern matcher discarding self-matches. The latter would match >>>> UNLESS the >>>> former has been previously added, because the variables "$gold" and >>>> "$silver" would be silently replaced by "$X" and "$Y". This is horribly >>>> confusing to the user! >>>> >>>> Second, it seems rather arbitrary to try to detect this kind of >>>> equivalence >>>> while there's an infinity of others. For instance >>>> >>>> (And (Variable "$X") (And (Variable "$Y")) >>>> >>>> is equivalent to >>>> >>>> (And (Variable "$X") (Variable "$Y")) >>>> >>>> For these reasons I think semantic equivalence detection shouldn't be >>>> incorporated into the AtomSpace. The AtomSpace should take care of the >>>> syntax only (OK, with the exception of unordered links), as it's always >>>> been, and this task should differed to another process working above the >>>> AtomSpace. >>>> >>>> It was suggested a while ago to have a normal form reduction engine >>>> for the >>>> AtomSpace, similar to MOSES', and such an engine could be used to reduce >>>> while adding atoms, if the user chooses so. This is a much cleaner >>>> way to >>>> handle that. Also since semantic equivalence is undecidable, there will >>>> always be a battle between completeness and performance. Another >>>> reason to >>>> have this ever growing monster above the AtomSpace rather than in it. >>>> >>>> OK, I don't know if I've convinced you, or even if I've convinced >>>> myself, >>>> but it's really a discussion we need to have. >>>> >>>> Opinions welcome. >>>> >>>> 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 [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/580A3A75.1020708%40gmail.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 [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/ms > gid/opencog/582C4675.9050308%40gmail.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 [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/CACYTDBecsE5f98o-ru%2BZf52WL6_-UyJCmLzP%3DsgkKwwZntpNsg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
