In other words, if the result for a state is q, and the bound p falls in the range
[q-e,q+e] where is the error bound from model checking computations, then an
error is generated rather than producing a potentially incorrect true/false result.
Explicit model checking engine only for now.
Test cases are added, and some (unrelated) existing regression tests with dubiously
close bound checks are fixed.
There is no explicit model type keyword added to the parser.
Instead, LTSs are auto-detected by the absence of probabilities.
ConstructModel is extended to build LTSs. Model checking (CTL+LTL)
can be done out of the box using the existing NonProbModelChecker class.
A few MDP regression tests are clarified to make it clear that the
models are MDPs, not LTSs.
Tweak the result strings for the CTL with step bounds cases (currently
computation is not supported with any engine). Previously, an error was
expected, but the properties are not actually erroneous. Additonally, the
error message was not uniform between the different engines, leading to
spurious failures against the exact engine.
Some of the result values for the test cases were floating-point approximations,
which results in 'close but inaccurate' errors when running the test cases against
the exact engine.
We replace those results either with the exact values or mark the approximated
results with ~... (mostly for a few CTMC properties, where the exact results
are a bit unwieldly).
Expressions are now evaluated exactly in parametric / exact model checking mode for:
- state updates
- command guards
- the if part of if-then-else expressions
- reward guards
- reward values
- Boolean expressions in RESULTS in property files
Add various test cases to check that it is now handled properly.
Using the infrastructure from the previous commit, we request exact evaluation
of constants in exact and parametric model checking mode.
Additionally, note where we deliberately choose non-exact evaluation mode.
Add corresponding test cases.
Due to a typo, the upper iteration uses `updateValueFromBelow` instead of `updateValueFromAbove`
to update the value vector. When the flag for monotonicity enforcement from above is active (default),
all values are thus forced to be above the upper bound, preventing convergence.
Example:
prism functionality/verify/mdps/reach/mdp_simple.nm functionality/verify/mdps/reach/mdp_simple.nm.props -sparse -intervaliter
+ test case
Dave Parker