Closed misgeatgit closed 4 years ago
It seems we need to categorize such rules in a special way.
What do you mean categorize in a special way?
On the surface, I only saw the need to not match an InheritanceLink against itself, in order to avoid all those duplicate AndLink...
@williampma cog-bind is creating the links its told to create. And the rule engine is selecting rules stochastically(not checking link type..etc) and pass it to the pattern matcher/cogbind. By special cases I mean, categorizing rules into different classes, like generic once which can be applied on every kind of atoms and special once which are handled by special callback handlers. What am saying is we need a robust way of rule selection once candidate rules that match with the target are found.
I think a way to deal with that is to apply reduction to those hypergraphs, in order to remove the redundant semantically equivalent hypergraphs from the results.
I should precise that we don't have such a reduct library for hypergraph yet, only for combo.
@bgoertzel your opinion here?
IF I understand correctly, it seems that, as William says, the issue here is that we want to tell some rules not to apply to duplicate arguments...
So if we have
Inheritance A D Inheritance B D
we may want to form
Inheritance (AND A B) D
but we don't want to waste time going from
Inheritance A D Inheritance A D
to
Inheritance (AND A A) D
because this is boring...
Reduction, as Nil suggests, seems not to solve the problem because it would just reduce
Inheritance (AND A A) D
to
Inheritance A D
after the formation of the former, whereas we want to prevent the formation of the former in the first place...
It seems we want to be able to specify that a rule taking 2 Atoms as arguments, is only applied to "2 distinct Atoms" as arguments....
Before exploring how to solve this problem in the code, I want to be sure this is actually the problem that needs solving though...
-- Ben
On Wed, Mar 18, 2015 at 11:43 PM, Misgana Bayetta notifications@github.com wrote:
@bgoertzel https://github.com/bgoertzel your opinion here?
— Reply to this email directly or view it on GitHub https://github.com/opencog/opencog/issues/1431#issuecomment-83026849.
Ben Goertzel, PhD http://goertzel.org
"The reasonable man adapts himself to the world: the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man." -- George Bernard Shaw
I'm not sure I understand the problem. However, if you have $variable-one and $variable-two and want to make sure that they are not both grounded by the same atom, you could solve it in two different ways: one way is t return false_tv if the two vars are identical:
(EvaluationLink
(GroundedPredicateNode "scm: (lambda (a b) (if (equal? a b) false_tv else true_tv)))" )
(ListLink (VariableNode $a) (VariableNode $b))))
but that could possible run slowly. a higher-performance fix is to write a special callback to reject duplicate groundings.This list of current groundings is known to the pattern matcher .. just scane that list...
A third fix, is to do something similar to what the evaluation-to-member rule is heading toward in a current pull request:
Instead of creating the new link in the BindLink implicand, do it in the helper function called by the GroundedSchemaNode. Then the helper function can check if the two nodes are the same before creating the new AndLink.
@williampma that looks a nice and easy way.
Yes, better avoid to produce useless cases than using reduct.
BTW, it seems to me the other problem, beside considering the same match for the 2 clauses, the results are also use, so the process is feeding on itself, I don't how to explain that otherwise:
(InheritanceLink
(ConceptNode "Frog" (stv 0.0099999998 0.111111))
(AndLink
(ConceptNode "Slimy" (stv 0.0099999998 0.111111))
(AndLink
(ConceptNode "Intelligent" (stv 0.050000001 0.111111))
(ConceptNode "Animal" (stv 0.1 0.111111))
)
)
)
I do remember that this is potential problem when not using virtual clauses.
I however don't understand why it doesn't go on forever.
So whats the verdict here? Should we modify those rules to work only on distinct atoms or handle it from the c++ code? Modifying the rules seems the right way since we don't want to always add new exceptions to the c++ code whenever there is new special case. Handling this kind of cases from with in the rules prevents that from happening.
No conclusion yet as most solutions will interfere with Backward Chaining.
https://groups.google.com/forum/#!topic/opencog/ZeK1mZgXoo8 https://github.com/opencog/opencog/issues/1441
is this still an issue?
Maybe, I'd rather not spend time on it ATM, even testing. We can let it open for now.
This is old, big and must be terminated.
I am confused with application of this https://github.com/opencog/opencog/blob/master/opencog/reasoning/RuleEngine/rules/pln/contextualize.scm#L214