3:33 p.m.
I don't know much about Visual Rules so I will abstain from commenting on
that (although I can imagine what they are doing).
Regarding "interpreted" vs "code generated" RETE, there should be
no
difference at all on the reasoning process, as the rules would be the same,
does not matter if it is "compiled" or "interpreted".
There **could** be difference on the dynamic behavior of the knowledge
base itself, i.e., adding/removing rules while there are sessions running.
Some engines that use the compiled approach require the whole rulebase to be
recreated (and obviously the corresponding sessions) every time a rule
changes or is added/removed to/from the kbase. Talking about Drools itself,
our goal is to remain completely dynamic, even when compiling down to
bytecode, and we do that by using custom classloaders that allow us to
add/remove rules and properly update any existing sessions on-the-fly.
Although, it is important to note that as it is today, Drools does not
bytecode generate all of the kbase (as I mentioned before, we use a mixed
approach). We are capable of bytecode generating all but the beta network as
it is today, and we will add support for that in coming versions.
It is important to note, though, that one approach is not essentially
better than the other. There are advantages to both approaches and in case
of Drools, the idea is to keep them both and hopefully add heuristics that
will allow us to transparently JIT compile only the parts of the network
that would benefit the use case the most, while keeping the non-compiled
approach for the rest. By transparently I mean, without the user having to
worry about this.
Drools sequential mode is a change on the Rete algorithm that is
***not*** transparent. I.e., depending on what you are doing, results might
be completely different when running ReteOO (a general purpose algorithm
with inference) and the Sequential mode. You may think about the sequential
mode as a non-inferencing algorithm.
From all the discussion, I hope it is clear that the functional
requirements of an inference algorithm should not change when running in
compiled or interpreted mode (and that is why I called it an "orthogonal
concern). But, of course, there will probably exist differences on the
non-functional requirements.
[]s
Edson
2010/3/8 Tim de Jager <tim.dejager(a)student.hu.nl>
Thanks a lot everybody for their awnsers, this clarifies it to some extend
:)!
What I was talking about was indeed the difference between an: interpreted
rete engine vs. code generated rete engine vs. the use of no inference
engine at all (e.g. Visual Rules). One of the questions that pop up: Is it
possible to maintain the same 'statefull' features with a code generated
inference engine? Like you said Take generates a backward chaining algorith,
but would it be able to react to a changed fact like drools can with the
modify statement? Is code-generated Rete maybe comparable with the drools
sequential mode?
It could be that I'm mixing alot of things up, I can't find a whole lot on
this subject.
So do you have any insight on the differences between a interpreted rete
engine an a code generated one. Would they differ in functionality in any
way?
Thanks!
-----Oorspronkelijk bericht-----
Van: rules-users-bounces(a)lists.jboss.org namens Edson Tirelli
Verzonden: ma 8-3-2010 17:55
Aan: Rules Users List
Onderwerp: Re: [rules-users] Inferencing
Hi Tim,
That is a nice topic for studies, but be prepared for a tsunami of
information and quite a few controversies. :)
Regarding your question, I am not sure I completely understand what you
mean, but it is important to be clear that "generation of code" is an
orthogonal concern to the chosen algorithm. I.e., take the Rete algorithm
for example: you can have it fully "interpreted" (I am using the term
loosely here), you can generate code for it completely, or you can be
anywhere in the middle. In all cases, the properties of the algorithm itself
will be preserved (assuming the implementations are correct). Incurring the
risk of making a mistake here, I will mention that AFAIK Jess falls in the
first cathegory, OPSJ falls in the second and Drools falls in the 3rd, and
they are all Rete based algorithms.
Its been a long time since I last looked at TAKE, but at that time it was
generating code for a backward-chaining-like algorithm. Not sure what it has
now.
So, my suggestion is that you either focus on the properties of the
algorithms itself (for instance, are you comparing classic Rete with known
algorithm like LEAPS, TREAT, etc) or focus on the advantages and
disadvantages of code generation (for instance "interpreted Rete" versus
"code generated Rete", again using terms loosely here). Mixing everything in
a single comparison might be misleading.
Edson
2010/3/8 Tim de Jager <tim.dejager(a)student.hu.nl>
Hi everybody,
I'm currently doing my bachelor thesis on Rule engines. This
includes
comapring different Rule engine products. I have set up a small Java
program
(Conway's game of life) and I'm writing the 'engine' in different
Rule
engines, while keeping the same GUI,CellGrid etc. I have already
made a
Drools based engine.
I have been studying the Rule engine subject for somewhat more then
a month
now. And I'm currently seeing two different developments namely the
use of
an inference engine and the generation of embedded code instead
(Take,
Visual Rules etc.) I can see some of the pro's and cons with both
paradigms. But I'm wondering what opinion some of you guys have on
the
subject.
I can see that without inferencing it is very hard (or even
impossible) to
keep a statefull session inside the rule engine, haven't seen a
non-inferencing rule engine which does offer this possibility. And
also lose
features like TMS. But what would be a concrete example where a
statefull
session is absolutely necessary? Instead of letting the engine
reason over
all the facts in stateless way. And managing conflicts with a
ruleflow (see
Visual Rules for a nice example).
I'm looking forward to hearing your thoughts.
Thanks,
Tim
P.S I already read two of Mark Proctors blogs on inferencing, but
while
enlightening, they didn't supply me with a definitive awnser
--
--
Edson Tirelli
JBoss Drools Core Development
JBoss by Red Hat @ www.jboss.com