Whereas this may or may not be true for CLIPS and its forebears, it is
incorrect as far as Jess's implementation goes. What you say about a
rule firing only once on a given set of facts is indeed true, but Jess
does not use the numeric IDs of facts to make this determination, and
never has. A token in Jess's Rete network has always contained
references to Fact objects, not the numeric IDs of the facts. The
numeric IDs are merely a convenience for the user, and again, their
behaviour is arbitrary and follows that in CLIPS simply for the sake
of familiarity.
Let me assure you that what I stated below is quite true: Jess could
be trivially altered such that the (modify) function did -not- update
the numeric ID of a fact, and everything else would continue to work
without change. I was wondering aloud whether anyone would be
interested in seeing this as an available option.
I think DusanSormaz wrote:
> 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]
---------------------------------------------------------------------
