Stutter-invariant languages¶

A language $L$ is said to be stutter-invariant iff $\ell_0\ldots\ell_{i-1}\ell_i\ell_{i+1}\ldots\in L \iff \ell_0\ldots\ell_{i-1}\ell_i\ell_i\ell_{i+1}\ldots\in L$, i.e., if duplicating a letter in a word or removing a duplicated letter does not change the membership of that word to $L$. These languages are also called stutter-insensitive. We use the adjective sutter-sensitive to describe a language that is not stutter-invariant. Of course we can extend this vocabulary to LTL formulas or automata that represent stutter-invariant languages.

Stutter-invariant languages play an important role in model checking. When verifying a stutter-invariant specification against a system, we know that we have some freedom in how we discretize the time in the model: as long as we do not hide changes of model variables that are observed by the specification, we can merge multiple steps of the model. This, combined by careful analysis of actions of the model that are independent, is the basis for a set of techniques known as partial-order reductions (POR) that postpone the visit of some successors in the model, because we know we can always visit them later.

Stutter-invariant formulas¶

When the specification is expressed as an LTL formula, a well known way to ensure it is stutter-invariant is to forbid the use of the X operator. Testing whether a formula is X-free can be done in constant time using the is_syntactic_stutter_invariant() method.

However some formula are syntactic-invariant despite their use of X. Spot implements some automaton-based check to detect stutter-invariance reliably and efficiently. This can be tested with the is_stutter_invariant() function.

Of course this is_stutter_invariant() function first checks whether the formula is X-free before wasting time building automata, so if you want to detect stutter-invariant formulas in your model checker, this is the only function to use. Also, if you hapen to already have an automaton aut_g for g, you should pass it as a second argument to avoid it being recomputed: spot.is_stutter_invariant(g, aut_g).

It is also known that any stutter-invariant LTL formula can be converted to an X-free LTL formula. Several proofs of that exist. Spot implements the rewriting of K. Etessami under the name remove_x(). Note that the output of this function is only equivalent to its input if the latter is stutter-invariant.

Stutter-invariant automata¶

Similarly to formulas, automata use a few bits to store some known properties about themselves, like whether they represent a stutter-invariant language. This property can be checked with the prop_stutter_invariant() method, but that returns a trival instance (i.e., yes, no, or maybe). Some algorithms will update that property whenever that is cheap or expliclitely asked for. For instance spot.translate() only sets the property if the translated formula is X-free.

As suggested above, we can call is_stutter_invariant() by passing a formula and its automaton, to save on one translation. A second translation is still needed to complement the automaton.

Note that prop_stutter_invariant() was updated as a side-effect so that any futher call to is_stutter_invariant() with this automaton will be instantaneous.

You have to be aware of this property being set in your back because if while playing with is_stutter_invariant() you the incorrect formula for an automaton by mistake, the automaton will have its property set incorrectly, and running is_stutter_inariant() with the correct formula will simply return the cached property.

In doubt, you can always reset the property as follows:

In case you have an automaton for which you do not have formula, you can also use is_stutter_invariant() by passing this automaton as the first argument. In that case a negated automaton will be constructed by determinization. If you do happen to have a negated automaton handy, you can pass it as a second argument to avoid that.

Explaining why a formula is not sutter-invariant¶

As explained in our Spin'15 paper the sutter-invariant checks are implemented using simple operators suchs as spot.closure(aut), that augment the language of L by adding words that can be obtained by removing duplicated letters, and spot.sl(aut) or spot.sl2(aut) that both augment the language that L by adding words that can be obtained by duplicating letters. The default is_stutter_invariant() function is implemented as spot.product(spot.closure(aut), spot.closure(neg_aut)).is_empty(), but that is just one possible implementation selected because it was more efficient.

Using these bricks, we can modify the original algorithm so it uses a counterexample to explain why a formula is stutter-sensitive.

Note that a variant of the above explanation procedure is already integerated in our on-line LTL translator tool (use the study tab).

Detecting stutter-invariant states¶

Even if the language of an automaton is not sutter invariant, some of its states may recognize a stutter-invariant language. (We assume the language of a state is the language the automaton would have when starting from this state.)

First example¶

For instance let us build a disjunction of a stutter-invariant formula and a stutter-sensitive one:

