spot
1.2.6
|
Modules | |
Emptiness-check algorithms for SSP | |
Emptiness-check algorithms | |
TGBA runs and supporting functions | |
Emptiness-check statistics | |
Classes | |
class | spot::emptiness_check_result |
The result of an emptiness check. More... | |
class | spot::emptiness_check |
Common interface to emptiness check algorithms. More... | |
class | spot::emptiness_check_instantiator |
All emptiness-check algorithms follow the same interface. Basically once you have constructed an instance of spot::emptiness_check (by instantiating a subclass, or calling a functions construct such instance; see this list), you should call spot::emptiness_check::check() to check the automaton.
If spot::emptiness_check::check() returns 0, then the automaton was found empty. Otherwise the automaton accepts some run. (Beware that some algorithms—those using bit-state hashing—may found the automaton to be empty even if it is not actually empty.)
When spot::emptiness_check::check() does not return 0, it returns an instance of spot::emptiness_check_result. You can try to call spot::emptiness_check_result::accepting_run() to obtain an accepting run. For some emptiness-check algorithms, spot::emptiness_check_result::accepting_run() will require some extra computation. Most emptiness-check algorithms are able to return such an accepting run, however this is not mandatory and spot::emptiness_check_result::accepting_run() can return 0 (this does not means by anyway that no accepting run exist).
The acceptance run returned by spot::emptiness_check_result::accepting_run(), if any, is of type spot::tgba_run. This page gathers existing operations on these objects.