Main Page | Namespace List | Class Hierarchy | Class List | File List | Namespace Members | Class Members

spot::emptiness_check Class Reference

Check whether the language of an automate is empty. More...

#include <gtec.hh>

Inheritance diagram for spot::emptiness_check:

Inheritance graph
[legend]
Collaboration diagram for spot::emptiness_check:

Collaboration graph
[legend]
List of all members.

Public Member Functions

 emptiness_check (const tgba *a, const numbered_state_heap_factory *nshf=numbered_state_heap_hash_map_factory::instance())
virtual ~emptiness_check ()
virtual bool check ()
 Check whether the automaton's language is empty.

const emptiness_check_statusresult () const
 Return the status of the emptiness-check.


Protected Member Functions

void remove_component (const state *start_delete)
 Remove a strongly component from the hash.


Protected Attributes

emptiness_check_statusecs_

Detailed Description

Check whether the language of an automate is empty.

This is based on the following paper.

@InProceedings{couvreur.99.fm, author = {Jean-Michel Couvreur}, title = {On-the-fly Verification of Temporal Logic}, pages = {253--271}, editor = {Jeannette M. Wing and Jim Woodcock and Jim Davies}, booktitle = {Proceedings of the World Congress on Formal Methods in the Development of Computing Systems (FM'99)}, publisher = {Springer-Verlag}, series = {Lecture Notes in Computer Science}, volume = {1708}, year = {1999}, address = {Toulouse, France}, month = {September}, isbn = {3-540-66587-0} }

check() returns true if the automaton's language is empty. When it return false, a stack of SCC has been built is available using result() (spot::counter_example needs it).

There are two variants of this algorithm: spot::emptiness_check and spot::emptiness_check_shy. They differ in their memory usage, the number for successors computed before they are used and the way the depth first search is directed.

spot::emptiness_check performs a straightforward depth first search. The DFS stacks store tgba_succ_iterators, so that only the iterators which really are explored are computed.

spot::emptiness_check_shy try to explore successors which are visited states first. this helps to merge SCCs and generally helps to produce shorter counter-examples. However this algorithm cannot stores unprocessed successors as tgba_succ_iterators: it must compute all successors of a state at once in order to decide which to explore first, and must keep a list of all unexplored successors in its DFS stack.


Constructor & Destructor Documentation

spot::emptiness_check::emptiness_check const tgba a,
const numbered_state_heap_factory nshf = numbered_state_heap_hash_map_factory::instance()
 

virtual spot::emptiness_check::~emptiness_check  )  [virtual]
 


Member Function Documentation

virtual bool spot::emptiness_check::check  )  [virtual]
 

Check whether the automaton's language is empty.

Reimplemented in spot::emptiness_check_shy.

void spot::emptiness_check::remove_component const state start_delete  )  [protected]
 

Remove a strongly component from the hash.

This function remove all accessible state from a given state. In other words, it removes the strongly connected component that contains this state.

const emptiness_check_status* spot::emptiness_check::result  )  const
 

Return the status of the emptiness-check.

When check() succeed, the status should be passed along to spot::counter_example.

This status should not be deleted, it is a pointer to a member of this class that will be deleted when the emptiness_check object is deleted.


Member Data Documentation

emptiness_check_status* spot::emptiness_check::ecs_ [protected]
 


The documentation for this class was generated from the following file:
Generated on Tue Jun 29 17:01:57 2004 for spot by doxygen 1.3.7