A good technical question!

The method listActivations() is not used internally by Jess; it's just provided for use by tools of various kinds. It's a fairly expensive method because it makes a copy of the whole agenda, and iterating over this copy does a full sort. The copy is necessary; the process of iterating over all the activations is destructive. They're not kept in sorted order -- they're pulled out "just in time." Anyway concern over using == vs equals() may be misplaced -- this is a small difference compared to the overall expense of copying the whole agenda. This much has always been true.

What's changed in 7.0 is that an Activation object can't be part of more than one agenda at a time, because the Activation "knows" where in the agenda it lies. In older versions, the same Activation objects would live in the copied agenda as in the original; now copies are made of all the Activations, too. This new property of Activation objects is an optimization; it makes the process of removing activations from the agenda before firing them (due to a retraction, for example) much more efficient.

I thought of this as an internal implementation detail and so didn't document it, but the change is permanent.


On Dec 2, 2006, at 8:07 PM, Jonathan Sewall wrote:

I've found that the method below behaves differently in Jess 7.0b7 and the formal v7.0 release. In the formal release, the Activations provided by the Iterator in 2 successive calls to Rete.listActivations() are different objects, even if nothing has happened between the calls. The change has ramifications for those with custom Strategy implementations. In our case, we scan the agenda for a particular Activation to favor before calling run(), and then our Strategy's compare() method tests its arguments for that object with the == operator. We can, with some impact on performance (presumably negligible on short agendas), use the Activation.equals() method instead of the == operator. But I wanted to ask about the intent of the change, and whether it's likely to be permanent. I hadn't seen (but could have simply missed) mention of it in the notes since beta 7. Thanks very much,

Jonathan
________

   public void dumpAgenda(String label) {
       Map actMap = new HashMap();
Iterator it = listActivations(); // get the agenda and store Activations
       for (int i = 0; it.hasNext(); ++i) {
           Activation a = (Activation) it.next();
           actMap.put(new Integer(a.hashCode()), a);
       }
it = listActivations(); // get the agenda again; no intervening activity
       for (int i = 0; it.hasNext(); ++i) {
           Activation a = (Activation) it.next();
Activation aa = (Activation) actMap.get(new Integer (a.hashCode()));
           System.out.println("agenda a["+i+"]"+
(aa == null ? " not" : "")+" in map,"+ // aa ! = null in both v7.0b7 and 7.0 (a == aa ? "" : " not")+ " same obj"); // aa == a only in v7.0b7
       }
   }
--------------------------------------------------------------------
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 owner-jess- [EMAIL PROTECTED]
--------------------------------------------------------------------

---------------------------------------------------------
Ernest Friedman-Hill
Advanced Software Research          Phone: (925) 294-2154
Sandia National Labs                FAX:   (925) 294-2234
PO Box 969, MS 9012                 [EMAIL PROTECTED]
Livermore, CA 94550                 http://www.jessrules.com
--------------------------------------------------------------------
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]
--------------------------------------------------------------------

Reply via email to