rename is_deterministic to is_universal
For #212. * spot/twa/twa.hh: Rename prop_deterministic() as prop_universal(), and keep the old name as deprecated. * spot/twaalgos/isdet.cc, spot/twaalgos/isdet.hh: Rename is_deterministic() as is_universal(), and add a new function for is_deterministic(). * doc/org/concepts.org, doc/org/hoa.org, doc/org/tut21.org, spot/tl/hierarchy.cc, spot/twa/twagraph.cc, spot/twaalgos/are_isomorphic.cc, spot/twaalgos/determinize.cc, spot/twaalgos/dtbasat.cc, spot/twaalgos/dtwasat.cc, spot/twaalgos/hoa.cc, spot/twaalgos/minimize.cc, spot/twaalgos/postproc.cc, spot/twaalgos/product.cc, spot/twaalgos/randomgraph.cc, spot/twaalgos/remfin.cc, spot/twaalgos/simulation.cc, spot/twaalgos/totgba.cc, spot/twaalgos/word.cc, tests/python/product.ipynb, tests/python/remfin.py: Adjust. * NEWS: Mention the change.
This commit is contained in:
Alexandre Duret-Lutz
parent
4518724a5b
commit
4a5d7a3978
24 changed files with 181 additions and 180 deletions
|
|
@ -1054,18 +1054,18 @@ better choices.
|
|||
There are actually several property flags that are stored into each
|
||||
automaton, and that can be queried or set by algorithms:
|
||||
|
||||
| flag name | meaning when =true= |
|
||||
|----------------------+----------------------------------------------------------------------------------------------|
|
||||
| =state_acc= | automaton should be considered as having state-based acceptance |
|
||||
| =inherently_weak= | accepting and rejecting cycles cannot be mixed in the same SCC |
|
||||
| =weak= | transitions of an SCC all belong to the same acceptance sets |
|
||||
| =very-weak= | weak automaton where all SCCs have size 1 |
|
||||
| =terminal= | automaton is weak, accepting SCCs are complete, accepting edges may not go to rejecting SCCs |
|
||||
| =complete= | it is always possible to move the automaton forward, using any letter |
|
||||
| =deterministic= | there is at most one run *recognizing* a word, but not necessarily accepting it |
|
||||
| =semi-deterministic= | any nondeterminism occurs before entering an accepting SCC |
|
||||
| =unambiguous= | there is at most one run *accepting* a word (but it might be recognized several time) |
|
||||
| =stutter_invariant= | the property recognized by the automaton is [[https://www.lrde.epita.fr/~adl/dl/adl/michaud.15.spin.pdf][stutter-invariant]] |
|
||||
| flag name | meaning when =true= |
|
||||
|----------------------+-------------------------------------------------------------------------------------------------------------------------------------------|
|
||||
| =state_acc= | automaton should be considered as having state-based acceptance |
|
||||
| =inherently_weak= | accepting and rejecting cycles cannot be mixed in the same SCC |
|
||||
| =weak= | transitions of an SCC all belong to the same acceptance sets |
|
||||
| =very-weak= | weak automaton where all SCCs have size 1 |
|
||||
| =terminal= | automaton is weak, accepting SCCs are complete, accepting edges may not go to rejecting SCCs |
|
||||
| =complete= | it is always possible to move the automaton forward, using any letter |
|
||||
| =universal= | there is no non-determinism branching in the automaton (hence each word is *recognized* by at most one run, but not necessarily accepted) |
|
||||
| =semi-deterministic= | any nondeterminism occurs before entering an accepting SCC |
|
||||
| =unambiguous= | there is at most one run *accepting* a word (but it might be recognized several time) |
|
||||
| =stutter_invariant= | the property recognized by the automaton is [[https://www.lrde.epita.fr/~adl/dl/adl/michaud.15.spin.pdf][stutter-invariant]] |
|
||||
|
||||
For each flag =flagname=, the =twa= class has a method
|
||||
=prop_flagname()= that returns the value of the flag as an instance of
|
||||
|
|
@ -1083,12 +1083,14 @@ operator =X= does not prevent the formula from being
|
|||
stutter-invariant, but it would require additional work to check.
|
||||
|
||||
As another example, if you write an algorithm that must check whether
|
||||
an automaton is deterministic, do not call the
|
||||
=twa::prop_deterministic()= method, because that might return
|
||||
=trival::maybe=. Instead, call =spot::is_deterministic(...)=: that
|
||||
will respond in constant time if the =deterministic= property flag was
|
||||
either =true= or =false=, otherwise it will actually explore the
|
||||
automaton to decide its determinism.
|
||||
an automaton is universal, do not call the =twa::prop_universal()=
|
||||
method, because that might return =trival::maybe=. Instead, call
|
||||
=spot::is_universal(...)=: that will respond in constant time if the
|
||||
=universal= property flag was either =true= or =false=, otherwise it
|
||||
will actually explore the automaton to decide its determinism. Note
|
||||
that there is also a =spot::is_deterministic(...)= function, which is
|
||||
equivalent to testing that the automaton is both universal and
|
||||
existential.
|
||||
|
||||
These automata properties are encoded into the [[file:hoa.org::#property-bits][HOA format]], so they can
|
||||
be preserved when building a processing pipeline using the shell.
|
||||
|
|
|
|||
|
|
@ -609,11 +609,11 @@ double-checked by the parser.
|
|||
It should be noted that each property can take three values: true,
|
||||
false, or maybe. So actually two bits are used per property. For
|
||||
instance if in some algorithm you want to know whether an automaton is
|
||||
deterministic (the equivalent of calling =autfilt -q
|
||||
--is-deterministic aut.hoa= from the command-line), you should not
|
||||
call the method =aut->prop_deterministic()= because that only checks
|
||||
complete (the equivalent of calling =autfilt -q
|
||||
--is-complete aut.hoa= from the command-line), you should not
|
||||
call the method =aut->prop_complete()= because that only checks
|
||||
the property bits, and it might return =maybe= even if =aut= is
|
||||
deterministic. Instead, call the function =is_deterministic(aut)=.
|
||||
deterministic. Instead, call the function =is_complete(aut)=.
|
||||
This function will first test the property bits, and do the actual
|
||||
check in case it is unknown.
|
||||
|
||||
|
|
@ -639,12 +639,12 @@ this requests "verbose" properties.
|
|||
|
||||
The following table summarizes how supported properties are handled. In
|
||||
particular:
|
||||
- for the parser =checked= means that the property is always inferred
|
||||
- For the parser, =checked= means that the property is always inferred
|
||||
and checked against any declaration (if present), =trusted= means
|
||||
that the property will be stored without being checked (unless
|
||||
=--trust-hoa=no= is specified).
|
||||
- Stored properties are those represented as bits in the automaton.
|
||||
- the printer will sometime check some properties when it can do
|
||||
- The printer will sometime check some properties when it can do
|
||||
it as part of its initial "survey scan" of the automaton; in that
|
||||
case the stored property is not used. This makes it possible
|
||||
to detect deterministic automata that have been output by algorithms
|
||||
|
|
|
|||
|
|
@ -132,7 +132,8 @@ corresponding BDD variable number, and then use for instance
|
|||
// example, the properties that are set come from the "properties:"
|
||||
// line of the input file.
|
||||
out << "Complete: " << aut->prop_complete() << '\n';
|
||||
out << "Deterministic: " << aut->prop_deterministic() << '\n';
|
||||
out << "Deterministic: " << (aut->prop_universal()
|
||||
&& aut->is_existential()) << '\n';
|
||||
out << "Unambiguous: " << aut->prop_unambiguous() << '\n';
|
||||
out << "State-Based Acc: " << aut->prop_state_acc() << '\n';
|
||||
out << "Terminal: " << aut->prop_terminal() << '\n';
|
||||
|
|
@ -162,57 +163,6 @@ corresponding BDD variable number, and then use for instance
|
|||
#+END_SRC
|
||||
|
||||
#+RESULTS:
|
||||
#+begin_example
|
||||
Acceptance: Inf(0)&Inf(1)
|
||||
Number of sets: 2
|
||||
Number of states: 4
|
||||
Number of edges: 10
|
||||
Initial state: 0
|
||||
Atomic propositions: a (=0) b (=1) c (=2)
|
||||
Name: Fa | G(Fb & Fc)
|
||||
Complete: no
|
||||
Deterministic: no
|
||||
Unambiguous: yes
|
||||
State-Based Acc: maybe
|
||||
Terminal: maybe
|
||||
Weak: maybe
|
||||
Inherently Weak: maybe
|
||||
Stutter Invariant: yes
|
||||
State 0:
|
||||
edge(0 -> 1)
|
||||
label = a
|
||||
acc sets = {}
|
||||
edge(0 -> 2)
|
||||
label = !a
|
||||
acc sets = {}
|
||||
edge(0 -> 3)
|
||||
label = !a
|
||||
acc sets = {}
|
||||
State 1:
|
||||
edge(1 -> 1)
|
||||
label = 1
|
||||
acc sets = {0,1}
|
||||
State 2:
|
||||
edge(2 -> 1)
|
||||
label = a
|
||||
acc sets = {}
|
||||
edge(2 -> 2)
|
||||
label = !a
|
||||
acc sets = {}
|
||||
State 3:
|
||||
edge(3 -> 3)
|
||||
label = !a & b & c
|
||||
acc sets = {0,1}
|
||||
edge(3 -> 3)
|
||||
label = !a & !b & c
|
||||
acc sets = {1}
|
||||
edge(3 -> 3)
|
||||
label = !a & b & !c
|
||||
acc sets = {0}
|
||||
edge(3 -> 3)
|
||||
label = !a & !b & !c
|
||||
acc sets = {}
|
||||
#+end_example
|
||||
|
||||
* Python
|
||||
|
||||
|
|
@ -239,7 +189,7 @@ Here is the very same example, but written in Python:
|
|||
name = aut.get_name()
|
||||
if name:
|
||||
print("Name: ", name)
|
||||
print("Deterministic:", aut.prop_deterministic())
|
||||
print("Deterministic:", aut.prop_universal() and aut.is_existential())
|
||||
print("Unambiguous:", aut.prop_unambiguous())
|
||||
print("State-Based Acc:", aut.prop_state_acc())
|
||||
print("Terminal:", aut.prop_terminal())
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue