Simplify membership functions in our demonstration fcl files

[umeshsarkar]

this MR will solve the issues:

Use singleton membership functions in case of simple ordinal scales -
#66

DEFUZZIFY term can be modeled in a simpler way - #58

Simplify membership functions in our Demonstration FCL files - #55

[gr-hovest-atb]

Just to understand: is this change due to the simplified modelling of membership functions? On first glance this should not change the result, but maybe it is because of the Singleton approach for defuzzification?

[umeshsarkar]

I have looked this in detail and I found that the the COGS calculation is returning something like 3.0000000000000004 but singleton value expects something like 3.0, that`s why the wrong approach is selected.

The current code passes the value directly to the singleton membership function https://github.com/AI4WORK-Project/sliding-work-sharing/blob/main/src/main/java/eu/ai4work/sws/service/RuleEngineService.java#L101

.membership(resultAsFuzzyVariable.getLatestDefuzzifiedValue())

so 3.0000000000000004 does not match the singleton value 3.0. Because of that, none of the output terms gets a membership value of 1, and the wrong linguistic term is selected.

Since our output uses numbers such as 1, 2, and 3, I think a simple fix would be to round the defuzzified value before checking the membership: https://github.com/AI4WORK-Project/sliding-work-sharing/blob/55-simplify-membership-functions-in-our-demonstration-fcl-files/src/main/java/eu/ai4work/sws/service/RuleEngineService.java#L101

.membership(Math.round(resultAsFuzzyVariable.getLatestDefuzzifiedValue()))

this correctly matches the 3 and returns the letRobotContinue.

this change done in commit a559e73

[gr-hovest-atb]

My impression is that our previous approach, i.e.

• first get membership values for all terms
• then select the term for which membership is max
  does not really work for the singleton approach, because the defuzzification step already does a similar thing by selecting an integer value (except for the described rounding issue), so membership values will either be 0 or 1.

That being said, the introduced Math.round fixes this situation, but it could lead to distorted results in case of non-singleton COG defuzzification. To be discussed if non-singleton/COG is actually required for implementation of our SWS concept.

[umeshsarkar]

That is true that using the Math.round will break the non-singleton/COG. In the commit a4cddc4 the support for both COG and COGS added and works for both discrete (COGS) and continuous defuzzification (COG).

For discrete outputs, such as COGS with singleton terms, it directly reads the activation degree of the singleton from the discrete defuzzifier.

For continuous outputs, such as normal COG, it keeps the existing behavior: it takes the final defuzzified value and checks which value belongs to the current membership function.

Math.round() is not used because for singleton outputs, rounding is also not needed because we can directly read the activation degree of the singleton instead of trying to match the defuzzified value back to the singleton position. This also avoids floating-point issues such as 3.0000000000000004 instead of exactly 3.0.

[gr-hovest-atb]

This is very cryptic, could you please add a comment that explains what valueX and what the index 0 mean?

[umeshsarkar]

I try to improve the comment in the commit 2efb531