Ernest and all,
there is a rationale that in ops5 and clips modified fact gets new ID:
No rule should be fired twice on the same (unchanged) set of data (facts).
This ID was used as a test that fact has been changed and rule needs to be
revisited, or in rete network, new fact needs to be pushed through the net
for possible rule firing.
Relaxing new ID creation would jeopardize this behavior of rete net. New
mechanism needs to be implemented (if it is not already implemented).
Cheers,
Dusan Sormaz
At 05:48 AM 2/13/01 -0800, [EMAIL PROTECTED] wrote:
>I think Thomas Barnekow wrote:
> >
> > Then what exactly is the rationale behind changing a fact's id after having
> > modified a slot? Does a modification produce, at least conceptually, a new
> > fact or is it still the same fact? Is the fact id a mixture of an object's
> > "identity" and some versioning information?
> >
> > Thomas
> >
>
>There really is no rationale that I'm aware of -- that's just the way
>it's always been done. Jess is just doing what CLIPS does.
>
>Because of the Rete algorithm works, a "modify" is really a retract
>followed by an assert -- i.e., the fact is removed, changed, and
>reasserted. I suppose this is why in CLIPS the ID changes; I guess
>they viewed it as "retract, create new, assert." But in Jess, a Fact
>is a Java object, and that same object gets reused, deliberately. The
>ID gets updated just because that's how it's always been done.
>
>Jess would have no problem functioning if the ID -wasn't-
>updated. Would this be a useful option? The recent changes I've been
>describing -- where the bound "fact-id" is really the fact itself --
>has many useful properties beyond what you gain from having unchanging
>ids.
>
>
>
>---------------------------------------------------------
>Ernest Friedman-Hill
>Distributed Systems Research Phone: (925) 294-2154
>Sandia National Labs FAX: (925) 294-2234
>Org. 8920, MS 9012 [EMAIL PROTECTED]
>PO Box 969 http://herzberg.ca.sandia.gov
>Livermore, CA 94550
>
>---------------------------------------------------------------------
>To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]'
>in the BODY of a message to [EMAIL PROTECTED], NOT to the
>list (use your own address!) List problems? Notify
>[EMAIL PROTECTED]
>---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]'
in the BODY of a message to [EMAIL PROTECTED], NOT to the
list (use your own address!) List problems? Notify [EMAIL PROTECTED]
---------------------------------------------------------------------
