I think Steve Webster wrote:
> Greetings,
>
> I've tried to use the current event model to determine which Node passed a
> given Token along to its successor, without any success. I have no way of
> tracking a Token, since new Tokens are created for each hop in the Rete
> network and their current attribution does not carry a unique identifier.
> Consequently, I have no way of disambiguating which predecessor Node that
> caused a RETE_TOKEN_LEFT event in a given Node, when that Node has multiple
> predecessors. Consequently, I can not identify which Nodes have propagated a
> Token after a change in the fact base. From my perspective, there are three
> choices ...
Note that (as far as I know) the Rete network can have 0, 1, or 2
inputs (or "predecessors," a good term but one that isn't used in the
Jess source.) This is a property of the Rete algorithm. It's possible
that there's an exception to this rule in Jess, but I can't think of
one. You seem to imply that you're aware of an exception when you
mention false positives below -- if you have a specific example I'd
be very interested in seeing it.
Anyway, the root node has zero inputs, all pattern-network nodes and
terminal nodes have 1, and all join nodes have 2 (left and right.)
Therefore, given a join node as the source object, and the event type
RETE_TOKEN_LEFT, you know that the single node connected to the left
input of the join is the source of the event. Now, what you DON'T know
is which node that is, since there are no backpointers. The view
command walks the Rete network and collects that kind of information
when it builds the display, and maybe you could do something similar.
Every node except terminal nodes can have any number of outputs
("successors," as they are called in the Jess source.) Terminal nodes
have none.
>
> 1) Modify the event model to provide events upon exit from a given Node, as
> described below. I would be happy to take a crack a modifying the code and
> including it as suggested patch. However, I'm inferring by the lack of
> response to my previous post that this modification would not be welcome.
> With any luck, I'm wrong.
>
> 2) Add state information to the Token object which reflects which Node
> generated the Token. This approach does not appeal, because obviously the
> Rete implementation functions quite nicely without it, it adds overhead, and
> it's applicability is very narrow.
>
> 3) Give up, and fork the code base. A horrible solution, for obvious
> reasons! ;)
>
> If I've left anything out, please let me know. I'm quite excited in that my
> application's view of the Rete network has already providing great debugging
> assistance to my development team, even though some false positives result.
>
> Regards,
> Steve
>
> > -----Original Message-----
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
> > Behalf Of Steve Webster
> > Sent: Thursday, April 25, 2002 2:40 PM
> > To: [EMAIL PROTECTED]
> > Subject: RE: JESS: Debug Utility
> >
> >
> > Ernest,
> >
> > You raise points that I had not considered, but I think you get
> > to the issue
> > when you mention, "a NodeViewer gets an event, and it knows it
> > describes the
> > node being displayed." The difference in our perspective can be attributed
> > to how our respective applications "describe the node being displayed."
> >
> > Here's where I demonstrate my ignorance of the Rete algorithm and probably
> > your implementation, but let me proceed none the less. Description of the
> > node has to do, from my perspective, with which tokens it successfully
> > passes to its successors, not the tokens it acts upon. Stated another way,
> > I'm not interested in all the tokens a node sees, rather I'm only
> > interested
> > in the tokens that satisfy the node's propagation logic. I
> > noticed that many
> > of your Node's toString results describe nodes as "Tests ...." I'm
> > interested in displaying whether those test have been met. If the network,
> > as depicted by other event consumers such as "(view)," is better described
> > by the Token inputs, then my argument is invalid.
> >
> > Finally, I understand your reluctance to expose the JESS
> > internals, but the
> > tag should be benevolent. Since Java would return this value by copy,
> > there's no opportunity for hacks like me to corrupt JESS during
> > run time. I
> > knew better than to ask you for hasLHS.getNodes to be public for just that
> > reason!
> >
> > HTH,
> > Steve
> >
> >
> > > -----Original Message-----
> > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
> > > Behalf Of [EMAIL PROTECTED]
> > > Sent: Thursday, April 25, 2002 1:58 PM
> > > To: [EMAIL PROTECTED]
> > > Subject: Re: JESS: Debug Utility
> > >
> > >
> > > I think Steve Webster wrote:
> > > > Ernest,
> > > >
> > > > Thanks for your support. Now that you've given me a leg to stand upon,
> > > > perhaps I could suggest another change.
> > > >
> > > > I noticed that these node events that now carry tokens are
> > all generated
> > > > upon the token's arrival in the class. Ideally, the event would
> > > be generated
> > > > right before the token is propagated to the next node. Under
> > the current
> > > > implementation, there's no way to determine what node delivered
> > > the token
> > > > that triggered the event broadcast. However, if the event was
> > > generated by a
> > > > node just before the token is propagated to adjacent nodes, one could
> > > > uniquely determine how far the token propagated through the
> > > Rete network. If
> > > > one was still interested in determining which nodes were
> > > getting the token,
> > > > that information would still be available via the originating node's
> > > > getSuccessor method.
> > >
> > > This also has the added benefit that the number of events is reduced by
> > > the "fan-out" factor. On the other hand, it does complicate the
> > > application that the whole mechanism was originally designed for,
> > > doesn't it? In the current "view" implementation, a NodeViewer gets an
> > > event, and it knows it describes the node being displayed. In the
> > > proposed implementation, a NodeViewer would have to listen to the
> > > inputs instead. Since there are currently no back-pointers in the Rete
> > > network, I'm not sure how this would get set up.
> > >
> > > You've probably got something in mind, so let me know how it would work.
> > >
> > >
> > > >
> > > > Finally if you're so inclined, perhaps you could introduce a
> > > public accessor
> > > > method for the Token's m_tag attribute.
> > >
> > > This is obviously necessary for what you're doing, but you can imagine
> > > it makes me shudder a bit. The more detail is exposed, the more
> > > headaches I have when things change. OTOH, this is pretty stable, so OK.
> > >
> > > >
> > > > Thanks again,
> > > > Steve
> > > >
> > >
> > >
> > > ---------------------------------------------------------
> > > 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]
> > --------------------------------------------------------------------
> >
> >
>
>
> --------------------------------------------------------------------
> 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]
> --------------------------------------------------------------------
>
---------------------------------------------------------
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]
--------------------------------------------------------------------
