On 11/17/2016 09:09 AM, Ben Goertzel wrote:
I think our conclusion in 2015 was that processes like the chainer
should do alpha conversion on the fly... so we should supply a utility
function making it easy for anyone to invoke alpha conversion in a
particular set of atoms..

The URE does alpha-conversion whenever necessary as to avoid name capture, there's no problem here. The problem comes from the fact that the atomspace may silently perform alpha-conversion when a scope link is added, ultimately there are solutions to address any problem resulting from such implicit conversions, but I can't help it, there's a part of me that feels ambivalent about it...

Anyway, I'll open a github issue whenever I encounter the problem I'm trying to describe in real life situation.

Nil



On Nov 17, 2016 3:54 PM, "'Nil Geisweiller' via opencog"
<[email protected] <mailto:[email protected]>> wrote:

    The reason I didn't want to open a bug report just yet is because I
    wanted to discuss whether we really want to check alpha-equivalence
    whenever a new scope link is added to the atomspace (and
    subsequently consider both equal and return the previous one to the
    user).

    Nil

    On 11/17/2016 05:13 AM, Linas Vepstas wrote:

        Look, if there is a bug, open a bug report. I'm nervous about
        these kind
        of blanket statements about what's best and what is not best.  The
        atomspace is already complicated, adding more complexity to it
        is not a
        solution.

        --linas

        On Wed, Nov 16, 2016 at 8:27 PM, Ben Goertzel <[email protected]
        <mailto:[email protected]>
        <mailto:[email protected] <mailto:[email protected]>>> wrote:

            Nil,

            I just reviewed our dialogue on this from a year ago...

            It seems what we provisionally concluded there was that the
        chainer
            should do alpha-conversion on the fly in the course of pattern
            matching ... but that the Atomspace shouldn't do
        alpha-conversion
            "automatically" in any other sense [unless we want to add
        some Reduct
            type engine on the Atomspace, which could do
        alpha-conversion along
            with other normalizations, but that becomes a separate issue]

            We also discussed a cog-new-var command that could be used
        to minimize
            the complexities of alpha-conversions... (via reducing the
        incidence
            of redundant variable names)

            In this case, the alpha-conversion done by the chainer in
        the course
            of doing its business, would need to handle LocalQuoteLink
            correctly...

            The choice of the chainer to do alpha-conversion but not
        (yet) more
            general types of reduction, would be made because
        alpha-conversion is
            cheaper and easier and of such broad utility.   Later
        versions of the
            chainer might do more general reductions as part of their
        ordinary
            business, as well...

            I may be missing something; a year ago when William and I
        were talking
            about this, my head was fully immersed in the problem, but
        it's less
            the case right now...

            -- Ben




            On Wed, Nov 16, 2016 at 8:34 PM, 'Nil Geisweiller' via opencog
            <[email protected] <mailto:[email protected]>
        <mailto:[email protected]
        <mailto:[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.
            >
            > 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]
        <mailto:[email protected]>
        <mailto:[email protected]
        <mailto:[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]
        <mailto:opencog%[email protected]>
            <mailto:opencog%[email protected]
        <mailto:opencog%[email protected]>>.
            >>> To post to this group, send email to
        [email protected] <mailto:[email protected]>
            <mailto:[email protected]
        <mailto:[email protected]>>.
            >>> Visit this group at
        https://groups.google.com/group/opencog
        <https://groups.google.com/group/opencog>
            <https://groups.google.com/group/opencog
        <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
        <https://groups.google.com/d/msgid/opencog/580A3A75.1020708%40gmail.com>

        <https://groups.google.com/d/msgid/opencog/580A3A75.1020708%40gmail.com
        
<https://groups.google.com/d/msgid/opencog/580A3A75.1020708%40gmail.com>>.
            >>> For more options, visit
        https://groups.google.com/d/optout
        <https://groups.google.com/d/optout>
            <https://groups.google.com/d/optout
        <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]
        <mailto:opencog%[email protected]>
            <mailto:opencog%[email protected]
        <mailto:opencog%[email protected]>>.
            > To post to this group, send email to
        [email protected] <mailto:[email protected]>
            <mailto:[email protected]
        <mailto:[email protected]>>.
            > Visit this group at
        https://groups.google.com/group/opencog
        <https://groups.google.com/group/opencog>
            <https://groups.google.com/group/opencog
        <https://groups.google.com/group/opencog>>.
            > To view this discussion on the web visit
            >

        https://groups.google.com/d/msgid/opencog/582C444E.4030706%40gmail.com
        <https://groups.google.com/d/msgid/opencog/582C444E.4030706%40gmail.com>

        <https://groups.google.com/d/msgid/opencog/582C444E.4030706%40gmail.com
        
<https://groups.google.com/d/msgid/opencog/582C444E.4030706%40gmail.com>>.
            >
            > For more options, visit https://groups.google.com/d/optout
        <https://groups.google.com/d/optout>
            <https://groups.google.com/d/optout
        <https://groups.google.com/d/optout>>.



            --
            Ben Goertzel, PhD
            http://goertzel.org

            “I tell my students, when you go to these meetings, see what
        direction
            everyone is headed, so you can go in the opposite direction.
        Don’t
            polish the brass on the bandwagon.” – V. S. Ramachandran

            --
            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]
        <mailto:opencog%[email protected]>
            <mailto:opencog%[email protected]
        <mailto:opencog%[email protected]>>.
            To post to this group, send email to
        [email protected] <mailto:[email protected]>
            <mailto:[email protected]
        <mailto:[email protected]>>.
            Visit this group at https://groups.google.com/group/opencog
        <https://groups.google.com/group/opencog>
            <https://groups.google.com/group/opencog
        <https://groups.google.com/group/opencog>>.
            To view this discussion on the web visit

        
https://groups.google.com/d/msgid/opencog/CACYTDBfsGxXbowYoxEe0zeqcBmabJXUyqG0dTy%2B1-MmO7sGfHA%40mail.gmail.com
        
<https://groups.google.com/d/msgid/opencog/CACYTDBfsGxXbowYoxEe0zeqcBmabJXUyqG0dTy%2B1-MmO7sGfHA%40mail.gmail.com>

        
<https://groups.google.com/d/msgid/opencog/CACYTDBfsGxXbowYoxEe0zeqcBmabJXUyqG0dTy%2B1-MmO7sGfHA%40mail.gmail.com
        
<https://groups.google.com/d/msgid/opencog/CACYTDBfsGxXbowYoxEe0zeqcBmabJXUyqG0dTy%2B1-MmO7sGfHA%40mail.gmail.com>>.
            For more options, visit https://groups.google.com/d/optout
        <https://groups.google.com/d/optout>
            <https://groups.google.com/d/optout
        <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]
        <mailto:opencog%[email protected]>
        <mailto:[email protected]
        <mailto:opencog%[email protected]>>.
        To post to this group, send email to [email protected]
        <mailto:[email protected]>
        <mailto:[email protected] <mailto:[email protected]>>.
        Visit this group at https://groups.google.com/group/opencog
        <https://groups.google.com/group/opencog>.
        To view this discussion on the web visit
        
https://groups.google.com/d/msgid/opencog/CAHrUA35ACzeiX-KYndrdW28ZoCBXFEG34qmJN3dpwS9Ht4L1Gw%40mail.gmail.com
        
<https://groups.google.com/d/msgid/opencog/CAHrUA35ACzeiX-KYndrdW28ZoCBXFEG34qmJN3dpwS9Ht4L1Gw%40mail.gmail.com>
        
<https://groups.google.com/d/msgid/opencog/CAHrUA35ACzeiX-KYndrdW28ZoCBXFEG34qmJN3dpwS9Ht4L1Gw%40mail.gmail.com?utm_medium=email&utm_source=footer
        
<https://groups.google.com/d/msgid/opencog/CAHrUA35ACzeiX-KYndrdW28ZoCBXFEG34qmJN3dpwS9Ht4L1Gw%40mail.gmail.com?utm_medium=email&utm_source=footer>>.
        For more options, visit https://groups.google.com/d/optout
        <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]
    <mailto:opencog%[email protected]>.
    To post to this group, send email to [email protected]
    <mailto:[email protected]>.
    Visit this group at https://groups.google.com/group/opencog
    <https://groups.google.com/group/opencog>.
    To view this discussion on the web visit
    
https://groups.google.com/d/msgid/opencog/d54abf5e-73a1-7837-a4af-7cbd36af21cd%40gmail.com
    
<https://groups.google.com/d/msgid/opencog/d54abf5e-73a1-7837-a4af-7cbd36af21cd%40gmail.com>.
    For more options, visit https://groups.google.com/d/optout
    <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]
<mailto:[email protected]>.
To post to this group, send email to [email protected]
<mailto:[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/CACYTDBfyAZELNnhMjbxqUcj9%3Dq2Uej-qVGuujezQwNU-%3D0yNqQ%40mail.gmail.com
<https://groups.google.com/d/msgid/opencog/CACYTDBfyAZELNnhMjbxqUcj9%3Dq2Uej-qVGuujezQwNU-%3D0yNqQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.
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/f589bc5c-c39e-e40c-bdd2-6eefea9ec954%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to