Background
Simple Example Using Only Jess Code
Simple Example Results
Certainty Factors
Mixed Jess and Java Code
Java Beans and Jess Shadow Facts with Fuzzy Slots –
special consideration
How to Use the Fuzzy Extensions with Jess
Summary of the FuzzyJess Functions
The NRC
FuzzyJ Toolkit can be used to create Java programs that encode fuzzy operations
and fuzzy reasoning. However, a rule based expert system shell provides a
convenient and suitable way to encode many types of applications. Fuzzy logic
programs fit nicely into the rule based paradigm. The work on the FuzzyJ
Toolkit follows from experience in building an extension to the CLIPS rule
based expert system shell. This extension provided fuzzy facts as well as the
standard crisp facts in CLIPS
and is called FuzzyCLIPS.
The work on the FuzzyJ Toolkit started as an exercise to provide a similar
capability for Jess, a Java
version of CLIPS. One of the weaknesses (and strengths) of FuzzyCLIPS was that
the implementation was seamlessly integrated with the CLIPS language. The syntax
was extended in a compatible way and the parsers etc. were modified to allow a
quite natural extension to CLIPS. This meant that the CLIPS code was modified
in many places (in quite complex ways at times) and this led to the difficulty
of maintaining new releases of FuzzyCLIPS every time a new version of CLIPS
emerged. At this time FuzzyCLIPS has stopped evolving at compatibility with
version 6.10 of CLIPS because it requires too much effort (for a single person)
to maintain with a reasonable degree of quality. It appeared to be more
reasonable to expend the effort to create a portable set of classes in Java and
link these with Jess. This fits well with the concept of Jess. There is no
object system (like the COOL of CLIPS) provided in Jess. Instead it is well
integrated with the objects of Java. This provides a good mix between an object
system and a rule based system allowing one to do the
most appropriate things in each. The challenge has been to provide an
integration of the FuzzyJ Toolkit and Jess, providing many of the capabilities
of a FuzzyCLIPS, while minimizing the code changes to Jess classes. What we
describe here is the result of this effort, what we call FuzzyJess. Of course
there have been tradeoffs and the syntax from FuzzyCLIPS did not survive, but
the result is in many ways better and more flexible, allowing users to be more
creative and making it much simpler to maintain.
A small
example will serve to introduce the basic concepts for creating fuzzy rules in
Jess. In this example everything is done using only Jess code. There is quite a
bit of opportunity to create code that is a mix of Jess and Java, but Jess can
easily reference Java classes and this allows one to work entirely in Jess when
appropriate. This example is pretty much identical to the one we coded in the
section on FuzzyRules (Simple Example
using Java code) where we only used Java. An assumption is made that the reader
has a reasonable knowledge of Jess and has at least a basic understanding of
the FuzzyJ Toolkit (Fuzzy Variables, Fuzzy Values, and FuzzyRules).
In English-like syntax the rule being implemented can be written as:
if temperature is hot
then
pressure is low or medium
Then by
providing an input value for the temperature, in this case temperature is very medium, the rule can
be fired and a fuzzy conclusion is provided as the output of the rule firing.
;; Two globals
to hold our two FuzzyVariables for temperature and pressure
(defglobal ?*tempFvar* = (new nrc.fuzzy.FuzzyVariable
"temperature" 0.0 100.0 "C"))
(defglobal ?*pressFvar* = (new nrc.fuzzy.FuzzyVariable
"pressure" 0.0 10.0 "kilo-pascals"))
;; An initialization
rule that adds the terms to the FuzzyVariables and
;; asserts the input FuzzyValue 'temperature is very
medium'
(defrule init
=>
(load-package nrc.fuzzy.jess.FuzzyFunctions)
(bind ?xHot (create$ 25.0
35.0))
(bind ?yHot (create$ 0.0
1.0))
(bind ?xCold (create$ 5.0
15.0))
(bind ?yCold (create$ 1.0 0.0))
;; terms for the temperature
Fuzzy Variable
(?*tempFvar* addTerm
"hot" ?xHot ?yHot 2)
(?*tempFvar* addTerm
"cold" ?xCold ?yCold 2)
(?*tempFvar* addTerm "veryHot"
"very hot")
(?*tempFvar* addTerm
"medium" "not hot and (not cold)")
;; terms for the pressure Fuzzy
Variable
(?*pressFvar* addTerm
"low" (new nrc.fuzzy.ZFuzzySet 2.0 5.0))
(?*pressFvar* addTerm
"medium" (new nrc.fuzzy.PIFuzzySet 5.0 2.5))
(?*pressFvar* addTerm
"high" (new nrc.fuzzy.SFuzzySet 2.0 5.0))
;; add the fuzzy input -- temperature is very medium
(assert (theTemp (new
nrc.fuzzy.FuzzyValue ?*tempFvar* "very medium")))
)
;; the rule
'if temperature hot then pressure low or medium'
(defrule temp-hot-press-lowOrMedium
(theTemp ?t&:(fuzzy-match
?t "hot"))
=>
(assert (thePress (new
nrc.fuzzy.FuzzyValue ?*pressFvar* "low or medium")))
)
;; a rule to
print some interesting things
(defrule do-the-printing
(theTemp ?t)
(thePress ?p)
=>
(printout t "Temp is:
" (?t toString) crlf "Press is: " (?p toString) crlf)
(bind ?theFzVals
(create$ (new nrc.fuzzy.FuzzyValue ?*tempFvar* "hot") ?t)
)
(printout t (call nrc.fuzzy.FuzzyValue
plotFuzzyValues "*+" ?theFzVals) crlf)
(printout t (call (new
nrc.fuzzy.FuzzyValue ?*pressFvar* "low or medium")
plotFuzzyValue "*") crlf)
(printout t (?p plotFuzzyValue
"*") crlf)
)
The
first part is pretty straightforward; create the FuzzyVariables we need to
represent the concepts of temperature and pressure. We store these in global
variables. Do note that the code will look much less complicated if we use the import
function of Jess since we could then just use FuzzyVariable and FuzzyValue etc.
rather than nrc.fuzzy.FuzzyVariable (package names dropped).
Then we have an initialization rule that adds the appropriate terms to the FuzzyVariables so we can describe our concepts. We add many more terms than we need for the example but it does show various ways to define the terms. Nothing too weird here or hard to understand if you check out the addTerm method for a FuzzyVariable in the API documentation and you know that the load-package function loads some necessary user functions (such as fuzzy-match) that support fuzzy capabilities. The last thing to be done in the init rule is to assert a temperature fact that has a FuzzyValue in it. We used an ordered fact in this case but slots in unordered facts can also hold FuzzyValues.
The next rule is the heart of the program. Notice that it is quite compact and not too difficult to read the intent. It is not quite as clean as a FuzzyCLIPS rule (for those of you familiar with FuzzyCLIPS) but is still pretty simple. In FuzzyCLIPS it would have been:
(defrule temp-hot-press-lowOrMedium
(temperature hot)
=>
(assert (pressure low or
medium))
)
Note
the lack of strings for "hot" and "low or medium". Also
there is no function (fuzzy-match) required to compare the fuzzy pattern
"hot" to the fuzzy value in the input, This comparison is implicit
and the parse of FuzzyCLIPS generates some internal code to do this. However,
in some sense one might argue that the FuzzyJess code is easier to understand.
So, what is happening here? When a temperature fact is asserted that has a
FuzzyValue in it, the fuzzy-match will compare the FuzzyValue in the fact to the
FuzzyValue hot.
In this case the fuzzy-match function will succeed since there is overlap
between the two FuzzyValues. Internally Jess will remember the pair of FuzzyValues that
matched and will use them when the rule fires and tries to assert other facts
with FuzzyValues. The default value for matching is that the intersection of
the two fuzzy values must have a maximum value greater than 0. In other words
if they intersect at all they match enough to allow the function to return
true. A user can change this behaviour by setting the tolerance for fuzzy matching to be
greater than 0. This is done using the static method of the FuzzyValue class.
In Jess one would do,
(call nrc.fuzzy.FuzzyValue setMatchThreshold 0.2)
for example. This has the effect of
strengthening the matching requirement. Here again it is the user who must
determine the meaning of such an act.
On the right hand side nothing special occurs unless theTemp fact with a fuzzy value in it is asserted. In the example we have such a fact asserted:
(theTemp (new nrc.fuzzy.FuzzyValue ?*tempFvar* "very medium"))
At this point a number of things are done. Using all of the remembered antecendent/input pairs that matched on the LHS (left hand side) of the rule, a FuzzyRule is constructed (if it has not already been constructed by another assert on the RHS (right hand side) of the rule). The FuzzyValues identified in the fact being asserted are added as outputs for the FuzzyRule and it is fired, producing the actual FuzzyValues that will be placed in the FuzzyValue positions of the asserted fact. In our case, the antecedent and the input FuzzyValues are temperature hot and temperature very medium. They overlapped and were remembered and used to construct the FuzzyRule. The output FuzzyValue from the assert function, pressure low or medium, is added to the rule and it is fired. The output FuzzyValue is then placed into the actual fact that is asserted. The results are shown below. This might sound complicated but the FuzzyJess user does not need to be aware of all of these details. The user simply needs to know that it is necessary to use the fuzzy-match function on the RHS of a rule to match FuzzyValues and that assertions done on the LHS of a rule that have FuzzyValues in them will automatically be adjusted to account for fuzzy matching on the LHS of the rule.
There are a few other things to mention here. First is that in Java we can specify one of two methods for doing the inferencing when a FuzzyRule is executed. These are the MamdaniMinMaxMinRuleExecutor, the LarsenProductMaxMinRuleExecutor and the TsukamotoRuleExecutor. This is covered in more detail in Rule Executors in the section on FuzzyRules. When a FuzzyRule is constructed in Jess, it uses the default RuleExecutor to determine how to perform the inferencing. In Jess one can change the FuzzyRuleExecutor that is used by using the static FuzzyRule method setDefaultRuleExecutor or (as of version 1.5 of FuzzyJ/FuzzyJess) one can use a Jess function, set-default-fuzzy-rule-executor. To get the results shown below one would need to do something like the following after loading the program into FuzzyJess.
1.
(reset)
2. (run)
<--- uses the initial default MamdaniMinMaxMinRuleExecutor
3. (reset)
4. (call
nrc.fuzzy.FuzzyRule
setDefaultRuleExecutor (new nrc.fuzzy.LarsenProductMaxMinRuleExecutor))
5. (run)
This executes
the rules once with each of the inferencing techniques. Step 4 could have been
done using the set-default-fuzzy-rule-executor FuzzyJess
function. The allowed values for the argument to this function are mamdanimin,
larsenproduct or tsukamoto.
(set-default-fuzzy-rule-executor larsenproduct)
A second consideration (although we don’t find it in this example) is that, when there are multiple FuzzyValues on the LHS of the rule that are matched using the fuzzy-match function, the FuzzyRule created will have multiple antecedents. This means that we can, if desired, specify the operator (minimum, product, etc.) to be used to combine the results of the matches of the individual antecedent/input pair matches (see the details of this in the FuzzyRules section). Again this can be done in two ways: using a static method, setDefaultAntecedentCombineOperator, or (as of version 1.5 of FuzzyJ/FuzzyJess) a FuzzyJess function, set-default-antecedent-combine-operator. So we could do:
(call
FuzzyRule setDefaultAntecedentCombineOperator (new
ProductAntecedentCombineOperator))
or
(set-default-antecedent-combine-operator product)
This would cause the match values for the antecedent/input pairs to be combined by multiplying their values, rather than the default method of taking the minimum of the values. Using the FuzzyJess function is simpler and provided for convenience but it only supports setting the combine operator to one of those supplied by FuzzyJ. If a user defines her own AntecedentCombineOperator then the (call FuzzyRule …) version would have to be used.
The final item of interest is the Global Contribution of FuzzyValues that are created. This, again, is described in more detail in the FuzzyRule section (Global Contribution). Basically if there already exists the same FuzzyValue when a new one is asserted, then the two are combined to aggregate the contribution that each has made to the solution. In our example this is not the case, but it is important to note that this will happen automatically in FuzzyJess (as it does in FuzzyCLIPS). It is also important to understand what is meant when we say the FuzzyValues are the same. In fact the FuzzyJess system will look for another fact that is identical in all of the non-fuzzy components and has FuzzyValues with the same FuzzyVariable in the other components of the fact. It will then identify these to be the same and perform the global contribution of these facts. Our example could be easily extended to see this result. If we added the rule:
(defrule temp-medium-press-high
(theTemp ?t&:(fuzzy-match
?t "medium"))
=>
(assert (thePress (new
nrc.fuzzy.FuzzyValue ?*pressFvar* "high")))
)
In this
case both rules, temp-medium-press-high and temp-hot-press-lowOrMedium, would
fire. Since each asserts a thePress fact with a FuzzyValue for pressure, the two outputs will
be combined and the output will reflect this combination (by default the union)
of the FuzzyValues. Prior to version 1.5 of FuzzyJess, the union was the only
possibility for combining FuzzyValues. In Java the user takes care of the
global contribution by explicitly doing a union or some other operation. But in
FuzzyJess since it is done automatically for the user, union was the default
and only choice. Now there are three options provided to the user: fuzzy union,
fuzzy sum, or none. The choices can be extended if desired by providing an
implementation of a nrc.fuzzy.jess.GlobalContributionOperator,
but the three choices are likely to be sufficient for almost any system. To
specify the operation to use when doing the global contribution of FuzzyValues
one can do:
(call
(engine) setFuzzyGlobalContributionOperator (new SumGlobalContributionOperator))
or
(set-default-antecedent-combine-operator sum)
The valid arguments for the FuzzyJess function set-default-antecedent-combine-operator are union, sum and none.
There is one final comment on the setting of the operator for Global Contribution or for Antecedent Combining or the choosing of the desired Rule Executor. These can be done at any time in the execution of the program. They take effect when an assert is done for a fact having one or more FuzzyValues. This means that it is possible to have facts asserted in the same RHS of a rule using different values for these options. For example, one could set the RuleExecutor to mandamimin, assert a fact with FuzzyValues, set the RuleExecutor to larsenproduct and then assert another fact with FuzzyValues. This would be an extremely unusual thing to do but in some specific case might make sense. With this flexibility comes responsibility. Be sure you understand what the implications of such actions are.
Of course it is possible to create rules with many FuzzyValue patterns on the LHS and many FuzzyValues asserted in facts on the RHS. These can be mixed with non-fuzzy facts and various tests. With minimal internal modifications to Jess and the FuzzyJess function (fuzzy-match), much of the essence of FuzzyCLIPS is captured.
The
Jess rules in the example would produce the following graphs as output (the
first 2 graphs appear on each run of the rule set and one of the last 2 graphs
will appear, depending on the inferencing technique that is being used). Note
too that when displaying these text plots it is necessary to use a mono-spaced
(non-proportional) font. The standard Jess Console does not and the plots will
look incorrect.
The
Antecedent (hot) and the input (very medium) fuzzy values
Fuzzy Value:
temperature
Linguistic Value: hot (*),
very medium (+)
1.00
+++++++++++ ****************
0.95
0.90
*
0.85
0.80
+
+ *
0.75
0.70
*
0.65
+ +
0.60
*
0.55
0.50
+
+ *
0.45
0.40
*
0.35
+
+
0.30
*
0.25
+
+
0.20
*
0.15
+
+
0.10
+
* +
0.05
+
+
0.00+++++++*******************
+++++++++++++++++
|----|----|----|----|----|----|----|----|----|----|
0.00
10.00 20.00
30.00 40.00 50.00
The conclusion fuzzy value.
Fuzzy Value:
pressure
Linguistic Value: low or medium (*)
1.00************
***
0.95
* * *
0.90
* * *
0.85
*
0.80
* *
0.75
*
0.70
*
0.65
* *
0.60
0.55
* * *
0.50
0.45
*
0.40
* *
0.35
0.30
0.25
*
0.20
0.15
*
0.10
*
0.05
*
0.00
**************
|----|----|----|----|----|----|----|----|----|----|
0.00 2.00
4.00 6.00
8.00 10.00
The output using MamdaniMinMaxMinRuleExecutor
Fuzzy Value:
pressure
Linguistic Value: ???
(*)
1.00
0.95
0.90
0.85
0.80
0.75
0.70
0.65
0.60
0.55
0.50
0.45
0.40*********************************
0.35
0.30
0.25
*
0.20
0.15
*
0.10
*
0.05
*
0.00
**************
|----|----|----|----|----|----|----|----|----|----|
0.00
2.00 4.00
6.00 8.00 10.00
The conclusion using LarsenProductMaxMinRuleExecutor.
Fuzzy Value:
pressure
Linguistic Value: ???
(*)
1.00
0.95
0.90
0.85
0.80
0.75
0.70
0.65
0.60
0.55
0.50
0.45
0.40************
*
0.35
*** *** ***
0.30
* * *
0.25
* * *
0.20
* * *
0.15
** *
0.10
*
0.05
**
0.00
***************
|----|----|----|----|----|----|----|----|----|----|
0.00
2.00 4.00
6.00 8.00 10.00
This
topic is covered with some examples in the special section on Certainty Factors, with a full example in Jess
only code. There we explain two FuzzyJess user defined functions, (fuzzy-rule-similarity) and (fuzzy-rule-match-score).
If you have
mastered (at least the simple examples) of Jess only programs and Java only
programs using the FuzzyJ Toolkit, then you will appreciate the potential of
mixing the two in quite powerful ways. There are too many possibilities to
tackle here (perhaps more insight will be added at a later time) so we leave it
by pointing to the examples included with the toolkit, especially the fuzzy
shower examples (completely Java and a mix of Jess and Java) and the so-called
Fuzzy Compiler example (compiles a set of rules and the output from a range of
inputs into a table).
The following indented and reduced size text applies to FuzzyJess prior to version 1.10. In the version 1.10 and later changes were made that remove the requirement to do anything special for Java Beans with Fuzzy properties. It is important to upgrade to 1.10 or later if you use Java Beans with FuzzyValues since changes to Jess have led to incorrect operation of the shadow fact updates.
In Jess when a
fact is asserted that is ‘identical’ to an existing fact nothing happens since
duplicate facts are not allowed. In FuzzyJess where slots can have FuzzyValues
facts are considered to be ‘identical’ when all of the non-fuzzy (crisp) slots
are the same (equal) and when the fuzzy values have the same FuzzyVariable. For
example, if a fact is created by the assert
(assert (fan (ID fan1) (speed (new FuzzyValue
?*speedFuzzyVar* “slow”))))
and later another assert
(assert (fan (ID fan1) (speed (new FuzzyValue
?*speedFuzzyVar* “medium”))))
is executed, then the 2 facts are considered to be
‘identical’. If these were ‘identical’ non-fuzzy facts, then the second assert
would have no effect since the fact already exists. For fuzzy facts these 2
facts are combined (global contribution) such that the crisp values are the
same and the fuzzy values are merged using a union (by default) operation. So
in effect the old (initial) fact is deleted and the new combined fact is
asserted (similar to a fact modify). This however, presents 2 problems when
using shadow facts, facts created from Java Bean classes in Jess. The first
issue is that for a Java Bean to cause an update to a shadow fact it uses the
firePropertyChange method:
m_pcs.firePropertyChange("beanAttribute",
oldAttributeValue,
newAttributeValue);
In this case if the old and new values are ‘equal’ then the slot
in the shadow fact is not updated. In the case of FuzzyValue attributes (slots)
the values are ‘equal’ when the FuzzyValues share the same FuzzyVariable, even
if the fuzzy sets for the FuzzyValues are different. This means that the slot
will not be updated and the slot values of the fuzzy slot will not be combined
as required. The solution here is to use:
m_pcs.firePropertyChange("beanAttribute",
null,
newAttributeValue);
and do a test of the values using equalsStar for the
FuzzyValues before calling the firePropertyChange method if desired. This will
ensure that the slot is updated. Well, actually it won’t in version 6.1a2 (or
earlier) of Jess since Jess internally also checks for the equality of the
slots and will not replace the slot with the new one if they are ‘equal’. This
required a change to the Jess code so that it does not block the update of the
slot. So use Jess 6.1a3 or later and do not specify an
‘oldAttributeValue’ in the call to firePropertyChange when updating
fuzzy slots.
In version 1.10 and later the FuzzyValue equals method returns true only if the FuzzyValues being compared have the same FuzzyVariable and identical FuzzySets. This means that the updating of shadow facts will occur properly for FuzzyValue properties of beans without doing anything special. In fact programs written to work with previous versions may have to be updated to work properly now. For example, if equalsStar was used to decide if a call to firePropertyChange was to be done then this code should be removed. Also one can use the ‘old’ value in the call to firePropertyChange. The equalsStar method now returns true if the FuzzyValues have the same FuzzyVariable. The handling of Global Contribution is taken care of internally.
To use
the extension with Jess is really quite simple. You need to have access to the
FuzzyJ Toolkit and FuzzyJess packages (nrc.fuzzy and nrc.fuzzy.jess). These
will have been obtained with the appropriate licence
requirements being met. Normally these will be in a Java jar file for easy
inclusion in the classpath
variable. The only other thing that is required is that instead of using the Rete object
in programs, you must use the FuzzyRete object. For convenience the classes
nrc.fuzzy.jess.FuzzyConsole and nrc.fuzzy.jess.FuzzyMain have been provided and
they can simply replace any use of jess.Console or
jess.Main.
Consider
the code for FuzzyMain:
public class FuzzyMain extends Main
{
public static void main(String[]
argv)
{
FuzzyMain m = new
FuzzyMain();
m.initialize(argv,
new FuzzyRete());
m.execute(true);
}
}
and the code for FuzzyConsole:
public class FuzzyConsole extends Console
{
public FuzzyConsole(String
name)
{
super(name, new
FuzzyRete());
}
public static void main(String[] argv)
{
new
FuzzyConsole("Fuzzy Jess Console").execute(argv);
}
}
To
start the FuzzyConsole one might execute a command line similar to the one to
start the standard Jess Console:
java -classpath "%classpath%";f:\fuzzyjtoolkit\fuzzyj15a.jar;.\
nrc.fuzzy.jess.FuzzyConsole
with appropriate entries in the
-classpath option to allow all necessary classes to be located. If you have
been able to use standard Jess then you will no doubt have little trouble using
FuzzyJess.
There
are a number of functions that have been added to FuzzyJess to make it simpler
to use. They are briefly described below. In the text of this chapter (above)
they are mentioned in the context of creating FuzzyJess programs.
(fuzzy-match FuzzyValue1 FuzzyValue2)
Returns
true if the 2 FuzzyValues have some overlapping portion that has a membership
value at least as large as the current setting of the FuzzyValue match Threshold;
both arguments can be Fuzzy Values (with the same FuzzyVariable) or one can be
a string that is a valid linguistic expression for the FuzzyVariable associated
with the FuzzyValue.
(fuzzy-rule-similarity)
Returns
a value between 0 and 1 which indicates the overall
fuzzy similarity of the patterns that matched on the left hand side (LHS) of a
rule, if the function is called from the right hand side (RHS) of a rule. If
not called from the RHS of a rule it will always return 0. The value is
determined by calculating the minimum (or product -- depends on the current
rule's antecedentCombineOperator) similarity of all of the fuzzy matches that
were made on the LHS of the rule. If there were no fuzzy matches on the LHS of
the rule a value of 1 is returned.
(fuzzy-rule-match-score)
Returns
a value between 0 and 1 which indicates the overall
fuzzy match scores of the patterns that matched on the left hand side (LHS) of
a rule, if the function is called from the right hand side (RHS) of a rule. If
not called from the RHS of a rule it will always return 0. The value is
determined by calculating the minimum (or product -- depends on the current
rule's antecedentCombineOperator) of all of the fuzzy matches that were made on
the LHS of the rule. If there were no fuzzy matches on the LHS of the rule a
value of 1 is returned. A fuzzy-match score is the maximum value of the
intersection of the 2 fuzzy values. This is different than the fuzzy-similarity
of 2 fuzzy values, which provides a more complex (and possibly more useful)
measure of the similarity of 2 fuzzy values.
(set-fuzzy-global-contribution-operator
operator)
Takes
one argument that specifies the way fuzzy global contribution should be done
when 'identical' facts with fuzzy values are asserted. The values can be one
of:
union - combine the fuzzy values
using the fuzzy union operation (this is the default).
sum - combine the fuzzy values
using the fuzzy sum operation.
none - do not combine the fuzzy
values; replace the old value with the new one.
(get-fuzzy-global-contribution-operator)
Takes
no arguments and returns an indicator of the way fuzzy global contribution will
be done when 'identical' facts with fuzzy values are asserted. The value
returned will be one of:
union - combine the fuzzy values
using the fuzzy union operation (this is the default).
sum - combine the fuzzy values
using the fuzzy sum operation.
none - do not combine the fuzzy
values; replace the old value with the new one.
(set-default-fuzzy-rule-executor executor)
Takes
one argument that specifies which fuzzy rule executor should be used when a
rule is fired. The values can be one of:
mamdanimin - use the
MamdaniMinMaxMin rule executor (this is the default).
larsenproduct - use the LarsenProductMaxMin
rule executor.
tsukamoto - use the Tsukamoto rule
executor.
(get-default-fuzzy-rule-executor)
Takes
no arguments and returns one of:
mamdanimin - the
MamdaniMinMaxMin rule executor is the default.
larsenproduct - the LarsenProductMaxMin rule
executor is the default.
tsukamoto - the Tsukamoto rule executor
is the default.
(set-default-antecedent-combine-operator
operator)
Takes
one argument that specifies which operator should be used to combine the
antecedent/input match values when a fuzzy rule is fired. The values can be one
of:
minimum - use the minimum of the
match values of the antecedent/input pairs (this is the default).
product - use the product of the
match values of the antecedent/input pairs.
CompensatoryAnd – use a special operator that
gives a value larger than the minimum (see details in the FuzzyJ API)
(get-default-antecedent-combine-operator)
Takes
no arguments and returns a value that specifies which operator will be used to
combine the antecedent/input match values when a fuzzy rule is fired. The value
returned will be one of:
minimum - using the minimum of
the match values of the antecedent/input pairs (this is the default).
product - using the product of
the match values of the antecedent/input pairs.
CompensatoryAnd – using a special operator that
gives a value larger than the minimum (see details in the FuzzyJ API)