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 <ls262570@.edu> 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-depende...
>>> 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-depende...
> 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