I have a confusion after discussion with one of my fellow on the rule base system. I have developed one in Android which has set of rules. What i say is that initial facts have to match any rule in order to start the engine, so we can directly start matching the initial facts without sending them to working memory.
the fellow says that NO, the initial facts has to enter the working memory and then matching should start and i agree till here but he also adds that you only need to get the variables from the initial facts and then match the rules for example io have a rule
a(variable),b(constant)
Initial facts in Working memory is a(VAR_VALUE)
so will it invoke the rule
a(variable),b(constant)
if the answer is yes then we can have a lot of such rules with constant values that can be invoked even when the working memory is empty.
i need some expert opinion on the issue above, so i may do the development changes as required.
Check the predicate match first, uf same then check if the subject is variable or not. If not then match with correapong rule if both subjects same then it will match.
Rules with comstants has to match elementa of wm. Otherwise it will b infinite loop. As aingle variable can come with any number of constants.
Also use better conflict reaolution strategy.
Related
This question already has answers here:
include or extend in UML?
(2 answers)
Closed 11 months ago.
I have this diagram. The staff receives an email when his letter is approved. Do I need add an include relationship between two use cases? If I did that, it means the staff needs to approve letter to receive an email. It's different from the description.
Definitely not. The simple reason is, that Receive Email is no use case. It is a pure function, likely used in some yet unknown use case. A use case brings added value to its actor. And receiving an email has no added value (like the dreaded Login).
It's hard to judge whether Approve Letter is a valid use case. It seems like a bit trivial. Probably if it's a certain letter in a certain process. As such, I would not let it go through as use case.
As always I recommend to read Bittner/Spence about use case modeling.
I am looking for an appropriate formalism (i.e. a temporal logic) to model the following kind of situation
There can be events happening at discrete events in time (subject to conditions to be detailed below).
There is state. This state cannot be expressed by a fixed number of variables. However, it is possible to express it with a linear list/array, where each entry consists of a finite number of variables.
Before any events have happened, the state is fixed.
At any point in time, events are possible. They have a fixed structure (with a few variables). The possible events are constrained by the current state.
Events will cause an immediate change of the state.
Events can also cause continuous state changes. For example, a variable (of one of the entries of the array mentioned above) changes its value from 0 to 1 over some time (either immediately or after a specified delay).
It should also be possible to specify discrete points in time in the form "the earliest point in time after event E where some condition C holds", and to start a continuos state change at such a point.
Is there an existing temporal logic to model something like this?
It should also be possible to express desired conditions, like the following:
Referring to a certain point in time: The sum of a specific variables of all the entries of the array may not exceed a certain threshold.
Referring to change over time: For all possible time intervals, the value of a certain variable (again, from each entry of said array) [realistically, rather of some arithmetic expression computed for each entry] must not change faster than a given threshold.
There should exist a model checker that can check whether for all possible scenarios, all the conditions are met. If this is not the case, it should print one possible scenario and tell me which condition is not met. In other words, it should distinguish between conditions describing the possible scenarios, and conditions that have have to be fulfilled in those scenarios, and not just tell me "not possible".
You need a model checker with more flexible language. Technically speaking model checking of systems of infinite state space is open research problem and in general case algorithmically undecidable. The temporal logic is more typically related to propreties under the question.
Considering limited info you shared about your project, why do not you try Spin/Promela it is loosely inspired by C and has 'buffers' which can be considered to be arrays. At the least you might be able to simulate your system?
I'm learning Alloy, and can use check and run individually. But, when I have them both in, it seems that the check is ignored. How do I execute both the check and the run?
To expand the question:
If I have a run, do I even need a check? Won't it automatically check all my assertions? Or is the goal of the check not only to check the assertions, but to intentionally and exhaustively (within the scope) search for a counterexample?
Is the goal of run only to find an instance that meets the predicate? Or is there another usage of run?
Perhaps check should be search-counterexample and run should be search-example?
Is Alloy limited to one search (check or run) for execution? If so, is the best practice to simply comment out all but one check/run, and uncomment out one at a time?
How do I execute both the check and the run?
You don't. You do one at a time.
Given two predicates P1 and P2, it's always possible to define a new predicate to combine them however you want (with and, or, and not, =>, etc., etc.), and doing so can be very helpful sometimes.
Given a predicate P and an assertion A, however, there may be less need to check them at the same time than you think. If the assertion A holds for a given scope, then it holds whether predicate P is satisfied or not. If it always holds in that scope, then you don't need to check it in addition to P, when seeking an instance of P. (It will hold whether you check it or not.)
If I have a run, do I even need a check? Won't it automatically check all my assertions? Or is the goal of the check not only to check the assertions, but to intentionally and exhaustively (within the scope) search for a counterexample?
An assertion is checked only when you ask the Analyzer to check it. The Analyzer checks the assertion precisely (and only) by looking for counter-examples.
In this, assertions differ from Alloy facts, which are always true by definition (or: by fiat) and need not be checked. (And more than that: they cannot be checked: since a counter-example is impossible, there is nothing for the Analyzer to look for, and there is no verb by means of which you could request that the Analyzer look for it.)
The difference between facts and assertions is worth thinking about.
Facts express constraints on a model; assertions don't. Informally, an assertion can be thought of as a suggestion (or claim) that a given constraint is already imposed on the model, that it follows logically from what has already been said. Assertions which state the blindingly obvious are useful, because checking them can draw our attention to situations where those blindingly obvious things are not in fact true. Assertions which state non-obvious consequences of the constraints in a model are also useful, in a different way, drawing our attention as readers to consequences we might have overlooked.
Facts can be useful too, as simple ways to restrict the model to situations we are interested in. But since they are always true, whether redundant with other constraints or not, facts have fewer opportunities to surprise us. (The most frequent surprise I associate with facts is the unwelcome discovery that my formulation of a fact has made it impossible to find any instances of the model. Over time, I have come to avoid using facts wherever possible: anything I am tempted to write as a fact, I end up rewriting as a predicate.)
Is the goal of run only to find an instance that meets the predicate? Or is there another usage of run?
That's the only one this user of Alloy knows.
Perhaps check should be search-counterexample and run should be search-example?
You may have a point; find-example and find-counterexample might be clearer for new users. (I wouldn't like search here, at least not without -for.) But some users' fingers may rebel at replacing a five-character command like check with a twenty-one-character equivalent.
Is Alloy limited to one search (check or run) for execution? If so, is the best practice to simply comment out all but one check/run, and uncomment out one at a time?
Not necessary; the Execute menu gives you your choice of the command to execute.
i use Jess rule engine with java and i have a template person with a number of facts. I excecute a rule concerning persons and i would like to get the number of facts that satisfy the rule and made it fire. Is this possible;
e.g.Command engine.executeCommand("(run)") returns only 0 or 1 in case a rule fired
Depending on what exactly you need, there are several things you might do. The function (run) actually returns the number of rules that fired, so if each fact activates one rule, then the return value of (run) would do it.
If you need to do anything more complex, then you can register a JessEventListener to be notified when each rule fires. The JessEvent will contain the whole activation record for the rule, so you can walk through it and count the facts however you like. Since rules can match the non-existence of facts, or the existence of at least one fact that fits a pattern, etc, the question of "how many facts activated a rule" isn't completely straightforward. But with the activation record in hand, you can count them however you like.
is there any way to make the rules on an Expert System be modified by the system itself so tha t it can learn from its experiences?
-suggestions are always welcome.Thanks!
The short answer is "yes" there are ways to do that. For example, the "if" part of the rule can be dependent on a numerical value (e.g., a prior probability). When the rule is triggered, the "then" part of the rule can update the prior, which changes the rule. If you are asking about structural changes to a rule, that is also possible (you could make a rule dependent on condition assertions that may be created, modified, or removed) but the extent to which that is possible will depend on the particular expert system shell you are using.