One further note might be helpful: Our application is an environment
for which our users write their own rules (in Jess). Other than test
cases, it in fact has no rules of its own. We provide an execution
environment that embeds Jess. This is the principal reason that many
details of Jess's behavior are important to me, for I'm trying to make
our environment's behavior predictable to our users. Hence, e.g., the
significance of a side effect like a reordered agenda on an operation
(bsave) that ostensibly makes no change to the engine.
Jonathan Sewall wrote:
My Strategy is meant to serve a different purpose, and in any case it
can return only 1, -1 or the value returned by the default Strategy.
Hence it returns 0 only if the built-in depth Strategy returns 0,
which I've observed it can.
In fact I would rather not be concerned about the order of the
agenda: I bother with it only as a poor substitute for labeling
Activations. My real purpose is to be able to note what Activations
are on the agenda before a bsave and then be able to find those same
Activations on the agenda after a bload. I've not wanted to rely on
Activation.equals() since I don't want to assume that it or one of the
methods it calls (directly or indirectly, in the next version if not
in this one, ...) relies on the == operator or the default
Object.equals(), which always return false when comparing an object to
a serialized-deserialized copy of itself. Instead I record an
Activation's position on the agenda (relative to other active entries)
as a label by which to find that Activation later. I'm not pleased
with this, but so far I've come up with no alternative.
My purpose would be far better served if there were simply a String or
a numeric member field of Activation and appropriate accessors by
which I could label the instance uniquely and identify it again later,
after deserialization. If I could effectively subclass Activation,
I'd add this myself.
[EMAIL PROTECTED] wrote:
The order is determined entirely by the conflict resolution strategy
in use. I recall that you were writing custom strategies. If your
strategy returns "0" for a comparison between two Activations, then
the relative order of their firing is indeterminate, so indeed, they
might be affected by various things that happen in Jess.
The best answer to your question is that you should not write systems
that depend on a particular indeterminate order; subtle factors may
change the observed order. Conversely, a Strategy shouldn't return "0"
for two Activations unless the firing order really doesn't matter.
I think Jonathan Sewall wrote:
[Charset iso-8859-1 unsupported, filtering to ASCII...]
I'd previously noticed, and coded for, the fact that inactive
Activations were excised from the agenda by Rete.bsave().
Yesterday, however, a colleague showed me a case in v7.0b6 where the
remaining entries on the agenda were also reordered after calling
bsave(). That is, I was surprised to get different sequences of
active Activations returned by the 2 Iterators below:
Iterator it1 = rete.listActivations();
rete.bsave(byteArrayOutputStream);
Iterator it2 = rete.listActivations();
It appears that the push() calls in
HeapPriorityQueue.writeObject(ObjectOutputStream) can reorder the
reconstituted agenda. Could you provide a public method that
performs the algorithm in
HeapPriorityQueue.writeObject(ObjectOutputStream) yet skips the
actual object serialization call? In other words, could I get a
look at what the agenda will look like after bsave() without the
performance cost of object serialization (of the entire Rete)?
Thanks very much,
Jonathan Sewall
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
