Similar to the behaviour in the properties list, if we double-click
inside the constant or label table but not on an existing entry, we
add a new contant/label line in the table.
On first close, we set the file pointer to 0 to indicate that it
is not valid anymore. As PrismLog implements Close/AutoCloseable, multiple
close calls have to be supported.
Before, calling close multiple times could result in double free
crashes on Linux (seen in development branches, not master).
We also check that we don't write on a closed FILE pointer, but raise
an exception instead. Here, we use a RuntimeException
(IllegalStateException) instead of a PrismException as changing the
PrismLog interface would be quite disruptive to the rest of the code.
(addresses #72)
If the desired accuracy is to small, the naive weight computation can run
into an infinite loop, as floating point precision / rounding leads to
non-termination of the loop.
To partially address this, we move the accuracy check up, so that it
is also applied in the case of the 'naive' computation. This should make
it much less likely to run into this in practice.
For a full fix, we'd either need to check for non-progress in the loop
or do an analysis that the floating-point precision of double always
suffices for the remaining allowed input values.
Previously, despite the error message being printed, the Fox-Glynn computation
was nevertheless performed and the weights returned to the caller.
Now, we return and let the caller deal with the error condition.
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.
E.g., -const x=0:1/3:1 now works in non-exact/non-parametric mode as well.
Additionally, catch the case where the constants are not finite numbers (infinities, NaN).
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.
Previously, constants that are defined via an expression
were evaluated using standard (integer or floating point) arithmetic,
even in parametric or exact model checking mode.
This commit provides the infrastructure for requesting that constant
expressions are evaluated using exact arithmetic.
To keep the API backward compatible, we introduce additional methods that
offer an 'exact' flag, but keep the old methods as well. Those default to
normal arithmetic.
TypeDouble constants are kept as rational numbers, while int and boolean
constants are converted to Java data types. For int, an exception is raised
if the value can't be exactly represented by Java int.
Support matching of constants in RESULT strings for the case
that constants in the model are exact rational
numbers (implemented in subsequent commits).
This allows storage of BigRational values in StateValues / Values vectors, e.g.,
to store constants that have been evaluated exactly.
TypeDouble.castValueTo now returns a Number instead of a Double, requiring the use
of the doubleValue() method in several places where the value is evaluated using
double arithmetic.
To guarantee convergence, the power method requires the precomputation
P = (Q * deltaT + I)
from: William J. Stewart: Introduction to the Numerical Solution of Markov Chains p. 124.
For JDK10, the test suite did not run as the JDK8 binary installed in /usr/bin/ was used for the PRISM runs instead of the JDK10 binaries, even though the JDK10 bin directory comes first on the PATH. This is due to the python startup helpers (when running prism-auto for the tests) fiddling with the PATH variable, prepending /usr/bin/...
So, we now just set the PRISM_JAVA environment variable to the java binary on the PATH from the travis build script, which is then picked up correctly in the prism startup script.
Print test statistics also in the (not particularly useful) case that the timeout is set to 0 by testing against None instead to see if a timeout was set.
The occurence of a line with 'Error:' does not necessarily imply a
failed test result, e.g., for test cases that test against the error
messages.
So we revert the previous change related to the printing of 'Error' lines
and tweak the handling in verbose-test mode some more.
Only F/U operators with upper bound have a bounded path length and can
thus skip the maximal path length checks.
Test cases (will continue sampling beyond the default max path length,
appearing to hang):
prism prism-examples/dice/dice.pm -pf 'P=?[ F>2 s=0 ]' -sim
prism prism-examples/dice/dice.pm -pf 'P=?[ F>2 s=0 ]' -sim -ctmc
After this fix, the usual error message for unbounded operators is
generated.
We now explicitly remember if there was an upper bound instead of
relying on an upper bound of Integer.MAX_VALUE in the case of an
absent bound.
Statistical MC, P[F]/P[U] in discrete time setting with time bounds.
Joachim Klein