notebooks: correction of typos
* tests/python/_partitioned_relabel.ipynb, tests/python/_product_weak.ipynb, tests/python/acc_cond.ipynb, tests/python/aliases.ipynb, tests/python/automata.ipynb, tests/python/cav22-figs.ipynb, tests/python/contains.ipynb, tests/python/decompose.ipynb, tests/python/formulas.ipynb, tests/python/games.ipynb, tests/python/highlighting.ipynb, tests/python/ltsmin-dve.ipynb, tests/python/parity.ipynb, tests/python/product.ipynb, tests/python/satmin.ipynb, tests/python/stutter-inv.ipynb, tests/python/synthesis.ipynb, tests/python/twagraph-internals.ipynb, tests/python/word.ipynb, tests/python/zlktree.ipynb: here
This commit is contained in:
parent
858629dd3a
commit
6dc11b4715
20 changed files with 242 additions and 82 deletions
|
|
@ -798,7 +798,7 @@
|
|||
"\n",
|
||||
"First, we build a product without taking care of the acceptance sets. We just want to get the general shape of the algorithm.\n",
|
||||
"\n",
|
||||
"We will build an automaton of type `twa_graph`, i.e., an automaton represented explicitely using a graph. In those automata, states are numbered by integers, starting from `0`. (Those states can also be given a different name, which is why the the `product()` shows us something that appears to be labeled by pairs, but the real identifier of each state is an integer.)\n",
|
||||
"We will build an automaton of type `twa_graph`, i.e., an automaton represented explicitly using a graph. In those automata, states are numbered by integers, starting from `0`. (Those states can also be given a different name, which is why the the `product()` shows us something that appears to be labeled by pairs, but the real identifier of each state is an integer.)\n",
|
||||
"\n",
|
||||
"We will use a dictionary to keep track of the association between a pair `(ls,rs)` of input states, and its number in the output."
|
||||
]
|
||||
|
|
@ -1145,7 +1145,7 @@
|
|||
"source": [
|
||||
"def product1(left, right):\n",
|
||||
" # A bdd_dict object associates BDD variables (that are \n",
|
||||
" # used in BDDs labeleing the edges) to atomic propositions.\n",
|
||||
" # used in BDDs labeling the edges) to atomic propositions.\n",
|
||||
" bdict = left.get_dict()\n",
|
||||
" # If the two automata do not have the same BDD dict, then\n",
|
||||
" # we cannot easily detect compatible transitions.\n",
|
||||
|
|
@ -1235,7 +1235,7 @@
|
|||
"source": [
|
||||
"## Second attempt: a working product\n",
|
||||
"\n",
|
||||
"This fixes the list of atomtic propositions, as discussed above, and also sets the correct acceptance condition.\n",
|
||||
"This fixes the list of atomic propositions, as discussed above, and also sets the correct acceptance condition.\n",
|
||||
"The `set_acceptance` method takes two arguments: a number of sets, and an acceptance function. In our case, both of these arguments are readily computed from the number of states and acceptance functions of the input automata."
|
||||
]
|
||||
},
|
||||
|
|
@ -1671,7 +1671,7 @@
|
|||
"\n",
|
||||
"The former point could be addressed by calling `set_state_names()` and passing an array of strings: if a state number is smaller than the size of that array, then the string at that position will be displayed instead of the state number in the dot output. However we can do even better by using `set_product_states()` and passing an array of pairs of states. Besides the output routines, some algorithms actually retrieve this vector of pair of states to work on the product.\n",
|
||||
"\n",
|
||||
"Regarding the latter point, consider for instance the deterministic nature of these automata. In Spot an automaton is deterministic if it is both existential (no universal branching) and universal (no non-deterministic branching). In our case we will restrict the algorithm to existantial input (by asserting `is_existential()` on both operands), so we can consider that the `prop_universal()` property is an indication of determinism:"
|
||||
"Regarding the latter point, consider for instance the deterministic nature of these automata. In Spot an automaton is deterministic if it is both existential (no universal branching) and universal (no non-deterministic branching). In our case we will restrict the algorithm to existential input (by asserting `is_existential()` on both operands), so we can consider that the `prop_universal()` property is an indication of determinism:"
|
||||
]
|
||||
},
|
||||
{
|
||||
|
|
@ -1710,7 +1710,7 @@
|
|||
"\n",
|
||||
" result.prop_universal(left.prop_universal() and right.prop_universal())\n",
|
||||
"\n",
|
||||
"because the results the `prop_*()` family of functions take and return instances of `spot.trival` values. These `spot.trival`, can, as their name implies, take one amongst three values representing `yes`, `no`, and `maybe`. `yes` and `no` should be used when we actually know that the automaton is deterministic or not (not deterministic meaning that there actually exists some non determinitic state in the automaton), and `maybe` when we do not know. \n",
|
||||
"because the results the `prop_*()` family of functions take and return instances of `spot.trival` values. These `spot.trival`, can, as their name implies, take one amongst three values representing `yes`, `no`, and `maybe`. `yes` and `no` should be used when we actually know that the automaton is deterministic or not (not deterministic meaning that there actually exists some non deterministic state in the automaton), and `maybe` when we do not know. \n",
|
||||
"\n",
|
||||
"The one-liner above is wrong for two reasons:\n",
|
||||
"\n",
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue