## Wednesday, November 11, 2009

### Representing Uncertainty

In one of my earlier blog post Is AI a Possibility I discussed the need of a 3rd state. For past few days I am thinking about scenario where just returning a Boolean value ie True or False is not good enough.

Normally a function evaluates to either "True" or "False" based on whether the attributes of the entities meet the conditions defined in the rule or not. But it may happen at times that the entity does not contain the attributes required by the rule to evaluate it properly. Then in that case we need to have a 3rd (Not Available) and 4th (Not Applicable) state as rule outcome. When a function returns Not Available then the it implies that the entity does not contain the attribute needed for the rule to execute or process the object. On the other hand Not Applicable means the rule does not apply to the type of the entity in context.

So in total we have 4 return values for the function:
- True
- False
- Not Applicable
- Not Available
A Boolean value (outcome) is not the possible solution here. So we need an alternate representation here for the function result. All functions cannot evaluate to True/False. For those rules (functions) that cannot be evaluated we need to find out the what was the state (Not Applicable or Not Available). When we apply multiple rules to the same object in a sequence (workflow) the outcome is a set of conclusions. But the conclusion must include which rule was evaluated and which ones could not be evaluated.

I am still puzzled as how to represent the two more state considering that internally everything is represented as either 1 or 0 and that does not leave room for representing uncertainty.

Until Next Time....

Jha said...

Does combinations help?

e.g. 00,01,10,11 represent four possible states :)

Just a thought!

Samir Kumar Mishra said...

Yes these 4 combinations are possible but not by using only two states. That is the problem..

James said...

i think there's any number of positions you can have on a topic. i don't think it's about whether it _is_ true or false or unclear, but about _your reasons_. in any real situation you don't know the truth, you have certain sorts of (usually ambiguous) evidence, and you construct reasons for certain conclusions based on these. "there's a reasonable chance that this person likes romance movies, because three of their ten rentals were romances". "but then their other seven rentals were all action movies, so it's probably the case that they are more into action movies, which means it's also probably less the case that they are into romance movies - perhaps these were watched on a date". really, i think the "degree of certainty" is a just an abstraction of the reasons - and it's really about those reasons and how they fit together. unfortunately don't have to time to try and describe that more. too much research to do too :-). James.

Alendar said...

I'm looking at the same issue in my designs. For booleans I think we are stuck with true false, because changing the response changes the way queries have to be done. An "IF LikesMovies = true THEN" statement can't be refactored to support a maybe or sometimes response.

Set type responses could be improved, I think, with a function: IF Stat("Running") THEN" and Stat("Started") or "Stat("On Hold")
Internally the function could deal with complex states and evolve, while still responding to the simple older questions that don't recognize the new statuses.

Patrick said...

Here's an approach for tri-value logic: