Working with Overlaps
Two rules overlap if they specify the same outcome in the same case. For example, suppose we have two rules specifying what to do in various combinations of variables A and B:
Each of these rules cover four combinations, for example, rule One covers the cases (a1, b1), (a1, b2), (a2, b1) and (a2, b2). One of these combinations, (a2, b2) is covered by both rules. Thus, they overlap.
Question: what colours would Statestep use for the values a2 and b2 when displaying rules One and Two? Assume they are the only rules for some event and that there are no constraints.
At first, you might think overlaps should be avoided completely. For example, if we later needed to change the outcome for the a2, b2 case above then we would need to change two rules rather than just one. However, there are two good reasons to allow rules to overlap:
- Allowing rules to overlap reduces the number of rules you need to define.
- Allowing rules to temporarily overlap reduces the number of rules you need to define.
The first reason is relatively easy to understand: If you look at Rules One and Two above, it should become clear that there is no way to change the two rules so that they cover the same seven cases and don't overlap. To cover these cases without an overlap you would need to define at least three rules. (Actually, this is true only for tabular rules - later we'll see how to define a rule using a formula.)
The second reason to allow overlaps is this: If you allow rules to overlap until you've finished defining rules to cover all the possibilities then you can still end up with fewer rules - even if you decide to change some rules later in order to get rid of any overlaps. This requires a bigger example and a bit more explanation.
To use Statestep most effectively, you will need to read the following. However, if you're only reviewing Statestep's functionality for now then you may wish to skip this and return to it later.
If you saved "activitiesNew.s2" as recommended earlier in the tutorial, now is the time to load it up again. If you didn't then load "activities.s2" and recreate this rule:
Now create another rule called "new2" and start this time by selecting the value fog for the variable Weather. Next, select breeze and calm for Wind. You can make Temperature "don't care". For the cases covered by this rule, we'll again make the outcome "read a book":
Notice how the common (purple) values indicate the area of overlap with the previous rule new1. Remember, "common" means that unselecting any of them would not only get rid of the overlap, it would also mean that new2 would no longer cover some combinations that are not covered by any other rule. So we decide not to worry about this overlap for the moment and continue defining rules.
Now, let's imagine we've finished defining rules for all possible cases and we want to get rid of the overlaps. Look back at new1 again and notice how the colours have changed because of the rules that were defined after it (well, in this case, just one: new2). In particular, note that fog is now redundant (blue). Again, this means that all of the combinations covered by rule new1 in which Weather is fog are also covered by other rules (in this case, rule new2). There is therefore no advantage in keeping this value selected. Unselect fog. You should now see all the selected values in both rules changing to unique (black) - the overlap has disappeared.
The point here is this: If we had been trying to avoid overlaps completely while defining new2, that is, if we had avoided selecting any common (purple) values, then instead of simply defining the new2 rule shown we would have needed to define several new rules to cover the same combinations. By allowing the overlap until we were finished defining all the rules, we were still able to get rid of it later in a neater way, so that we ended up with fewer rules.
Two things to note: First, in this example we were able to edit new1 to remove the overlap as soon as new2 was defined. However, in general, a value in an earlier rule may be made redundant by a combination of several later rules.
Second, things don't always work out as neatly as in this example, that is, you won't be able to get rid of all overlaps simply by unselecting redundant values. Even so, it is still a good strategy to give priority to ensuring that there are rules for every possibility and worry about overlaps later.