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..
On Nov 17, 2016 3:54 PM, "'Nil Geisweiller' via opencog" < [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]>> 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]>> 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]>> >> 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]>. >> >>> 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/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>. >> >> >> >> >> >> >> >> >> > >> > -- >> > 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/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>. >> >> >> >> -- >> 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]>. >> 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/CACYTDBfsGxXbowYox >> Ee0zeqcBmabJXUyqG0dTy%2B1-MmO7sGfHA%40mail.gmail.com >> <https://groups.google.com/d/msgid/opencog/CACYTDBfsGxXbowYo >> xEe0zeqcBmabJXUyqG0dTy%2B1-MmO7sGfHA%40mail.gmail.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/CAHrUA35ACzeiX-KYn >> drdW28ZoCBXFEG34qmJN3dpwS9Ht4L1Gw%40mail.gmail.com >> <https://groups.google.com/d/msgid/opencog/CAHrUA35ACzeiX-KY >> ndrdW28ZoCBXFEG34qmJN3dpwS9Ht4L1Gw%40mail.gmail.com?utm_medi >> um=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/ms > gid/opencog/d54abf5e-73a1-7837-a4af-7cbd36af21cd%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/CACYTDBfyAZELNnhMjbxqUcj9%3Dq2Uej-qVGuujezQwNU-%3D0yNqQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
