Al,
your point about load on Ernest is well taken (believe me, I know how he
feels), but on the efficiency front things seem a little less clear. If I read
Ernest's original response correctly he seemed to imply that a "deep"
implementation of modules - where each namespace maintains its own agenda - would
actually be _more_ efficient for large rulesets which are, in effect, partitioned
into smaller ones by means of this approach.
There has been much mention of what is, in a effect, a group of independendent
agents (Rete processes running on their own rulesets) which cooperate via shared
facts of some kind (Java Spaces, Sockets, .....). This is nice but is neither what
I want nor need:
My system very naturally partitions itself into a number a sequential phases,
where each phase is potentially complex (many complex rules and much 'record
keeping'). I found myself naturally writing names along the lines of
pretend-module-name-rule-name and likewise for facts. This was somewhat messy, I
had to keep a lot of my own book-keeping straight, and I had the niggling feeling
that resources were being used by Jess that needn't be - to keep track of rules
that I knew would never fire again. Of course the Rete compilation itself deals
with managing some of this to make things as efficient as possible, but
nonetheless if for no other reason than good 'coding' practice (the last time I
checked modularity was still the "in thing") it seems that modules would be a good
thing. I'd even contemplated writing out my facts at the end of one pseudo module,
invoking a new copy of Jess on the facts and the next pseudo module rulebase and
then terminating -- multi-pass reasoning if you will. Yuk.
Tnx
Alanl
Al Davis wrote:
> Alex (et al),
> This is exactly my point... in a multi-agent system of autonomous
> intelligent agents, from both a design and implementation perspective,
> knowledge and rule partitioning (e.g. via modules) is highly desirable
> (if not essential) in order to maintain autonomy.......
...... but as others have pointed out presents issues of efficiency, not to
mention being shadowed by
> other tasks of higher priority that already burden our friend Ernest.
--
-------------------------------------------------------------
| Alan Littleford | Networks and Software |
| [EMAIL PROTECTED] | (650)-964-4313 |
-------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]'
in the BODY of a message to [EMAIL PROTECTED], NOT to the
list. List problems? Notify [EMAIL PROTECTED]
---------------------------------------------------------------------
