On Wed, Nov 16, 2016 at 5:34 AM, 'Nil Geisweiller' via opencog <
[email protected]> 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.
Well, no, it throws an error:
ERROR: Throw to key `C++-EXCEPTION' with args `("cog-new-link" "Expected a
VariableNode or a TypedVariableLink, got: LocalQuoteLink
(/home/linas/src/novamente/src/atomspace-git/opencog/atoms/core/VariableList.cc:61)")'.
That's with a pull from just now.
anyway, it is designed to fetch ImplicationScopeLinks that are
ill-formed. It's declared to find links like this:
(ImplicationScope
(TypedVariableLink
(TypeNode "ConceptNode")
(VariableNode "vvv"))
(PredicateNode "pa")
(PredicateNode "qa"))
the variable never appears anywhere. Its -- well, the variable can be
completely discarded, and you'd get an equivalent ImplicationScope that
does not have any variables in it.
> 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.
>
? I don't understand what you're saying. Why would it be "invalid"? Is
there a bug? What do you mean by "happens to be alpha-equivalent"? It is,
by definition, alpha-equivalent to an infinite number of other links.
>
> Indeed alpha-conversion shouldn't be triggered in that case,
In which case? Alpha conversion of what?
> the right idea is that the ImplicationScope, when quoted corresponds to a
> DIFFERENT atom than the one not being quoted.
Can you clarify?
> Also of course if we decide to not perform systematic alpha-conversion
> then this problem doesn't arise.
>
You want to eliminate ScopeLink and Lambda Link ? That's a very serious
change.
>
> I'm re-iterating my question. Do we really want automatic alpha-conversion
> to begin with?
>
What do you mean when you say "automatic"? Either there is alpha
conversion, or there is not. What else can it be?
>
> If the answer is yes then I suppose we need a way to tell that the quoted
> version is different than then unquoted version.
>
what is different from what? A better example is needed.
--linas
>
> 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/582C444E.4030706%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/CAHrUA346PCysGNzcgwgA3ugvgnACGbgrD7A5PLJ97mw41Fg_4Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
