Re: [rules-users] Inferencing
2010/3/9 Tim de Jager : > > > Also interesting read about the Airliner application Greg, thanks! Not "Up in the Air" but on rails: http://sunsite.informatik.rwth-aachen.de/Publications/CEUR-WS/Vol-549/paper6.pdf -W ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] Inferencing
Thank you this explains it. As I see it the Visual Rules approach is very
different in that it's more of a flowchart based approach than actual
inferencing. And it's clear now that there is no difference in the infreasoning
inferencing process either interpreted or compiled.
Also interesting read about the Airliner application Greg, thanks!
-Oorspronkelijk bericht-
Van: rules-users-boun...@lists.jboss.org namens Edson Tirelli
Verzonden: ma 8-3-2010 22:33
Aan: Rules Users List
Onderwerp: Re: [rules-users] Inferencing
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
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-boun...@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
Re: [rules-users] Inferencing
You can have code generated rete and still maintain state. Edson mentioned OPSJ, and I can verify that (at least the last time I worked with it 10 years ago) it was code generated and maintained state. http://www.pst.com/opsj.htm http://www.pst.com/opsjbro.htm --- On Mon, 3/8/10, Tim de Jager wrote: > From: Tim de Jager > Subject: Re: [rules-users] Inferencing > To: "Rules Users List" > Date: Monday, March 8, 2010, 2:37 PM > > > > 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-boun...@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 > > > > 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 &g
Re: [rules-users] Inferencing
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 > > > > 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-boun...@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 (
Re: [rules-users] Inferencing
Wolfgang, you've basically described the system I've been working on for two years, the Early Alerts System at Southwest Airlines. So yes, Tim, there are real world examples. :) In my case EAS monitors the state of our aircraft fleet (and soon the state of customer bookings) and alerts dispatchers to problems. The actions of the dispatchers and ground operations personnel feeds back into the system and changes the aircraft state. The app was actually designed in a semi stateless manner at first, but it quickly became apparent that the state of all aircraft had to be tracked to reduce rule complexity and increase performance. Otherwise, every time a significant operation had to be performed, the current state of the aircraft had to be retrieved from external system, which did not scale well at all. Also the state being stored locally means you can continually update it and write rules that fire off the state of groups of aircraft, which would be even more untenable if handled in a stateless manner. (i.e. when monitoring all aircraft at an airport we'd have to periodically load the state of the entire airport and run rules, when in statefull mode all we have to do is subscribe to the aircraft events, a simpler and less resource intensive process.) --- On Mon, 3/8/10, Wolfgang Laun wrote: > From: Wolfgang Laun > Subject: Re: [rules-users] Inferencing > To: "Rules Users List" > Date: Monday, March 8, 2010, 1:13 PM > Delayed modifications of the facts > database are bound to have an > impact on the semantics of your rule set (unless, perhaps, > you are > writing them anticipating this execution cycle). A stateful > session > effects changes immediately, which, in turn, affects the > facts and the > agenda immediately. Delaying these changes for the next > stateless run > will make rules fire in the current run, which would not do > so in the > stateful execution scenario. > > As for the initial question, whether there are real > applications that > need stateful session, I'd like to say that there is a set > of > applications that need stateful reasoning to be built > according to the > (as I call it) Plant Design Pattern. Such an application is > meant to > monitor a set of real world objects, with their dynamically > changing > states as facts, and while observing incoming state changes > and > operator commands. And, the important point is, that firing > rule will > cause interaction with the real word. > > -W > > > On Mon, Mar 8, 2010 at 6:21 PM, Pavel Tavoda > wrote: > > Yes you are right but that should be a hidden detail > like asynchronous > > connect is internally synchronous because you are > waiting for > > confirmation packet (but not response) ;-). > > > > No way to implement execution without changing > "global" state - am I > > right? BTW I implemented for one small subproject (IRC > bot) mechanism > > where I listen to all new memory inserts and repeat > them at beginning > > of next stateless session with new KnowledgeBase. Very > simple and > > straightforward just 20 lines of code because I don't > have to > > serialize it just keep in memory for next run. > > > > Pavel > > > > 2010/3/8 Edson Tirelli : > >> > >> Interesting analogy, but careful here: > >> > >> "Statefull is just series of stateless session > where you transfer state from > >> one session to another." > >> > >> Not sure what lead you to think that way, > but it is actually the > >> opposite, and trying to explain that will make > things REALLY confusing for > >> some. So, I would recommend anyone not interested > in knowing internal > >> details to **stop reading here**! > >> > >> Ok, if you are still reading, then I will > try to explain in the simplest > >> way I can: "there is no such thing as stateless > session in Drools > >> internals". Deep in drools internals, there is > only stateful working memory, > >> that is exposed to the user in 2 different ways: a > properly stateful > >> session, that allows users to manage the state, > and a helper object that we > >> call "staless session". This helper staless > session object, among other > >> things, simply holds a reference to the kbase and > when the execute(...) > >> method is called, internally it creates a stateful > session, inserts the > >> facts, fire the rules and disposes the session > automatically. There are a > >> bunch of other helper mechanisms there, but the > essence is just that: > >
Re: [rules-users] Inferencing
I think that the functionality is the same, compiled (generated) or interpreted. You will have the same consequences of an interpreted language or a compiled one. That's my two cents opinion. 2010/3/8 Tim de Jager > > > > 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-boun...@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 > > > >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 >-- >View this message in context: > http://n3.nabble.com/Inferencing-tp435411p435411.html &
Re: [rules-users] Inferencing
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-boun...@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 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 -- View this message in context: http://n3.nabble.com/Inferencing-tp435411p435411.html Sent from the Drools - User mailing list archive at Nabble.com. ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users -- Edson Tirelli JBoss Drools Core Development JBoss by Red Hat @ www.jboss.com <>___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] Inferencing
Delayed modifications of the facts database are bound to have an impact on the semantics of your rule set (unless, perhaps, you are writing them anticipating this execution cycle). A stateful session effects changes immediately, which, in turn, affects the facts and the agenda immediately. Delaying these changes for the next stateless run will make rules fire in the current run, which would not do so in the stateful execution scenario. As for the initial question, whether there are real applications that need stateful session, I'd like to say that there is a set of applications that need stateful reasoning to be built according to the (as I call it) Plant Design Pattern. Such an application is meant to monitor a set of real world objects, with their dynamically changing states as facts, and while observing incoming state changes and operator commands. And, the important point is, that firing rule will cause interaction with the real word. -W On Mon, Mar 8, 2010 at 6:21 PM, Pavel Tavoda wrote: > Yes you are right but that should be a hidden detail like asynchronous > connect is internally synchronous because you are waiting for > confirmation packet (but not response) ;-). > > No way to implement execution without changing "global" state - am I > right? BTW I implemented for one small subproject (IRC bot) mechanism > where I listen to all new memory inserts and repeat them at beginning > of next stateless session with new KnowledgeBase. Very simple and > straightforward just 20 lines of code because I don't have to > serialize it just keep in memory for next run. > > Pavel > > 2010/3/8 Edson Tirelli : >> >> Interesting analogy, but careful here: >> >> "Statefull is just series of stateless session where you transfer state from >> one session to another." >> >> Not sure what lead you to think that way, but it is actually the >> opposite, and trying to explain that will make things REALLY confusing for >> some. So, I would recommend anyone not interested in knowing internal >> details to **stop reading here**! >> >> Ok, if you are still reading, then I will try to explain in the simplest >> way I can: "there is no such thing as stateless session in Drools >> internals". Deep in drools internals, there is only stateful working memory, >> that is exposed to the user in 2 different ways: a properly stateful >> session, that allows users to manage the state, and a helper object that we >> call "staless session". This helper staless session object, among other >> things, simply holds a reference to the kbase and when the execute(...) >> method is called, internally it creates a stateful session, inserts the >> facts, fire the rules and disposes the session automatically. There are a >> bunch of other helper mechanisms there, but the essence is just that: >> simplify the use of stateful sessions for stateless scenarios. >> >> Edson >> >> 2010/3/8 Pavel Tavoda >>> >>> It's like synchronous vs. asynchronous communication. In reality it's >>> always asynchronous but from top view it appear synchronous. >>> Similar to stateless vs. statefull. Statefull is just series of >>> stateless session where you transfer state from one session to >>> another. Look for Drools statefull persistency. In reality it is >>> series of stateless sessions where you store status from one session >>> result and use it as start for another session plus some new changes. >>> This is my point of view of difference between stateless/statefull >>> session specially how Drools make it. >>> >>> Regards >>> >>> Pavel >>> >>> On Mon, Mar 8, 2010 at 4:23 PM, Tim de Jager >>> wrote: >>> > >>> > 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
Re: [rules-users] Inferencing
Yes you are right but that should be a hidden detail like asynchronous connect is internally synchronous because you are waiting for confirmation packet (but not response) ;-). No way to implement execution without changing "global" state - am I right? BTW I implemented for one small subproject (IRC bot) mechanism where I listen to all new memory inserts and repeat them at beginning of next stateless session with new KnowledgeBase. Very simple and straightforward just 20 lines of code because I don't have to serialize it just keep in memory for next run. Pavel 2010/3/8 Edson Tirelli : > > Interesting analogy, but careful here: > > "Statefull is just series of stateless session where you transfer state from > one session to another." > > Not sure what lead you to think that way, but it is actually the > opposite, and trying to explain that will make things REALLY confusing for > some. So, I would recommend anyone not interested in knowing internal > details to **stop reading here**! > > Ok, if you are still reading, then I will try to explain in the simplest > way I can: "there is no such thing as stateless session in Drools > internals". Deep in drools internals, there is only stateful working memory, > that is exposed to the user in 2 different ways: a properly stateful > session, that allows users to manage the state, and a helper object that we > call "staless session". This helper staless session object, among other > things, simply holds a reference to the kbase and when the execute(...) > method is called, internally it creates a stateful session, inserts the > facts, fire the rules and disposes the session automatically. There are a > bunch of other helper mechanisms there, but the essence is just that: > simplify the use of stateful sessions for stateless scenarios. > > Edson > > 2010/3/8 Pavel Tavoda >> >> It's like synchronous vs. asynchronous communication. In reality it's >> always asynchronous but from top view it appear synchronous. >> Similar to stateless vs. statefull. Statefull is just series of >> stateless session where you transfer state from one session to >> another. Look for Drools statefull persistency. In reality it is >> series of stateless sessions where you store status from one session >> result and use it as start for another session plus some new changes. >> This is my point of view of difference between stateless/statefull >> session specially how Drools make it. >> >> Regards >> >> Pavel >> >> On Mon, Mar 8, 2010 at 4:23 PM, Tim de Jager >> wrote: >> > >> > 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 >> > -- >> > View this message in context: >> > http://n3.nabble.com/Inferencing-tp435411p435411.html >> > Sent from the Drools - User mailing list archive at Nabble.com. >> > ___ >> > rules-users mailing list >> > rules-users@lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/rules-users >> > >> >> ___ >> rules-users mailing list >> rules-users@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/rules-users > > > > -- > Edson Tirelli > JBoss Drools Core Development > JBoss by Red Hat @ www.jboss.com > > ___ > rules-users mailing list > rules-users@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-users > > ___ rules-users mailing list rules-users@lists.jboss.org https:
Re: [rules-users] Inferencing
Interesting analogy, but careful here: "Statefull is just series of stateless session where you transfer state from one session to another." Not sure what lead you to think that way, but it is actually the opposite, and trying to explain that will make things REALLY confusing for some. So, I would recommend anyone not interested in knowing internal details to **stop reading here**! Ok, if you are still reading, then I will try to explain in the simplest way I can: "there is no such thing as stateless session in Drools internals". Deep in drools internals, there is only stateful working memory, that is exposed to the user in 2 different ways: a properly stateful session, that allows users to manage the state, and a helper object that we call "staless session". This helper staless session object, among other things, simply holds a reference to the kbase and when the execute(...) method is called, internally it creates a stateful session, inserts the facts, fire the rules and disposes the session automatically. There are a bunch of other helper mechanisms there, but the essence is just that: simplify the use of stateful sessions for stateless scenarios. Edson 2010/3/8 Pavel Tavoda > It's like synchronous vs. asynchronous communication. In reality it's > always asynchronous but from top view it appear synchronous. > Similar to stateless vs. statefull. Statefull is just series of > stateless session where you transfer state from one session to > another. Look for Drools statefull persistency. In reality it is > series of stateless sessions where you store status from one session > result and use it as start for another session plus some new changes. > This is my point of view of difference between stateless/statefull > session specially how Drools make it. > > Regards > > Pavel > > On Mon, Mar 8, 2010 at 4:23 PM, Tim de Jager > wrote: > > > > 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 > > -- > > View this message in context: > http://n3.nabble.com/Inferencing-tp435411p435411.html > > Sent from the Drools - User mailing list archive at Nabble.com. > > ___ > > rules-users mailing list > > rules-users@lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/rules-users > > > > ___ > rules-users mailing list > rules-users@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-users > -- Edson Tirelli JBoss Drools Core Development JBoss by Red Hat @ www.jboss.com ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
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 > > 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 > -- > View this message in context: > http://n3.nabble.com/Inferencing-tp435411p435411.html > Sent from the Drools - User mailing list archive at Nabble.com. > ___ > rules-users mailing list > rules-users@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-users > -- Edson Tirelli JBoss Drools Core Development JBoss by Red Hat @ www.jboss.com ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] Inferencing
It's like synchronous vs. asynchronous communication. In reality it's always asynchronous but from top view it appear synchronous. Similar to stateless vs. statefull. Statefull is just series of stateless session where you transfer state from one session to another. Look for Drools statefull persistency. In reality it is series of stateless sessions where you store status from one session result and use it as start for another session plus some new changes. This is my point of view of difference between stateless/statefull session specially how Drools make it. Regards Pavel On Mon, Mar 8, 2010 at 4:23 PM, Tim de Jager wrote: > > 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 > -- > View this message in context: > http://n3.nabble.com/Inferencing-tp435411p435411.html > Sent from the Drools - User mailing list archive at Nabble.com. > ___ > rules-users mailing list > rules-users@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-users > ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
