Thanks for you patience in describing the Rete implementation. You have cleared up my understand of what's going on under the covers and the meaning of a Node's "left" and "right." However even after you explanation, I still think there may be a case that can not be handled as you've described below.
Specifically, I have a Node1RTL that has two inputs in my test case, according to the (view) utility. Tracing the inheritance chain, there only appears to be one means of generating Token events, the Node1.callNodeRight method. Therefore, it appears that two inputs are wired to the "right" side of the successor, Node1RTL. This construct appears to violate your description below, where I inferred that one input would be directed to the "left" and the other to the "right." Hence, I'm back in the disambiguation trap. As for my citation of a false positive, it's my application that depicts this conclusion, not the Rete network. Sorry if I caused any confusion. Once again, thanks for the patience and support. Steve > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On > Behalf Of [EMAIL PROTECTED] > Sent: Monday, April 29, 2002 3:05 PM > To: [EMAIL PROTECTED] > Subject: Re: JESS: Debug Utility > > > 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] > -------------------------------------------------------------------- > > -------------------------------------------------------------------- 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] --------------------------------------------------------------------
