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.



-- 
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 [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/CACYTDBenW9A10kjH%3Ds%2Bmkk-rR9gwP5eWEtOcmnCZzip%3DNXTjcA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to