Acceptance conditions¶

The acceptance condition of an automaton specifies which of its paths are accepting.

The way acceptance conditions are stored in Spot is derived from the way acceptance conditions are specified in the HOA format. In HOA, acceptance conditions are given as a line of the form:

Acceptance: 3 (Inf(0)&Fin(1))|Inf(2)

The number 3 gives the number of acceptance sets used (numbered from 0 to 2 in that case), while the rest of the line is a positive Boolean formula over terms of the form:

• Inf(n), that is true if and only if the set n is seen infinitely often,
• Fin(n), that is true if and only if the set n should be seen finitely often,
• t, always true,
• f, always false.

The HOA specifications additionally allows terms of the form Inf(!n) or Fin(!n) but Spot automatically rewrites those away when reading an HOA file.

Note that the number of sets given can be larger than what is actually needed by the acceptance formula.

Transitions in automata can be tagged as being part of some member sets, and a path in the automaton is accepting if the set of acceptance sets visited along this path satify the acceptance condition.

Definining acceptance conditions in Spot involves three different types of C++ objects:

• spot::acc_cond is used to represent an acceptance condition, that is: a number of sets and a formula.
• spot::acc_cond::acc_code, is used to represent Boolean formula for the acceptance condition using a kind of byte code (hence the name)
• spot::acc_cond::mark_t, is a type of bit-vector used to represent membership to acceptance sets.

In because Swig's support for nested class is limited, these types are available respectively as spot.acc_cond, spot.acc_code, and spot.mark_t in Python.

mark_t¶

Let's start with the simpler of these three objects. mark_t is a type of bit vector. Its main constructor takes a sequence of set numbers.

As seen above, the sequence of set numbers can be specified using a list or a tuple. While from the Python language point of view, using a tuple is faster than using a list, the overhead to converting all the arguments from Python to C++ and then converting the resuslting back from C++ to Python makes this difference completely negligeable. In the following, we opted to use lists, because brackets are more readable than nested parentheses.

The bits can be set, cleared, and tested using the set(), clear(), and has() methods:

Left-shifting will increment all set numbers. This operation is useful when building the product of two automata: all the set number of one automaton have to be shift by the number of sets used in the other automaton.

The different sets can be iterated over with the sets() method, that returns a tuple with the index of all bits set.

count() return the number of sets in a mark_t:

lowest() returns a mark_t containing only the lowest set number. This provides another way to iterate overs all set numbers in cases where you need the result as a mark_t.

max_set() returns the number of the highest set plus one. This is usually used to figure out how many sets we need to declare on the Acceptance: line of the HOA format:

acc_code¶

acc_code encodes the formula of the acceptance condition using a kind of bytecode that basically corresponds to an encoding in reverse Polish notation in which conjunctions of Inf(n) terms, and disjunctions of Fin(n) terms are grouped. In particular, the frequently-used genaralized-Büchi acceptance conditions (like Inf(0)&Inf(1)&Inf(2)) are always encoded as a single term (like Inf({0,1,2})).

The simplest way to construct an acc_code by passing a string that represent the formula to build.

You may also use a named acceptance condition:

The recognized names are the valid values for acc-name: in the HOA format. Additionally, numbers may be replaced by ranges of the form n..m, in which case a random number is selected in that range.

It may also be convenient to generate a random acceptance condition. Below we require between 3 and 5 acceptance sets:

The to_cnf() and to_dnf() functions can be used to rewrite the formula into Conjunctive or Disjunctive normal forms. This functions will simplify the resulting formulas to make them irredundant.

The manipulation of acc_code objects is quite rudimentary at the moment: they are easy to build, but are harder take appart. In fact we won't attempt to disassemble an acc_code object in Python: those things are better done in C++.

Operators |, |=, &, &=, <<, and <<= can be used with their obvious semantics. Whenever possible, the inplace versions (|=, &=, <<=) should be prefered, because they create less temporary acceptance conditions.

The complement() method returns the complemented acceptance condition:

Instead of using acc_code('string'), it is also possible to build an acceptance formula from atoms like Inf({...}), Fin({...}), t, or f.

Remember that in our encoding for the formula, terms like Inf(1)&Inf(2) and Fin(3)|Fin(4)|Fin(5) are actually stored as Inf({1,2}) and Fin({3,4,5}), where {1,2} and {3,4,5} are instance of mark_t. These terms can be generated with the functions spot.acc_code.inf(mark) and spot.acc_code.fin(mark).

Inf({}) is equivalent to t, and Fin({}) is equivalent to f, but it's better to use the functions spot.acc_code.t() or spot.acc_code.f() directly.

To evaluate an acceptance condition formula on a run, build a mark_t containing all the acceptance sets that are seen infinitely often along this run, and call the accepting() method.

Finally the method used_sets() returns a mark_t with all the sets appearing in the formula:

The used_inf_fin_sets() returns a pair of marks instead, the first one with all sets occuring in Inf, and the second one with all sets appearing in Fin.

If the top-level operators is a conjunct or disjunct, the following methods returns lists of clauses.

acc_cond¶

Automata store their acceptance condition as an instance of the acc_cond class. This class can be thought of as a pair (n, code), where n is an integer that tells how many acceptance sets are used, while the code is an instance of acc_code and encodes the formula over a subset of these acceptance sets. We usually have n == code.used_sets().max_set()), but n can be larger.

It is OK if an automaton declares that is uses 3 sets, even if the acceptance condition formula only uses set number 1. The extra two sets will have no impact on the language, even if they are used in the automaton.

The acc_cond objects are usually not created by hand: automata have dedicated methods for that. But for the purpose of this notebook, let's do it:

For convenience, you can pass the string directly:

The acc_cond object can also be constructed using only a number of sets. In that case, the acceptance condition defaults to t, and it can be changed to something else later (using set_acceptance()). The number of acceptance sets can also be augmented with add_sets().

Calling the constructor of acc_cond by passing just an instance of acc_code (or a string that will be passed to the acc_code constructor) will automatically set the number of acceptance sets to the minimum needed by the formula:

The above is in fact just syntactic sugar for:

The common scenario of setting generalized Büchi acceptance can be achieved more efficiently by first setting the number of acceptance sets, and then requiring generalized Büchi acceptance:

The acc_cond class has several methods for detecting acceptance conditions that match the named acceptance conditions of the HOA format. Note that in the HOA format, Inf(0)&Inf(1)&Inf(2)&Inf(3) is only called generalized Büchi if exactly 4 acceptance sets are used. So the following behavior should not be surprising:

Similar methods like is_t(), is_f(), is_buchi(), is_co_buchi(), is_generalized_co_buchi() all return a Boolean.

The is_rabin() and is_streett() methods, however, return a number of pairs. The number of pairs is always num_sets()/2 on success, or -1 on failure.

The check for parity acceptance returns three Boolean in a list of the form [matched, max?, odd?]. If matched is False, the other values should be ignored.

If the acceptance condition has some known name, it can be retrieved using the name() method. By default the name given is a human-readable string close that used in the HOA format, but with proper accents, and support for name like Streett-like or Rabin-like. The argument arg can specify a different style using the same syntax as in --format='%[arg]g' when using the command-line tools.

acc_cond contains a few functions for manipulating mark_t instances, these are typically functions that require known the total number of accepting sets declared.

For instance complementing a mark_t:

all_sets() returns a mark_t listing all the declared sets:

For convencience, the accepting() method of acc_cond delegates to that of the acc_code.
Any set passed to accepting() that is not used by the acceptance formula has no influence.

Finally the unsat_mark() method of acc_cond computes an instance of mark_t that is unaccepting (i.e., passing this value to acc.accepting(...) will return False when such a value exist. Not all acceptance conditions have an satisfiable mark. Obviously the t acceptance is always satisfiable, and so are all equivalent acceptances (for instance Fin(1)|Inf(1)).

For this reason, unsat_mark() actually returns a pair: (bool, mark_t) where the Boolean is False iff the acceptance is always satisfiable. When the Boolean is True, then the second element of the pair gives a non-accepting mark.

top_conjuncts and top_disjuncts also work on acc_cond. In this case they return tuple of acc_cond with the same number of sets.

fin_one() return the number of one color x that appears as Fin(x) in the formula, or -1 if the formula is Fin-less.

The variant fin_one_extract() consider the acceptance condition as a disjunction (if the top-level operator is not a disjunction, we just assume the formula is a disjunction with only one disjunct), and return a pair (x,c) where c is the disjunction of all disjuncts of the original formula where Fin(x) used to appear but where Fin(x) have been replaced by true, and Inf(x) by false. Also this function tries to choose an x such that one of the disjunct has the form ...&Fin(x)&... if possible: this is visible in the third example, where 5 is prefered to 2.