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]> 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]> 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/msgid/opencog/582C444E.4030706%40gmail.com. > > > > For more options, visit 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]. > 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/CACYTDBfsGxXbowYoxEe0zeqcBmabJXUyqG0dTy%2B1-MmO7sGfHA% > 40mail.gmail.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/CAHrUA35ACzeiX-KYndrdW28ZoCBXFEG34qmJN3dpwS9Ht4L1Gw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
