I’ve been learning about and experimenting a bit of late with fuzzy logic. In fact, I decided to implement a variant of it in ResponsIF. For those who don’t know, unlike in “crisp” logic where you have only two values (“true” or “false”), in fuzzy logic you have a continuum of values ranging from 0 (“false”) to 1 (“true”). A value represents a level of certainty or degree of something. For example, if you’re happy, your “happy” value might be 1. If you’re almost perfectly happy, but not quite, your “happy” value might be only 0.85. If you’re only a little bit happy, you might be down to 0.1.

Such variability comes in handy for attributes that don’t have hard edges. A person who is six feet tall would be considered tall, but how about someone only five-nine? And how about down to five-seven or five-five? As you can see, there is no clear line for “tall”, where you can say everyone above this value is tall and those below are not. There is not “you must be this tall” in life. The “tallness” attribute tapers of as height decreases. As it decreases, there is less certainty. Things become iffy. Things become fuzzy.

This blog entry came to be because I happened upon something interesting in relation to that.

In normal logic, you have certain tautologies. One of them is that “A and not A” is always false. This is so because “A” and “not A” can never both be true at the same time, and “and” requires both arguments to be true for it to be true. Similarly, “B or not B” is always true, as either “B” or “not B” will always be true, which makes the “or” true as well.

In fuzzy logic, things aren’t quite so simple.

Fuzzy logic uses “min” for “and” and “max” for “or”. That is, to compute “A and B”, you take the smaller value of “A” and “B”. To compute “A or B”, you take the larger value of “A” and “B”. These fuzzy operations happen to have the same behavior as the standard logic ones when “A” and “B” have extreme values (0 or 1). Check out the numerous truth tables on the web if you’re unsure.

In between the extremes, things aren’t so clear.

I came to think about this because, in ResponsIF, a “need” was initially considered met if the final value evaluated to 0.5 or greater. I began to think about the 0.5 case. Should 0.5 be considered met or not?

First, it occurred to me that “A and not A” when A is 0.5 evaluates to 0.5 So that means that an expression like that would actually satisfy the need at 0.5. That seemed wrong to me. “A and not A” is always false! (Or should be.)

But then I thought of “A or not A” when A is 0.5, and I realized it too is 0.5. Hmm. But “A or not A” should always be a true value. Or should it?

So when A is 0.5, both “A and not A” and “A or not A” have the same middling value.

I had a choice to make: do I consider 0.5 satisfying a need or not? I was getting no help from “and” and “or”. They were both ambiguous at 0.5. And that’s what led to my final decision: 0.5 does not satisfy a need. That’s the 50-50 case, the “it could be or it couldn’t be”. It’s just shy of a preponderance of the evidence. It isn’t anything definite.

I made the change. It might seem a bit strange to someone reading this that I pondered such a small thing at all, or for any length of time, but such tiny decisions are what go into designs like this. You have to work out the minutiae. You have to make the little decisions that sometimes end up to having large ramifications.

Sometimes pondering this level of things brings unexpected thoughts: if 0.5 is on that edge between false and true, if it’s a no-mans land, perhaps it becomes a coin toss. Perhaps when evaluating a need, if it’s 0.5, then it generates a random 50-50 result, sometimes true, sometimes false. That has some interesting ramifications which I might explore someday. In particular, I began thinking perhaps it should always be evaluated that way, as a chance. Not an “above or below this limit” but a random coin toss, where the coin is weighted by the need expression result. For example, if it evaluates to 0.8, you’d have an 80% chance of the need being considered met. Similarly, 0.1 would only give you a 10% chance. The extremes would still work as expected.

I don’t know if that makes sense at all. But it is fun to think about. It did have the result of making me start to consider whether “needs” should stop being a crisp choice at all, whether the “needs” value should just be an additional weight. That goes against its original emphasis, which is that a response allows you to configure it in both crisp and fuzzy ways. But I have to have these design crises on occasion to make sure I’m doing the right thing. Sometimes “the right thing” only becomes clear after doing something else for a while.

Like having 0.5 satisfy a need. It did and now it doesn’t.

Though sometimes I wonder if I made the right choice. It could have gone either way, really…

Oh, I don’t know.