Slashdot Mirror
Building Intelligent, Rule-Based Applications?
Donald Hughes asks: "What are good approaches for building intelligent, rule-based applications? In particular, I typically build ASP.Net applications. I came across P#, which translates Prolog into C#. I also came across NxBRE, which touts itself as the first open-source rules engine for the .Net platform. Currently, the intelligence in my applications consist of data stored in the database, which is either processed in T-SQL or in a C# class using linear conditional logic. This approach works fine to a point, after which the complexity of the if/then statements becomes extremely difficult to manage. This is especially problematic when returning to a project after several months of not looking at it, or when someone needs to be introduced to it for the first time. Does anyone have some helpful advice?"
I'm not an AI or Prolog type person. But if there are a lot of conditional statements that are based upon some know steps then generating them might be an idea.
Of course I tend to be slightly biased towards generators as they save me days of coding and testing in my current job.
Create some intelligent rules, then base your application on them. It is easier than making a peanut, butter and jelly sandwich.
there is a prolog compiler for .net around:1 .3/dlpsharp.html
;)
http://www.dcs.ed.ac.uk/home/jjc/psharp/psharp-1.
as you can implement a prolog interpreter in 30 lines of lisp, you might also want to check lisp.net compilers
I'm not sure I understand the question but you definitely don't want if/then statements in rule-based programming. You basically want to create a separate function for each "if" and each "then", and then declare the relationship between them.
.NET languages, but I'm sure it can be done with a little reflection (pun intended).
For example (I'm just making this up off the top of my head, and using Ruby syntax), you might want to call "customer.save" to send a customer object to the database. You can't call this function until the customer object has had certain things happen to it, for instance "not customer.empty?" must return true. "customer.agreed_to_terms?" must return true. Each of these tests might itself depend on other tests, and so forth. And some tests might need input from the user, or the result of a complex calculation, or whatever.
Just write a function for each and then write some generic code that doesn't call a function until all the dependencies return true. This is like, 5 lines of code.
You can configure the relationships with a simple text file. This is a very powerful system. An analogous system for shell scripts would be Makefiles.
This is super-easy in Lisp, Ruby, etc., not sure about
This is a really easy and powerful concept once you figure it out. Basically your code will "discover" the proper order to do things in based on the dependencies.
A further step is to encode the state of your app in a tuple (an array), and use tuple spaces to distribute work among many machines. It's quite magical when you've got it all working right.
Study the prolog examples as well, Prolog basically generalizes this procedure even more.
You might want to check out Enterprise Patterns and MDA : Building Better Software with Archetype Patterns and UML (Addison-Wesley Object Technology Series) by Jim Arlow and Ila Neustadt. They present a decent model to describe rules.
-- bearclaw
What's intelligent, rule-based application design? Is it different from pattern design?
Maybe make another data structure which contains a list of constraints, sort of like a data representation of all of those if-then-else statements. You can customise the data structure and make it as simple or as complicated as it needs to be to support the processing of those rules.
:)
That way, you can also associate comments and descriptions with those rules which might make it easier to come back to or introduce new people to. Especially if you represent the rules in a particularly user-friendly way (eg. In a database or an XML file as opposed to a binary dump of your data structure into a file) then you allow for simple editting of these constraints using existing tools, and as an added bonus, avoid the need for a recompile each time the constraints need to be changed.
Of course, the disadvantage of this approach is slower execution of your code. If that is a priority then this wouldn't be the best idea
Depending on what you are doing a finite state machine could be a good answer. Take a look at the state machine compiler (SMC) on sourceforge.
Mercury might almost be considered a dialect of Prolog, and offers a .NET compiler, in case you need it. http://mercury.sf.net/
-I like my women like I like my tea: green-
Roughly (and correct me if I'm wrong), a rule-based application is one that stores formulae, business/validation rules, process orchestration steps etc as dynamic data, usually in a database.
The application will load and interpret the rules in order to perform processing functions; and the rules can be modified at runtime, typically by expert users or adminsitrators.
This sig is false.
What is this application?
What kind of "rule based" application has so many if/else tests that it becomes unmanagable?
I know of Prolog and I have seen expert systems running based on this type of logic but I have always seen that type of design as flawed. It is much better to write a simple algorithm that can then more generically handle rules which are stored somewhere else (possibly not in the code at all). I don't see the point of building complex rules right into the code. All that does is add bloat and make the code unmanagable.
What kinds of problems would you solve with a prolog type system?
I've read about prolog, going back for years (it was a scare, a long time ago, in the '80's, I think -- the japanese were spending government money on prolog type logic systems, and they were going to bury us), but I've never really understood how it plugs into the real world.
I mean, if you're doing something practical, what does it do for you?
Even this question is pretty vague... I don't have any idea of what the poster wants the thing to do.
One approach is to have a database table with the rules in them. Example schema:
// example: "x > 3 and y == 7" // what to execute if true // order of execution
table: rules
----------------
ruleID
ruleDescript
expression
ifTrueSnippet
priority
This allows one to easily create a log of the of the rules and their result. Note that it takes a fairly dynamic language to impliment this so that it can execute code snippets from a database. You probably would want to go with something like Python or PHP instead of C++.
However, I am skeptical any such tool can be as flexible as just plain IF statements in code. But it may be useful for non-programmers, yet power-users to manage the rules themselves. The "ifTrueSnippet" may instead be predefined operation names rather than code in that case. And, maybe a parameter column or two may be in order, depending on the domain.
-T-
Table-ized A.I.
If you have a complex enough set of rules, it might be better to pony up the licensing costs for Ilog. It's native .NET code, and very capable.
if/then rules systems (aka expert systems) are know to have this kind of problem.
There's no magical bullet, just switch methodologies, ej, statistical rule construction methods.
As other people have suggested, one path is to invest in an expert system. You haven't mentioned how many rules your expert system consists of, and you may switch to some other expert system to find that it hasn't improved your capability to manage your rules. Regardless of whether you switch or not, I cannot overemphasize the importance of having a good suite of regression tests for your rules.
I know the original poster typically builds .NET applications, but for those times when you want to do this in Java, there are at least two good engines: http://www.mandarax.org/ is a backwards-chained engine (like Prolog), and http://www.drools.org/ is a forward-chained engine (takes action based on input).
I haven't used these in real life, but they seem like they could be quite useful in your rule-based situation:
Recursive queries in SQL Server 2005
In Soviet Russia, the readers moderate YOU! Wait a second...
http://www.ghg.net/clips/CLIPS.html It's C based, mature, multi platformed and easy to interface to (if you can code in C). Currently it has interfaces to Python, PHP and Java.
-- Before you do anything you can't undo, always understand all the things you can't do once you've done it.
I'll keep it short.
:-) searches... all the rules based systems have this issue, again the answer will be depending on the problem.
1. there is no way to completely get rid of if/then statements. they'll be somewhere. What's good with CLIPS or so is that there is not much else than the if/thens of the rules, so you don't get lost in memory allocation and the rest of the bull. On the other hand, the rules (and facts) tend to be localized in the same file, you don't have to read 200 classes of assembler (:-)) files to find all of them
2. depending on the nature of dynamics of your rules , if you don't have that many rules (20-30???) you can use simple (or complicated) if-then statements as long as you DOCUMENT THEM WELL!!! so the next john (or yourself) can pick up the work from there. hmm, this kind'a makes me think
3. if the rules are VERY dynamic (or just too many of them), a more general approach will be needed. Welcome CLIPS or other rule-based expert system. I heard fairy-tales with systems with tens of thousands of rules, so probably it works.
4. How you store the rules, is completely your business, I don't see any problem storing them in a database, file or on a rice, written by a very old and pacient chinese.
5. from the practical standpoint, the problem with the rules is a very general one. how do you connect a lot of facts with a lot of rules? answer? algorithms - check RETE, check hashes, I'll stop here gasping for air short of ideas.
6. how do you apply the rules, in which order? this is another issue, related to the given problem. see the depth, width or jumpy
7. another issue, thread safety, parallelism. how do you synchronize all of these?
and I think I forget something... hmmm... did I turn off the stove...?
I had another sig before, but this one is better
Who is going to maintain the code you write? Is this just for you, a company you work for or a company you are starting?
If it is just for you it really does not matter.
If it a company you work for you may want to check. I had a guy working for me that wanted to write everything in FoxPro because that is what he knew. I told him no but he wrote some little utilities for a different department. He left and no one knows how modify his code. That goodness they were trivial.
If it is a company you are starting. Will you have the time to support your own code? How hard will it be to find someone that can do it for you if you get too busy.
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
I am a PROLOG practitioner and I work in the field of AI, specializing in complex systems. Prolog is an excellent choice when the rules become unusually complex. You don't need a translator or compiler if you use Amzi! Prolog. You can generate compiled modules and call them via a DLL. No problem there. Check them out at www.Amzi.com. As to maintainability, any complex system can become formidable. Prolog will make long-term maintenance easier, not harder. Let me know if I can help. Best wishes, Burt Pierce
Amzi and ILog, mentioned by other posters, are superior, but if you have an MSDN subscription, BizTalk has a built-in forward-chaining rules engine. However, the problem of maintaining a large amount of rules doesn't go away just because you use a rules engine, Prolog, or what-have-you. One of the problems with expert systems is that the explicit un-coupling of rules from execution logic can lead to surprises. If the developer then tries to fix the problem by adding new rules to patch the issue, things can get baroque very fast. Often, a "rules patch" is an attempt to impose imperative flow-control via rules, which is a foolish thing to do. That's why the best rules-based systems almost always use a hybrid of imperative code and rules.
Actually - this is possible - it is called (IIRC) "forge welding" - basically, you get both of your pieces of steel super red hot, place them one on top of the other on an anvil, and pound them as hard as you can with your blacksmith's hammer. This may require more than one person to accomplish, and you need some good strength, because you have to pound that shit HARD. Plus, you need to keep it red hot as you work it. In the end, though, with a bit of patience and skill you will end up with a single piece of steel which can then be worked further.
BTW - this was one of the steps in the making of the "folded steel" (can't remember its true name) samuri swords - basically, getting the steel red hot, folding it over, pounding it flat (and welding it together), pounding it out and stretching it, folding it again, pounding it (welding), etc - until you had the material ready, then continue shaping it into the sword (actually, these swords are much more complicated than this - but that is the basic process - the original method was lost, but they have recreated the method in modern times)...
Reason is the Path to God - Anon
Depending on what kind of logic you're trying to code up, you might find it easier to create a domain-specific language that allows coding in whatever paradigm is most appropriate rather than having to shoehorn everything into logic-language assertions. Haskell is considered one of the best languages for create DSLs (my favourite example is a DSL for financial contracts which I was reminded of by this post); however, like most non-Microsoft, non-trivial languages, it is very difficult to port to the .Net CLR.
Lisp might not be good for RDBMS, but the close correspondance between S-expressions and XML might be extremely helpful if the application is distributed. And anyone who is willing to code rules in Prolog should have no problem with prefix syntax and higher-order functions.
High-end programmers should have no problem switching between prefix and infix: it's only cog-like code monkeys who insist that the most popular languages have C-like syntax. Experts will continue to implement obscure applications in obscure languages for obscene pay.
This could be a mature application with business analysts and real money on the line, he doesn't care about your toy solution.
Why would you write rules that get translated into an intermediate language when you could write what academics call a "compiler" for translating the rules directly into an executable or an "interpreter" for evaluating the rules on the fly? Generators are a sign of an inflexible, poorly designed language (I should know: I get paid to write C#!).
A friend of mine used CLIPS in a system for a drug store chain, which provided suggestions to customers depending on what they purchased.
September 2011: Looking for Cocoa/iOS work in Boston area Cocoa Programmer Quincy, MA
"CLIPS: A Tool for Building Expert Systems"
http://www.ghg.net/clips/CLIPS.html
Very rarely the answer is Prolog.
For the rest of cases, building your own rule processing engine that serves a particular purpose and interacts with the rest of the system, is such an easy task, it is not worth generalizing.
For $deity sake, netfilter has some (simple) rule-based processing, and it's merely a small piece of code inside the Linux kernel.
Contrary to the popular belief, there indeed is no God.
Need proof that this is a real form of welding? HERE IS YOUR PROOF
A couple of excerpts from the site:
Forge welding is the core technique involved in creating Damascus steels. It is a solid-phase bonding technique that uses heat and pressure to make the weld. To make Damascus steels the current method is to stack alternating pieces of steel, each with a contrasting composition, heat the billet in a fire and at the proper temperature apply pressure to make the weld.
and
You may vary the way you fold the billet. The Japanese method of making sword steel involves forging the billet wide and cutting down the middle and folding side to side. Any change will affect the look of the steel and may yield some interesting patterns.
I know in general the population is filled with masses of individuals ignorant in how the world came to be shaped by mankind over the centuries. I would expect responses of laughter and jeering "from the pit" on a site like Fark, for instance, where you have a more homogenous mix of the ignorant and the intelligent.
I expect more from the denizens Slashdot, though. I find it absurd that a site supposedly for geeks, by geeks, a site set up for intelligent people to express and judge each other's comments about posted articles and other comments about the world; is rapidly becoming a site which is attracting the unintelligent, the unimaginative, and the uninspired, while simultaneously slowing pushing out those who are 180 degrees opposite in nature.
This is a truely sad observation, one which I know others have noted and lamented on in the past...
Reason is the Path to God - Anon