Logical insert and cyclic rules dependences

[zephyr]

I want to use "magick" of logical insert to keep dynamically changing inferred facts up to date. The problem are cyclic dependences:

"a -> b" means "when a than insertLogical( new b()) end"

a -> b
b -> c
c -> b

when i insert "a" b and c are correctly inferred (they check equals so it doesnt loop)
but when i remove a they persist, as they make they're rules active because ot the cycle

is there a good way to remove such logical facts not supported by inserted data?

[zephyr]

zephyr wrote

I want to use "magick" of logical insert to keep dynamically changing inferred facts up to date. The problem are cyclic dependences:

"a -> b" means "when a than insertLogical( new b()) end"

a -> b
b -> c
c -> b

when i insert "a" b and c are correctly inferred (they check equals so it doesnt loop)
but when i remove a they persist, as they make they're rules active because ot the cycle

is there a good way to remove such logical facts not supported by inserted data?

I thought maybe if next reference didnt increase the counter but instead waited on some data structure, then after a fact and its implications are removed those facts with counter 0 could see wheather there are any rules still referencing them. As only one points at a time this should remove cycles that stay after node is removed, but im not 100% shure it would work, it can undo and insert again some facts [in my case its not that bad, but as a general solution seems bad] and probably i would have to edit drools files.

Hmm maybe there is some kind of better way to deal with this.

[Ansgar Konermann]

Am 02.07.2012 15:29, schrieb zephyr:

> zephyr wrote
>> I want to use "magick" of logical insert to keep dynamically changing
>> inferred facts up to date. The problem are cyclic dependences:
>>
>> "a -> b" means "when a than insertLogical( new b()) end"
>>
>> a -> b
>> b -> c
>> c -> b
>>
>> when i insert "a" b and c are correctly inferred (they check equals so it
>> doesnt loop)
>> but when i remove a they persist, as they make they're rules active
>> because ot the cycle
>>
>> is there a good way to remove such logical facts not supported by inserted
>> data?
>>
> [...]
>
> Hmm maybe there is some kind of better way to deal with this.

b -> c
c -> b

in other words: b and c are logically equivalent.

You can remove one of your symbols b or c and just work with the
remaining one. b and c will always have the same truth value (true/false).

If this does not help, please let me know a bit more about your use case.

Best regards

Ansgar
_______________________________________________
rules-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/rules-users

[zephyr]

In this case yes, but generally those dependences can be much more complicated and this example is the simplest ilustration of the problem.

It can also be

a-> b ->c ->d ->b

(that makes b,c,d equivalent, but is little less trivial to detect)

or more complicated
a->b
b->c
c and d -> b
d nad a are facts, then a is removed
c and b are not eqivalent, but still support each other while there is fact d
etc.

I just want logical facts that are not connected by any rule path with inserted facts and only stay because of logical fact cycles to disapear.

Im writing a system that takes user generated dependences as input and its main goal is to deal with different consequences, i thought drools might be a right tool to base this system on, this didnt work so i wonder is it a common problem and is there an easy way to deal with it (or some way to change drools to work like this).

[laune]

On 03/07/2012, zephyr <[hidden email]> wrote:
> In this case yes, but generally those dependences can be much more
> complicated and this example is the simplest ilustration of the problem.
>
> It can also be
>
> a-> b ->c ->d ->b


In this scenario, Fact b would not be inserted again, because thruth maintenance
always uses equality, irrespective of the runtime configuration
identity/equality.

Make sure to override equals and hashCode correctly, go by the book,

-W

>
> (that makes b,c,d equivalent, but is little less trivial to detect)
>
> or more complicated
> a->b
> b->c
> c and d -> b
> d nad a are facts, then a is removed
> c and b are not eqivalent, but still support each other while there is fact
> d
> etc.
>
> I just want logical facts that are not connected by any rule path with
> inserted facts and only stay because of logical fact cycles to disapear.
>
> Im writing a system that takes user generated dependences as input and its
> main goal is to deal with different consequences, i thought drools might be
> a right tool to base this system on, this didnt work so i wonder is it a
> common problem and is there an easy way to deal with it (or some way to
> change drools to work like this).
>
> --
> View this message in context:
> http://drools.46999.n3.nabble.com/Logical-insert-and-cyclic-rules-dependences-tp4018381p4018397.html
> Sent from the Drools: User forum mailing list archive at Nabble.com.
> _______________________________________________
> rules-users mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/rules-users
>

