Utilizing hedges

[Unknown]

Trying to understand how to implement hedges using QT. I can see & add them in the Rule Blocks area, but they don’t appear in the engine configuration. Nor do they appear to have any impact one way or another. What am I missing? How do I put the hedges to effective use?

Thanks!

[Juan Rada-Vilela (admin)]

Hi,

can you please elaborate a bit more? What version of QtFuzzyLite are you using?

Hedges are used in rules as:
if A is very LOW then Z is seldom HIGH, where very and seldom are hedges.

[Unknown]

Sure: QtFuzzyLite-5.0b1408

I have a rule: if Speed is Low and Distance is Short then BrakePressure is Light

Given a certain set of inputs, I get an output, as expected. Then I edit the rule and add a hedge: if Speed is Low and Distance is Short then BrakePressure is somewhat Light

Given the same set of inputs as the first test, I get exactly the same degree of rule firing and exactly the same output value as in the first test. The “somewhat” hedge doesn’t appear to have any impact on the output calculation.

When I export the engine, there is no reference to hedges (other than seeing the word “somewhat” in the rule definition of the FLL export, for example). But the FIS output is exactly the same whether the “somewhat” hedge is in the rule or not.

Thanks for any insight you might be able to provide.

[Juan Rada-Vilela (admin)]

Hi,

thanks for your feedback. Unfortunately, without a concrete example to test, I cannot help you much. If you can, post the FLL code and I will check it out.

If you do the same on the SimpleDimmer.fll, you will see the difference.

Important to notice is that Hedges on the consequent of a rule will not change the activation degree of the rule. The activation degree will be modified only by hedges in the antecedent.

[Unknown]

Thanks for straightening me out, Juan.

My sense of the language of hedges (as opposed to the fuzzy logic implementation of hedges) is somewhat different than what I find in fuzzylite. For example, I see that the formula to apply “very” is x^2. Since the membership function is always <= 1.0, as a practical matter this means that “very” is always less than x? That makes sense if x represents some variable at the small/low/slow side of the continuum. In this case, “very” is smaller/lower/slower than small/low/slow.

But if x represents something on the big/high/fast side of the continuum, shouldn’t “very” mean bigger than x? Bigger/higher/faster than big/high/fast?

So if the input continuum is running from left-to-right (0 to 55; low to high), all the input variables left of the centerpoint might have a hedge hierarchy like [extremely/very/quite * low * moderately/fairly/somewhat] while the input variables to the right of the centerpoint might have a hedge hierarchy like [somewhat/fairly/moderately * high * quite/very/extremely]. Variables that straddle the centerpoint are a tossup, linguistically speaking.

Anyway, this is why I was inquiring about the capability to build our own hedges.

Thanks.

[Juan Rada-Vilela (admin)]

Hi Stephen,

I find this fascinating. A long time ago this precise issue briefly came to my attention, but did not think too much about it as I had many others to think of. I agree with you on the need to create hedges that better match our expectations of natural language, and this is something I would be fond of discussing what the best approach would be to incorporate it into the next version of fuzzylite.

What you mention using a hierarchy is interesting, but is not generic enough. This would make sense if we have a negative-to-positive set of terms like lo-med-hi, but would not apply for sets expressed as fast-faster-fastest, for example. I am inclined towards leaving this option to be set manually, creating positive and negative hedges. An idea would be “very-” and “very+”, where “very-“=x^2 and “very+”=\sqrt{x}.

Lastly, have in mind that hedges were originally conceived to affect the antecedent of the rule, which they do unambiguously (yet not as intuitively). The possibility of adding a hedge to the consequent is thanks to the design of fuzzylite. You can create any number of hedges and seamlessly incorporate them into fuzzylite by registering them in the HedgeFactory.

[Unknown]

Always happy to kick around ideas. I like the “very-” / “very+” idea; allows for context to be considered. Perhaps a generic set of hedge—, hedge–, hedge-, hedge+, hedge++, hedge+++ that can be named dynamically as part of creating the rule block. The formulae are fixed, but the names are user-definable.

Need to learn more Java before I can start registering my own hedges with HedgeFactory. 🙂

[Unknown]

Hi Juan.

I can envision something like this:

hedge— = “somewhat” {x – 0.50} (capped at x = 0.00)
hedge– = “fairly” {x – 0.30} (capped at x = 0.00)
hedge- = “moderately” {x – 0.10} (capped at x = 0.00)
hedge+ = “ESPECIALLY” {x + 0.10} (capped at x = 1.00)
hedge++ = “VERY” {x + 0.30} (capped at x = 1.00)
hedge+++ = “EXTREMELY” {x + 0.50} (capped at x = 1.00)

and so forth. All minus hedges have lowercase linguistic tokens; all plus hedges have UPPERCASE linguistic tokens. So I could define both “extremely” and “EXTREMELY” in the same Rule Block and the hedge adjustment applied would be different (one minus; one plus). The actual linguistic token values can be anything the developer wants to use for this Rule Block.

Cheers.

[Author]

Posts