Oh, my query was idiotic, $P and $Q wouldn't be typed PredicateNode, I
meant something like EvaluationLink as to let a change to have the
variables appear in them.
Nil
On 11/16/2016 07:56 PM, Linas Vepstas wrote:
Ah, the exception was due to a bug in the original email. After fixing
that, it the code works just fine, I don't see what the problem is. Cut
n paste of the works-for-me version below.
--linas
(use-modules (opencog) (opencog query) (opencog exec))
(define g
(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")))))
;; except to find this
(ImplicationScope
(TypedVariableLink
(VariableNode "vvv")
(TypeNode "ConceptNode")
)
(PredicateNode "ppp")
(PredicateNode "qqq"))
(cog-execute! g)
;; returns the expected result. What is the problem?
On Wed, Nov 16, 2016 at 11:49 AM, Linas Vepstas <linasveps...@gmail.com
<mailto:linasveps...@gmail.com>> wrote:
On Wed, Nov 16, 2016 at 5:34 AM, 'Nil Geisweiller' via opencog
<opencog@googlegroups.com <mailto:opencog@googlegroups.com>> 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
<opencog@googlegroups.com <mailto:opencog@googlegroups.com>>
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 opencog+unsubscr...@googlegroups.com
<mailto:opencog%2bunsubscr...@googlegroups.com>.
To post to this group, send email to
opencog@googlegroups.com <mailto:opencog@googlegroups.com>.
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 opencog+unsubscr...@googlegroups.com
<mailto:opencog%2bunsubscr...@googlegroups.com>.
To post to this group, send email to opencog@googlegroups.com
<mailto:opencog@googlegroups.com>.
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>.
--
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 opencog+unsubscr...@googlegroups.com
<mailto:opencog+unsubscr...@googlegroups.com>.
To post to this group, send email to opencog@googlegroups.com
<mailto:opencog@googlegroups.com>.
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/CAHrUA36wu5Kv7PtyCPn2crbsqyu8C3rgMR49_nqLLgYSFZ4TCg%40mail.gmail.com
<https://groups.google.com/d/msgid/opencog/CAHrUA36wu5Kv7PtyCPn2crbsqyu8C3rgMR49_nqLLgYSFZ4TCg%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 opencog+unsubscr...@googlegroups.com.
To post to this group, send email to opencog@googlegroups.com.
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/96d70af7-aabe-26cb-b8c4-eaaaadc93b70%40gmail.com.
For more options, visit https://groups.google.com/d/optout.
