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).
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.
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)