While the automaton as a whole is stutter-sensitive, we can see that eventually we will enter a sub-automaton that is stutter-invariant.

The stutter_invariant_states() function returns a Boolean vector indiced by the state number. A state is marked as True if either its language is stutter-invariant, or if it can only be reached via a stutter-invariant state (see the second example later). As always, the second argument, f, can be omitted (pass None) if the formula is unknown, or it can be replaced by a negated automaton if it is known.

For convenience, the highligh_...() version colors the stutter-invariant states of the automaton for display. (That 5 is the color number for red in Spot's hard-coded palette.)

Such a procedure gives us a map of where POR can be enabled when model checking using this automaton.

Second example¶

This second example illustrates the fact that a state can be marked if it it not sutter-invariant but appear below a stutter-invariant state. We build our example automaton as the disjuction of the following two stutter-sensitive formulas, whose union is equivalent to the sutter-invariant formula GF!a.

Here are the automata for g1 and g2, note that none of the states are stutter-invariant.

Now we build the sum of these two automata. The stutter-invariance check detects that the initial state is stutter-invariant (i.e., the entire language is stutter-invariant) so all states below it are marked despite the fact that the language recognized from these individual states would not be stutter-invariant.

Third example¶

These procedures work regardless of the acceptance condition. Here is an example with co-Büchi acceptance.

In this case we do not even have a formula to pass as second argument, so the check will perform a complementation by determinization.

If the negated automaton is already known, it can be passed as second argument (instead of the positive formula) to avoid unnecessary work.

Sutter-invariance at the letter level¶

Instead of marking each state as stuttering or not, we can list the letters that we can stutter in each state. More precisely, a state $q$ is stutter-invariant for letter $a$ if the membership to $L(q)$ of any word starting with $a$ is preserved by the operations that duplicate letters or remove duplicates.

$(\ell_0\ldots\ell_{i-1}\ell_i\ell_{i+1}\ldots\in L(q) \land \ell_0=a) \iff (\ell_0\ldots\ell_{i-1}\ell_i\ell_i\ell_{i+1}\ldots\in L(q)\land \ell_0=a)$

Under this definition, we can also say that $q$ is stutter-invariant iff it is stutter-invariant for any letter.

For instance consider the following automaton, for which all words that start with $b$ are stutter invariant. The initial state may not be declared as stutter-invariant because of words that start with $\lnot b$.

The stutter_invariant_letters() functions returns a vector of BDDs indexed by state numbers. The BDD at index $q$ specifies all letters $\ell$ for which state $q$ would be stuttering. Note that if $q$ is stutter-invariant or reachable from a stutter-invariant state, the associated BDD will be bddtrue (printed as 1 below).

This interface is a bit inconveniant to use interactively, due to the fact that we need a spot.bdd_dict object to print a BDD.

The set of stutter-invariant states is not always forward closed¶

Consider the following automaton, which is a variant of our second example above.

The language accepted from state (2) is !GF(a & Xa) & GF!a (this can be simplified to FG(!a | X!a)), while the language accepted from state (0) is GF(a & Xa) & GF!a. Therefore. the language accepted from state (5) is a & X(GF!a). Since this is equivalent to a & GF(!a) state (5) recognizes stutter-invariant language, but as we can see, it is not the case that all states below (5) are also marked. In fact, states (0) can also be reached via states (7) and (6), recognizing respectively (a & X(a & GF!a)) | (!a & X(!a & GF(a & Xa) & GF!a)) and !a & GF(a & Xa) & GF!a)), i.e., two stutter-sentive languages.

This situation can be tested with spot.is_stutter_invariant_forward_closed(). The function returns -1 if the successor of any stutter-invariant state is it is also a stutter-invariant state, otherwise it return the number of one stutter-sensitive state that has a stutter-invariant state as predecessor.

In cases where we prefer to have a forward-closed set of stutter-invariant states, it is always possible to duplicate the problematic states. The make_stutter_invariant_foward_closed_inplace() modifies the automaton in place, and also returns an updated copie of the vector of stutter-invariant states.

Now, state 0 is no longuer a problem.

Let's see how infrequently the set of stutter-invarant states is not closed.

There is no instance of set of stutter-invariant states that is not closed in these example formulas.

Here is the percentage of stutter-invarant states.