Fuzzy Inference Systems

Model uncertainty, evaluate complex systems, decide with confidence

This page is about the machine itself: what happens between the numbers you feed in and the single number that comes out, and how each stage of that journey can be defended.

The system on the poster has four stages. Crisp inputs enter fuzzification and become degrees of membership in linguistic sets. The rule base — a list of if-then statements written by someone who knows the domain — fires every rule whose conditions are partly satisfied. The inference engine, Mamdani or Sugeno, combines those firings. Defuzzification collapses the aggregate back to one number by centroid, bisector or mean of maxima.

The concrete example on the artwork is a sustainable concrete mix: cement content, water-to-binder ratio, fly ash percentage and compressive strength go in as linguistic values; a sustainability score between zero and one hundred comes out. The rule shown — if cement is low and water-binder is low and fly ash is high and strength is high, then sustainability is high — is exactly the kind of statement an engineer can read, argue with and correct.

That readability is the reason to use Mamdani inference for evaluation problems. A neural network might predict the same score more accurately and nobody could say why. A fuzzy system that a domain expert can audit line by line is often worth more than a black box that is slightly better on the test set.

Reading a control surface properly

The three-dimensional surface is the single most useful diagnostic a fuzzy system produces. It plots the output against two inputs across their whole range, and it exposes problems that no table of rules will reveal: flat plateaus where the system has stopped responding, sharp cliffs where a small change in input flips the output, and corners that no rule covers.

A surface with a large flat region usually means the term sets are too coarse, or that several rules give the same output and are drowning out the ones that differentiate. A cliff usually means two adjacent rules disagree sharply with no intermediate rule between them. Both are fixable, and both are invisible if you only look at the defuzzified answer for a few test cases.

We generate the surfaces for every pair of inputs as a matter of course, read them with you, and adjust the rule base where they show something the design did not intend. A thesis that includes these surfaces and discusses them demonstrates that the author understood their own model.

Decision support that someone will actually use

A fuzzy system that lives only in a thesis chapter has done half its job. Where the work is meant to support real decisions — supplier selection, maintenance prioritisation, risk ranking — it needs an interface a non-specialist can operate and an output they can act on.

We build that as a simple spreadsheet or a small application: the inputs as sliders or dropdowns in the language the user actually speaks, the output as a score with the firing rules listed beneath it so the answer can be questioned. Being able to say which rules produced a recommendation is what earns a fuzzy system its place over a regression.

It also needs maintenance. Membership functions calibrated on data from three years ago drift. We document how they were derived so that they can be recalibrated later by someone else, rather than becoming an unmaintainable artefact once the author has moved on.