Can you open a bug report for this? What I see there should work, and I
have a pretty good idea why it doesn't -- its a design flaw/oversight, I
never really thought that something like this would be searched for.
> I feel it might be risky to ask the pattern matcher to guess groundable
clauses from evaluatable ones, but I haven't deeply thought about it.
Yes but no. Consider this:
(EvaluationLink
(GroundedPredicateNode \"scm: true-enough\")
(InheritanceLink
(VariableNode \"$A\")
(VariableNode \"$B\")))
The only way that scm: true-enough could ever be invoked is if
(InheritanceLink
(VariableNode \"$A\")
(VariableNode \"$B\"))
was groundable. Ergo, the InhLink should be findable in the atomspace.
This is somewhat subtle.. Normally, the way that multiple args are passed
to scm is to wrap them in a ListLink, but you did not do that. Thus,
scm:true-enough takes one arg, which is a single inh link.
I guess its somewhat subtle: when the pattern matcher hits an
EvaluationLink, should it create the arguments, if they do not yet exist
(which is what it does now), or should it assume that they already exist
(which is what I am advocating)?
My gut intuition says that the search-part of a clause should never create
atoms, since creating something kind-of violates the core idea of "just
searching". And so that implies that the InhLink can't be created, ergo,
it must be findable.
Otherwise, searching has side-effects. I guess we can avoid those
side-effects by creating arguments in a temp atomspace (which is kind-of
what is done now...) My gut instinct is that searching should not have
side-effects of creating new atoms...
.... interesting.
--linas
On Thu, Oct 26, 2017 at 12:24 AM, Nil Geisweiller <[email protected]>
wrote:
> Hi Linas,
>
> On 10/25/2017 10:12 PM, Linas Vepstas wrote:
>
>> Does it still work correctly/quickly if you just cut out the
>> inheritance link entirely?
>>
>
> No it doesn't. For instance if I remove AB, BC from
>
> https://github.com/opencog/atomspace/blob/master/tests/rule-
> engine/rules/bc-deduction-rule.scm#L25
>
> then I get the following message
>
> ERROR: Throw to key `C++-EXCEPTION' with args `("cog-new-link" "Variable
> not groundable: (VariableNode \"$A\") ; [2173103626934298135][1]
>
> (/home/nilg/OpenCog/atomspace/opencog/atoms/pattern/PatternLink.cc:853)
> Function args:
> ((VariableList
> (TypedVariableLink
> (VariableNode \"$A\")
> (TypeNode \"ConceptNode\")
> )
> (TypedVariableLink
> (VariableNode \"$B\")
> (TypeNode \"ConceptNode\")
> )
> (TypedVariableLink
> (VariableNode \"$C\")
> (TypeNode \"ConceptNode\")
> )
> )
> (AndLink
> (EvaluationLink
> (GroundedPredicateNode \"scm: true-enough\")
> (InheritanceLink
> (VariableNode \"$A\")
> (VariableNode \"$B\")
> )
> )
> (NotLink
> (IdenticalLink
> (VariableNode \"$A\")
> (VariableNode \"$C\")
> )
> )
> (EvaluationLink
> (GroundedPredicateNode \"scm: true-enough\")
> (InheritanceLink
> (VariableNode \"$B\")
> (VariableNode \"$C\")
> )
> )
> )
> (ExecutionOutputLink
> (GroundedSchemaNode \"scm: bc-deduction-formula\")
> (ListLink
> (InheritanceLink
> (VariableNode \"$A\")
> (VariableNode \"$C\")
> )
> (InheritanceLink
> (VariableNode \"$A\")
> (VariableNode \"$B\")
> )
> (InheritanceLink
> (VariableNode \"$B\")
> (VariableNode \"$C\")
> )
> )
> )
> )")'.
>
> I feel it might be risky to ask the pattern matcher to guess groundable
> clauses from evaluatable ones, but I haven't deeply thought about it.
>
> Nil
>
>
>>
>> I'll try.
>>
>>
>> Cool. OK, it should work. If not, open a new bug report.
>>
>> Its possible that it works, but more slowly. If so, that is also a bug...
>>
>> --linas
>>
>> Thanks.
>>
>> Nil
>>
>>
>>
>> On Wed, Oct 25, 2017 at 12:42 PM, Nil Geisweiller
>> <[email protected] <mailto:[email protected]>
>> <mailto:[email protected]
>>
>> <mailto:[email protected]>>> wrote:
>>
>> Thanks for your feedback Linas, I'll look into that. As for
>> repeating the clause, wrapping it in a true-enough
>> predicate, yes it
>> speeds up reasoning as it prevents producing uninformative
>> knowledge, that would otherwise propagate.
>>
>> Nil
>>
>> On 10/25/2017 08:11 PM, Linas Vepstas wrote:
>>
>> Nil,
>>
>> In the blog post bind-link, you've got repeated elements:
>>
>> |(EvaluationLink (GroundedPredicateNode "scm:
>> true-enough") ;
>> [4909279237071103651][1] (InheritanceLink (VariableNode
>> "$B-6266d6f2") ; [4097372290580364298][6] (VariableNode
>> "$B-6229393a") ; [6185394777777469381][6] ) ;
>> [12731261225409633207][6] ) ; [10287726414730683768][6]|
>>
>> and also this:
>>
>> |(InheritanceLink (VariableNode "$B-6266d6f2") ;
>> [4097372290580364298][6] (VariableNode "$B-6229393a") ;
>> [6185394777777469381][6] ) ; [12731261225409633207][6]|
>>
>>
>> You don't need both of these; the EvaluationLink should
>> be
>> enough. Is it not enough? Does it run faster if you
>> give both? If so, its a bug...
>>
>> It occurs to me that, given how the pattern matcher is
>> designed,
>> there could be an optimization done for clauses that
>> have GPN's
>> in them... these might not be being handled efficiently.
>>
>> --linas
>>
>> -- /"The problem is not that artificial
>> intelligence will get too
>> smart and take over the world," computer scientist Pedro
>> Domingos writes, "the problem is that it's too stupid and
>> already has." /
>>
>>
>>
>>
>> -- /"The problem is not that artificial intelligence will
>> get too
>> smart and take over the world," computer scientist Pedro
>> Domingos writes, "the problem is that it's too stupid and
>> already has." /
>>
>>
>>
>>
>> --
>> /"The problem is not that artificial intelligence will get too smart and
>> take over the world," computer scientist Pedro Domingos writes, "the
>> problem is that it's too stupid and already has." /
>>
>
--
*"The problem is not that artificial intelligence will get too smart and
take over the world," computer scientist Pedro Domingos writes, "the
problem is that it's too stupid and already has." *
--
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/CAHrUA34H19BK4Z3Ns3BG6tiz--QFn%3DWnMn8A6vYs2ELxwEDG3g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
