alarsyo/spot
1
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

twa: store property bits as trivals

Browse source 
* spot/twa/twa.hh: Store property bits as trivals.
* NEWS: Mention the change.
* spot/parseaut/parseaut.yy, spot/twaalgos/are_isomorphic.cc,
spot/twaalgos/complete.cc, spot/twaalgos/dot.cc, spot/twaalgos/hoa.cc,
spot/twaalgos/isdet.cc, spot/twaalgos/isunamb.cc, spot/twaalgos/lbtt.cc,
spot/twaalgos/ltl2tgba_fm.cc, spot/twaalgos/postproc.cc,
spot/twaalgos/remfin.cc, spot/twaalgos/strength.cc,
spot/twaalgos/stutter.cc, spot/twaalgos/stutter.hh,
spot/twaalgos/totgba.cc, tests/core/ikwiad.cc,
tests/python/product.ipynb, tests/python/remfin.py: Adjust.
* doc/org/hoa.org, doc/org/tut21.org: Update documentation.
This commit is contained in:
Alexandre Duret-Lutz 2016-01-12 19:37:18 +01:00
parent 1aeb260adf
commit da391492f3
22 changed files with 337 additions and 258 deletions
Download patch file Download diff file Expand all files Collapse all files

38
doc/org/hoa.org
View file

@ -186,15 +186,15 @@ rm -f stvstracc.hoa
Even if an input HOA file uses only state-based acceptance, Spot
internally stores it using transition-based acceptance. However in
that case the TωA will have a property bit indicating that it actually
that case the TωA will have a property flag indicating that it actually
represents an automaton with the "state-based acceptance" property:
this implies that transitions leaving one state all belong to the same
acceptance sets. A couple of algorithms in Spot checks for this
property, and enable specialized treatments of state-based automata.
Furthermore, even if an automaton does not have the "state-based
acceptance" property bit set, the HOA output routine may detect that
the automaton satisfies this property. In that case, it output the
acceptance" property flag set, the HOA output routine may detect that
the automaton satisfies this property. In that case, it outputs the
automaton with state-based acceptance.
For instance in the following automaton, the outgoing transitions of
@ -583,7 +583,7 @@ labels whenever that is possible. The option is named =k= (i.e., use
=-Hk= with command-line tools) because it is useful when the HOA file
is used to describe a Kripke structure.
** Property bits
** Property flags
:PROPERTIES:
:CUSTOM_ID: property-bits
:END:
@ -593,7 +593,7 @@ These properties can be useful to speedup certain algorithms: for
instance it is easier to complement a deterministic automaton that is
known to be inherently weak.
Spot stores this properties that matters to its algorithms as
Spot stores the properties that matters to its algorithms as
additional bits attached to each automaton. Currently the HOA parser
ignores all the properties that are unused by Spot.
@ -603,22 +603,22 @@ is parsed; this is for instance the case of =deterministic=,
body of the file, and then return and error if what has been declared
does not correspond to the reality.
Some supported properties (like =weak=, =unambiguous=, or
=stutter-invariant=) are not double-checked, because that would
require too much additional operations. Command-line tools that read
HOA files all take a =--trust-hoa=no= option to ignore properties that
are not double-checked by the parser.
Some supported properties (like =weak=, =inherently-weak=,
=unambiguous=, or =stutter-invariant=) are not double-checked, because
that would require more operations. Command-line tools that
read HOA files all take a =--trust-hoa=no= option to ignore properties
that are not double-checked by the parser.
It should be noted that these bits are only implications. When such a
bit is false, it only means that it is unknown whether the property is
true. For instance if in some algorithm you want to know whether an
automaton is deterministic (the equivalent of calling =autfilt -q
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
the property bit, and it might be false even if the =aut= is
the property bits, and it might return =maybe= even if =aut= is
deterministic. Instead, call the function =is_deterministic(aut)=.
This function will first test the property bit, and do the actual
check if it has to.
This function will first test the property bits, and do the actual
check in case it is unknown.
Algorithms that update a TωA should call the method =prop_keep()= and
use the argument to specify which of the properties they preserve.
@ -632,7 +632,7 @@ take a new argument).
The =HOA= printer also tries to not bloat the output with many
redundant and useless properties. For instance =deterministic=
automata are necessarily =unambiguous=, and people interested in
unambiguous automata know that, so Spot only output the =unambiguous=
unambiguous automata know that, so Spot only outputs the =unambiguous=
property if an unambiguous automaton is non-deterministic. Similarly,
while Spot only outputs non-alternating automata, it does not output
the =no-univ-branch= property because we cannot think of a situation
@ -666,7 +666,7 @@ particular:
| =complete= | checked | no | checked | |
| =unambiguous= | trusted | yes | as stored if (=-Hv= or not =deterministic=) | can be checked with =--check=unambiguous= |
| =stutter-invariant= | trusted | yes | as stored | can be checked with =--check=stuttering= |
| =stutter-sensitive= | trusted | yes | as stored | can be checked with =--check=stuttering= |
| =stutter-sensitive= | trusted | yes | as stored (opposite of =stutter-invariant=) | can be checked with =--check=stuttering= |
| =terminal= | trusted | yes | as stored | can be checked with =--check=strength= |
| =weak= | trusted | yes | as stored if (=-Hv= or not =terminal=) | can be checked with =--check=strength= |
| =inherently-weak= | trusted | yes | as stored if (=-Hv= or not =weak=) | can be checked with =--check=strength= |