spot  1.0.1
Modules | Classes
Emptiness-checks
TGBA algorithms

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

Detailed Description

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.


Please comment this page and report errors about it on the RefDocComments page.
Generated on Wed Jan 23 2013 15:00:02 for spot by doxygen 1.8.1.2