_______________________________________________
rules-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/rules-users

[zephyr]

With

"a" is the only inserted fact

a->b->c->d->b

now b,c,d are logically added, b's ref cnt is 2

Fact b is NOT inserted again, (it's ref cnt is increased) and its more or less what i wanted.

The problem is, when i remove fact a, b's ref cnt goes to 1, so it stays.

So b,c,d stay in fact memory because they support each other, even though all stated facts that support them (fact a) were already removed.

Still no loop in rule firing, but i have junk in fact memory that can later cause rules i don't want to fire fire.

Some less abstract example

see fire -> ring a bell
ring a bell -> bell rings
bell rings -> be alarmed
be alarmed -> there is alarm
there is alarm -> bell rings

When anyone sees fire i want all stuff to be in fact memory, but when all decide they see no fire anymore and ring a bell disappears i would like this alarm cycle that was logically inserted because of see fire to disappear.

(Maybe not the best example as here you should take some action to stop ringing the bell, nad use ear not deduction to hear ringing, but im writing a "thinking modelling system" and i haven't thought of better non abstract example yet, though my system will be abstract and i do think there are less stupid use cases when you would not like "unsupported logical circles" to stay)

laune wrote

On 03/07/2012, zephyr <[hidden email]> wrote:
> In this case yes, but generally those dependences can be much more
> complicated and this example is the simplest ilustration of the problem.
>
> It can also be
>
> a-> b ->c ->d ->b


In this scenario, Fact b would not be inserted again, because thruth maintenance
always uses equality, irrespective of the runtime configuration
identity/equality.

Make sure to override equals and hashCode correctly, go by the book,

-W


>
> (that makes b,c,d equivalent, but is little less trivial to detect)
>
> or more complicated
> a->b
> b->c
> c and d -> b
> d nad a are facts, then a is removed
> c and b are not eqivalent, but still support each other while there is fact
> d
> etc.
>
> I just want logical facts that are not connected by any rule path with
> inserted facts and only stay because of logical fact cycles to disapear.
>
> Im writing a system that takes user generated dependences as input and its
> main goal is to deal with different consequences, i thought drools might be
> a right tool to base this system on, this didnt work so i wonder is it a
> common problem and is there an easy way to deal with it (or some way to
> change drools to work like this).
>
> --
> View this message in context:
> http://drools.46999.n3.nabble.com/Logical-insert-and-cyclic-rules-dependences-tp4018381p4018397.html
> Sent from the Drools: User forum mailing list archive at Nabble.com.
> _______________________________________________
> rules-users mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/rules-users
>
_______________________________________________
rules-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/rules-users

[laune]

Inferring cause from effect is a logical error.

In your example, one can see that there are two meta-levels. One deals
with physical entities (fire, bell) and the other one with human
sentiments ("being alarmed"). There can be interactions between
levels, but they should be well-defined. (E.g.: I can be alarmed for
many reasons, but this does not give me the right to ring the bell,
but the fire alarm bell ringing is a good reason for me being
agitated.)

You can trip any logic system with such "unclean" reasoning. I'm sure
you know the Barber paradox.

-W


On 03/07/2012, zephyr <[hidden email]> wrote:

> With
>
> "a" is the only inserted fact
>
> a->b->c->d->b
>
> now b,c,d are logically added, b's ref cnt is 2
>
> Fact b is NOT inserted again, (it's ref cnt is increased) and its more or
> less what i wanted.
>
> The problem is, when i remove fact a, b's ref cnt goes to 1, so it stays.
>
> So b,c,d stay in fact memory because they support each other, even though
> all stated facts that support them (fact a) were already removed.
>
> Still no loop in rule firing, but i have junk in fact memory that can later
> cause rules i don't want to fire fire.
>
> Some less abstract example
>
> see fire -> ring a bell
> ring a bell -> bell rings
> bell rings -> be alarmed
> be alarmed -> there is alarm
> there is alarm -> bell rings
>
> When anyone sees fire i want all stuff to be in fact memory, but when all
> decide they see no fire anymore and ring a bell disappears i would like
> this
> alarm cycle that was logically inserted because of see fire to disappear.
>
> (Maybe not the best example as here you should take some action to stop
> ringing the bell, nad use ear not deduction to hear ringing, but im writing
> a "thinking modelling system" and i haven't thought of better non abstract
> example yet, though my system will be abstract and i do think there are
> less
> stupid use cases when you would not like "unsupported logical circles" to
> stay)
>
>
> laune wrote
>>
>> On 03/07/2012, zephyr &lt;ls262570@.edu&gt; wrote:
>>> In this case yes, but generally those dependences can be much more
>>> complicated and this example is the simplest ilustration of the problem.
>>>
>>> It can also be
>>>
>>> a-> b ->c ->d ->b
>>
>>
>> In this scenario, Fact b would not be inserted again, because thruth
>> maintenance
>> always uses equality, irrespective of the runtime configuration
>> identity/equality.
>>
>> Make sure to override equals and hashCode correctly, go by the book,
>>
>> -W
>>
>>
>>>
>>> (that makes b,c,d equivalent, but is little less trivial to detect)
>>>
>>> or more complicated
>>> a->b
>>> b->c
>>> c and d -> b
>>> d nad a are facts, then a is removed
>>> c and b are not eqivalent, but still support each other while there is
>>> fact
>>> d
>>> etc.
>>>
>>> I just want logical facts that are not connected by any rule path with
>>> inserted facts and only stay because of logical fact cycles to disapear.
>>>
>>> Im writing a system that takes user generated dependences as input and
>>> its
>>> main goal is to deal with different consequences, i thought drools might
>>> be
>>> a right tool to base this system on, this didnt work so i wonder is it a
>>> common problem and is there an easy way to deal with it (or some way to
>>> change drools to work like this).
>>>
>>> --
>>> View this message in context:
>>> http://drools.46999.n3.nabble.com/Logical-insert-and-cyclic-rules-dependences-tp4018381p4018397.html
>>> Sent from the Drools: User forum mailing list archive at Nabble.com.
>>> _______________________________________________
>>> rules-users mailing list
>>> rules-users@.jboss
>>> https://lists.jboss.org/mailman/listinfo/rules-users
>>>
>> _______________________________________________
>> rules-users mailing list
>> rules-users@.jboss
>> https://lists.jboss.org/mailman/listinfo/rules-users
>>
>
>
> --
> View this message in context:
> http://drools.46999.n3.nabble.com/Logical-insert-and-cyclic-rules-dependences-tp4018381p4018421.html
> Sent from the Drools: User forum mailing list archive at Nabble.com.
> _______________________________________________
> rules-users mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/rules-users
>

_______________________________________________
rules-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/rules-users

[zephyr]

Guess i shouldn't post this example. Maybe ill think of the better one some day.

Maybe a little more background will make my problem easier to see.

I'm writing a program that simulates thinking, using a special logic that is proven to works well because of many limitations and inspected interactions of rules you can use. The core of this logic are rules in the form of implication and facts that represent observations etc. Those rules can be stupid because there is a "nonsense" logic value that appears when rules contradict one another. I have no control over the rules i get.

I do have algorithm that guarantees no infinite loops while reasoning and coming up with results that make sense in the end. The problem is - how to use drools to calculate what i want in an effective way.  Im trying to "translate" consequences of algorithm on given thinking rules to Drools rules that will represent conclusions, finding contradictions etc (or if impossible use drools rete fast pattern matching in less direct way). Drools pattern matching was really nice and i got a really nice system in no time, so i can concentrate on giving this system better environment. It almost worked, almost is this logic junk that stays and brakes some of my conclusions.

So the goal is to create "pandora box" that will support all kinds of weird rule interaction that at the end gives true and inconsistent facts list.

In life its not that easy to distinguish cause and effect, rules are often correlation based observations and stereotypes. Like "if this guy has knife he's dangerous" and "if hes dangerous he might have a weapon". [hmm maybe here one could find a better illustration]

I thought that such logically inserted cycles do appear in other applications so maybe there is a way to deal with them. My example was not the best one, but i think with more complicated rules and much logical insertions this can happen and on some hard to find occasions make your system do strange things based on not removed junk facts, so it might make complicated logical insert based system unreliable as the premise of only being in fact memory when inserted facts support it is not guaranteed in this case.

laune wrote

Inferring cause from effect is a logical error.

In your example, one can see that there are two meta-levels. One deals
with physical entities (fire, bell) and the other one with human
sentiments ("being alarmed"). There can be interactions between
levels, but they should be well-defined. (E.g.: I can be alarmed for
many reasons, but this does not give me the right to ring the bell,
but the fire alarm bell ringing is a good reason for me being
agitated.)

You can trip any logic system with such "unclean" reasoning. I'm sure
you know the Barber paradox.

-W


On 03/07/2012, zephyr <[hidden email]> wrote:
> With
>
> "a" is the only inserted fact
>
> a->b->c->d->b
>
> now b,c,d are logically added, b's ref cnt is 2
>
> Fact b is NOT inserted again, (it's ref cnt is increased) and its more or
> less what i wanted.
>
> The problem is, when i remove fact a, b's ref cnt goes to 1, so it stays.
>
> So b,c,d stay in fact memory because they support each other, even though
> all stated facts that support them (fact a) were already removed.
>
> Still no loop in rule firing, but i have junk in fact memory that can later
> cause rules i don't want to fire fire.
>
> Some less abstract example
>
> see fire -> ring a bell
> ring a bell -> bell rings
> bell rings -> be alarmed
> be alarmed -> there is alarm
> there is alarm -> bell rings
>
> When anyone sees fire i want all stuff to be in fact memory, but when all
> decide they see no fire anymore and ring a bell disappears i would like
> this
> alarm cycle that was logically inserted because of see fire to disappear.
>
> (Maybe not the best example as here you should take some action to stop
> ringing the bell, nad use ear not deduction to hear ringing, but im writing
> a "thinking modelling system" and i haven't thought of better non abstract
> example yet, though my system will be abstract and i do think there are
> less
> stupid use cases when you would not like "unsupported logical circles" to
> stay)
>
>
> laune wrote
>>
>> On 03/07/2012, zephyr <ls262570@.edu> wrote:
>>> In this case yes, but generally those dependences can be much more
>>> complicated and this example is the simplest ilustration of the problem.
>>>
>>> It can also be
>>>
>>> a-> b ->c ->d ->b
>>
>>
>> In this scenario, Fact b would not be inserted again, because thruth
>> maintenance
>> always uses equality, irrespective of the runtime configuration
>> identity/equality.
>>
>> Make sure to override equals and hashCode correctly, go by the book,
>>
>> -W
>>
>>
>>>
>>> (that makes b,c,d equivalent, but is little less trivial to detect)
>>>
>>> or more complicated
>>> a->b
>>> b->c
>>> c and d -> b
>>> d nad a are facts, then a is removed
>>> c and b are not eqivalent, but still support each other while there is
>>> fact
>>> d
>>> etc.
>>>
>>> I just want logical facts that are not connected by any rule path with
>>> inserted facts and only stay because of logical fact cycles to disapear.
>>>
>>> Im writing a system that takes user generated dependences as input and
>>> its
>>> main goal is to deal with different consequences, i thought drools might
>>> be
>>> a right tool to base this system on, this didnt work so i wonder is it a
>>> common problem and is there an easy way to deal with it (or some way to
>>> change drools to work like this).
>>>
>>> --
>>> View this message in context:
>>> http://drools.46999.n3.nabble.com/Logical-insert-and-cyclic-rules-dependences-tp4018381p4018397.html
>>> Sent from the Drools: User forum mailing list archive at Nabble.com.
>>> _______________________________________________
>>> rules-users mailing list
>>> rules-users@.jboss
>>> https://lists.jboss.org/mailman/listinfo/rules-users
>>>
>> _______________________________________________
>> rules-users mailing list
>> rules-users@.jboss
>> https://lists.jboss.org/mailman/listinfo/rules-users
>>
>
>
> --
> View this message in context:
> http://drools.46999.n3.nabble.com/Logical-insert-and-cyclic-rules-dependences-tp4018381p4018421.html
> Sent from the Drools: User forum mailing list archive at Nabble.com.
> _______________________________________________
> rules-users mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/rules-users
>
_______________________________________________
rules-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/rules-users

[laune]

On 03/07/2012, zephyr <[hidden email]> wrote:
> It almost
> worked, almost is this logic junk that stays and brakes some of my
> conclusions.

Isn't this a very good metaphor for our brain?  ;-))

Here's one way that I've thought of that might help you to detect such "junk".

Let's assume that you wrap insertLogical() and run a check prior to
the actual insertion. If you have a graph representing the logical
dependencies between inferred facts it's a simple thing to detect any
cycles. As soon as an insertion would create a cycle, do not insert.

For each actual insertion, determine the logically inserted facts
backing the new insertion and extend the graph with one new node and
edges.

Use a listener for retractions. For an inferred fact that is
retracted: locate the node in the graph and destroy it and its
incoming and outgoing edges, if any. (Do not propagate this successors
of deleted edges - there should be another retract for them soon
enough.)

The iffy part here is that I've recklessly assumed that the logically
inserted facts don't have any mutable attributes.

I hope that this is logically sound. The technical task should be feasible,

-W
_______________________________________________
rules-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/rules-users

[zephyr]

I think those junk facts are quite interesting from psychological/anthropological perspective but as the project is more AI/thinking database i guess it has to try to get as good conclusions as it can rather than mimicking human errors :P

Im new to drools and some of those ideas seem really interesting. I didn't know you can wrap logical insertions in some code that performs additional check in fact memory (it could be the solution, or part of it) and they will still work [i remember some tip about avoiding "if"s in RHS of rules].

Listening to logical retractions i also missed.
(But i guess i could try to simulate it with "not Fact()" or sth)
[can you respond to rule that was active getting deactivated?]
(can you run some code after all was retracted and before drools looks for new rules to fire; i think if i could store those additional ref cnt increases somewhere, retract them when rule is not active anymore, and add them if they stayed after retraction it would work as i want it to)

Facts are generally not mutable, only their state (true, false, inconsistent) changes, and my current idea represents those states as separate objects. [Maybe gluing them in one class and updating... but i wanted to use logical insert for nice retraction properties {with no cycles}, and they provide nice distinction on stated and inferred... i don't see how to make that with "manual" insert and update]

So i guess this cycle problem is not that easy to solve and ill need to work around it somehow.
Cycle detection is a bit of a problem as cycles may appear and disappear when rules like
"a" and "b" -> c
may be part of cycle; and i think its more about finding parts of fact memory not connected to inserted facts than actual cycles; cyclic dependences are usually ok, the only problem is when they stop logical retraction :(

[Davide Sottara]

I haven't checked, but I think that the logical insertion failure is a bug.. if the logical insertion truth maintenance is based on reference counting, and no cycle detection algorithm is applied, this is definitely a missing feature - and a bad one! You might consider opening a JIRA and let the developers discuss whether it's really an intended/expected behavior or not.

This said, your project seems very interesting! Are you trying to implement a well known logical framework, or is this something new you've been defining? Do you have any research paper that describes it?
Davide

[zephyr]

The language I'm implementing is 4QL http://4ql.org/. There is SQL based interpreter that is ok for testing purposes. As my masters thesis I'm doing Java based version that has more focus on efficiency and ease of integration with other systems than the existing one. Basing it on drools seems like a very good idea as it will make it easy to add more complex rules extensions and have fast pattern matching on facts.

Davide Sottara wrote

I haven't checked, but I think that the logical insertion failure is a bug.. if the logical insertion truth maintenance is based on reference counting, and no cycle detection algorithm is applied, this is definitely a missing feature - and a bad one! You might consider opening a JIRA and let the developers discuss whether it's really an intended/expected behavior or not.

This said, your project seems very interesting! Are you trying to implement a well known logical framework, or is this something new you've been defining? Do you have any research paper that describes it?
Davide