Both types of engine now disallow negative/infinite/NaN rewards.
Symbolic engines will mostly still not detect the presence of NaN
due to the way that CUDD deals with this.
Regression tests also added.
Introduced in symbolic engines during recent-ish refactoring.
Seems to have been wrong in explicit engines for longer.
Format is 0=0.27109177824020264, not 0:=0.27109177824020264
This allows reward info to be specified separately from the model (ModelInfo & ModelGenerator).
Firstly, RewardGenerator includes basic syntactic info: the number of reward structs and their names.
Secondly it provides access to the rewards themselves.
Implementations of RewardGenerator can allow rewards to be queried in one or more ways:
by State object; by (integer) state index; or syntactically by providing a RewardStruct.
Default implementations of all methods are provided which assume that rewards are
looked up by State object and there are no rewards defined (zero reward structs).
A subset of these methods were previously in ModelInfo/ModelGenerator,
so classes that implement those interfaces and implement them should add
“implements RewardGenerator” or remove any @Override annotations.
RewardGenerator is now:
* implemented by ModulesFileModelGenerator and ModulesFileModelGeneratorSymbolic
* created and stored in Prism as needed
* passed to explicit engine model checkers via new method setModelCheckingInfo,
which now replaces setModulesFileAndPropertiesFile
* used in explicit.ConstructRewards to build reward structures
* passed to ModelGenerator2MTBDD for symbolic construction from ModelGenerators
There is also a refactor of the code for looking up index of reward structs:
New methods in ExpressionReward, including switch to RewardGenerator object,
and the methods return the index, not a RewardStruct object.
Export the values of the following standard compiler and compiler flag
variables in the main makefile, avoiding the need to pass through each
one to child make processes manually:
CC
CXX
LD
JAVAC
JAVACC
Since JAVAC is manually exported as "$(JAVAC) $(JFLAGS)" by the main
makefile, additionally separate JAVAC and JFLAGS into separate variables
from the perspective of child make processes.
Rename the following makefile variables for the sake of clarity in child
makefiles:
SRC_DIR -> PRISM_SRC_DIR
CLASSES_DIR -> PRISM_CLASSES_DIR
OBJ_DIR -> PRISM_OBJ_DIR
LIB_DIR -> PRISM_LIB_DIR
INCLUDE_DIR -> PRISM_INCLUDE_DIR
IMAGES_DIR -> PRISM_IMAGES_DIR
DTDS_DIR -> PRISM_DTDS_DIR
The helper script src/scripts/printversion.sh also makes use of the
value of SRC_DIR exported from the main makefile, so use PRISM_SRC_DIR
in that script too.
PR #116 (in particular 5c33a555ac) moved
the post-processing of the BSCC steady state probabilities (weighing
by the exit rates of the CTMC) into computeSteadyStateProbsForBSCC().
This introduced a regression, leading to wrong results, as the
post-processing would be applied on the solution vector that was
returned by the method, but not necessarily on the values passed back
out via the result argument vector.
We fix this by moving the post-processing up, before the copy and
adding a note of caution.
Failure e.g. for
prism prism-tests/papers/Par02/Par02-3.3.3.sm prism-tests/papers/Par02/Par02-3.3.3.sm.props -explicit -testall
The computation reuses the computeSteadyStateBackwardsProbs() method
used for the computation of S=?[ phi ]. We tweak the variable names
and comments in that method to make clear that the solution values of
a BSCC - after multiplication with the mult array - are not
necessarily probabilities anymore.
Provide variants of computeSteadyStateProbs() and computeSteadyStateBackwardsProbs() in DTMCModelChecker
that take a BSCCPostProcessor, which can be used to reweight the steady-state probabilities.
(preparation for steady-state computation for CTMCs)
This uses a new type of ExpressionFilter with op type "store",
rather than setting a boolean flag on existing filter objects.
Includes two test-cases showing examples where the old code failed.
Exports the value of a model checked property for all states as a vector.
If <file> is "stdout", this is displayed to the log instead of a file.
Currently, only works for a single property: if there is more than one,
then the file gets overwritten each time a property is checked.
Also fixes a bug in the underlying mechanism for storing results vectors
in the explicit engine (within Results objects).
We did not perform a required deepCopy of the path expression before checking/replacing maximal state formulas, thus modifying the original expression, which breaks later model checking when doing experiments.
Found by Steffen Märcker.
The HTML file generated by the iteration export loads Javascript and
CSS resources from www.prismmodelchecker.org. Previously, those URLs
used http as the protocol. If such a generated HTML file was loaded
via an https-connections, current browsers would reasonably block
access to the Javascript, as it's not be loaded over a secure
connection.
As the prismmodelchecker.org site now supports https, we switch to
https for loading those resources.
When constructing a model using the explicit engine, the set of
reachable states is always sorted. This is done purely for aesthetic
reasons and is potentially time-consuming for large models, so make it
optional (although enable it by default for backwards-compatibility, and
explicitly enable state sorting in the test cases that use
ConstructModel in case this default changes at a later time).
When DOT graphs of a model are exported, their maximum permitted size is
hardcoded to 8 inches wide by 5 inches high, which is too small for the
rendered drawing to be useful (e.g. during debugging) for all but the
simplest of models. Remove the maximum size restriction, allowing tools
to render the drawing with its natural dimensions.
Use enum fields to store the delimiters instead of the map.
Add some more comments to alert the user that proper quoting (for HTML labels) might be necessary.
Graphviz implements a subset of HTML that can be used in node and edge
labels (see https://graphviz.gitlab.io/_pages/doc/info/shapes.html#html
for a description of the subset) as an alternative to the plain-text
default style. The HTML-like style uses different attribute value
delimiters (<>) to the plain text style (""), but the latter is
hardcoded in explicit.graphviz.Decoration. The line delimiters also
differ (<br/> and \n respectively).
Provide support for both plain text and HTML-like labels in Decorator;
the label type can be changed by calling setLabelType() before appending
any label content via labelAddBelow() or labelAddAbove().
Previously, the flags for interval/topological iteration and
for Pmax-quotienting would not be initialised if the ModelChecker
was constructed directly.
As noted in #68, the javah tool has been removed in JDK10. Here, we switch to the new way of generating the JNI .h files, using the -h option of the regular javac compiler.
We have to adapt all Makefiles (not only those in directories that contain classes with native methods), as javac compiles all required classes (and generates their JNI headers) beyond the directory with the Makefile.
The .h files generated by javac -h had a different naming scheme, now there is a prefix for the package name. To avoid having to touch all the #includes, we generate the new .h files in prism/include/jni and provide legacy headers in the old location and with the old name, forwarding the the corresponding new header. In the future, at an appropriate moment, those legacy headers can be removed and replace with direct includes.
Currently, there is a post-processing step on Windows: After the .h file is generated, dos2unix is called to replace the Windows CRLF line endings. Otherwise, the generated headers show up as changed files in version control. As now there are no special targets for the generation of the .h files anymore, we move to a global post-processing step and call dos2unix on prism/include/jni/*.h at the end of building.
During model exploration of a CTMC, when using fast adaptive uniformisation,
only the last part of an update (rate & successor state) is used, as the
indexing of the outgoing transitions is buggy.
We now store all outgoing transitions and handle the case of multiple
choices/enabled commands in the CTMC.
+ two test cases
(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.
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.
The action object attached to a transition can be null (internal action), leading to a null pointer
exception when trying to call the toString method.
+ test case
The state information of the model-automaton product are stored as an int array, with one
entry for every combination of model state index and automaton state index. Thus, |S|*|A| has to be
less than INT_MAX, even if the reachable state space could be index with an int.
Thus, we use Math.multiplyExact to catch the case that the product of the two numbers of states overflows
the int range and throw an Exception.
Dave Parker