This is a rebased version of the code previously published in the prism-ext repo,
with various bits of code refactored, tidied and improved.
Model construction and model checking support is added to the explicit engine.
The PRISM modelling language is extended with the 'pomdp' model keyword
and observables...endobservables blocks to indicate observable variables.
A default implementation of createVarList() in ModelInfo now creates
a VarList automatically, so this does not need to be implemented when
creating a ModelGenerator. Instead, just getVarDeclarationType(int i),
which is a newly added method, should be implemented. There is also
a default implementation of this, but it assumes that integer variables
are unbounded, which will not work with the symbolic engine.
In a related change, ModelInfo can now optionally specify which "module"
a variable belongs to (via getVarModuleIndex and getModuleName).
ModulesFile is updated, to fully support the new version of ModelInfo,
and all implementations of ModelGenerator are simplified where possible.
The old VarList constructor which takes a ModulesFile is removed and
replaced with one which takes a ModelInfo object.
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.
This allows simulation and statistical model checking to be performed on
a wider range of model sources, not just PRISM language models.
SimulatorEngine and associated files have had their dependencies on
ModulesFile removed, now using ModelGenerator and RewardGenerator
instead. SimulatorEngine also no longer uses TransitionList and Updater:
these are internal to the ModulesFileModelGenerator which provides
ModelGenerator access to a PRISM model.
Associated simulator classes have been altered too. Path and Sampler
classes now use a ModelInfo and RewardGenerator, rather than a
ModulesFile and TransitionList. Path classes store an action object and
action string, rather than action info specific to a ModulesFile. This
means that the methods getTransitionModuleOrAction and
getTransitionModuleOrActionIndex disappear from SimulatorEngine,replaced
by getTransitionAction and getTransitionActionString.
Usage of SimulatorEngine changes slightly. There is now a loadModel()
method, after which paths are created or statistical model checking
initiated, rather than a ModulesFile being passed to these latter
methods as done previously. The main function of SimulatorEngine is
manual/automatic path creation and statistical model checking. Exploring
states/transitions of a model is now de-emphasised, since this is
already provided directly by the passed in ModelGenerator. But
SimulatorEngine still provide access to information about transitions
etc. in the model because it allows this to be queried for arbitrary
states along created paths. The method checkModelForSimulation() has
been removed - since these checks now occur earlier at the point of
creating a ModelGenerator - and is now in Prism instead.
In Prism, in line with other recent changes, simulation-based methods
now use the currently loaded model, rather than taking a passed in
ModulesFile. For use within these methods, or from other methods that
want to access SimulatorEngine directly, there is a new method
loadModelIntoSimulator().
Various utility methods added to ModelGenerator, all with default (but not
necessarily the most efficient) implementations. These include methods for:
computing indices of choices/transitions (getChoiceIndexOfTransition,
getChoiceOffsetOfTransition, getTotalIndexOfTransition); checking transition
availability (isDeadlock, isDeterministic); computing probability/rate sums
(getChoiceProbabilitySum, getProbabilitySum); action label strings
(getTransitionActionString, getChoiceActionString) and transition strings
(getTransitionUpdateString, getTransitionUpdateStringFull). ModelInfo also
has getActionStringDescription, associated with the last two groups.
Implementations added for most of these methods in ModulesFileModelGenerator
and ModulesFileModelGeneratorSymbolic, mostly just via the existing methods
in the underlying TransitionList. A little bit of additional tidying in these
classes too.
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.
* Remove some unneeded methods: getExploreState() and getTransitionAction(int i)
* Add a default implementation of getNumVars() based on name list
Existing code which implements the first two methods and annotates them with @Override needs to be changed.
TestModelGenerator, ModulesFileModelGenerator, ModulesFileModelGeneratorSymbolic updated accordingly.
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.
Provides a switch that allows to specify that reward information
should be included in path export functions, as well as API compatible
forwarding functions.
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.
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.
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.
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.
Now, all the top-level packages have Makefiles and search for Java files
in subpackages.
If a .java file does not get picked up by the Makefiles, it will
nonetheless be compiled if referenced from somewhere else in the
project, but dependency tracking at the level of 'make' is broken.
Currently, building PRISM with parallel building does not work,
as there are dependencies between targets that are not fully
encoded in the Makefiles. Building with -j n flag would lead to error.
Now, we add the .NOTPARALLEL target to most of the Makefiles,
which tell GNU make to ignore the -j flag. Note that this
only inhibits parallel builds for the current Makefile, we
thus have to specify it for all sub-Makefiles as well
(see https://www.gnu.org/software/make/manual/html_node/Parallel.html)
For the external libraries, CUDD and LPSolve don't seem to mind building
in parallel, so we don't inhibit there and can get some minor compile time
speed-up by using multiple cores if the -j option is specified.
git-svn-id: https://www.prismmodelchecker.org/svn/prism/prism/trunk@12202 bbc10eb1-c90d-0410-af57-cb519fbb1720
During reward construction in the explicit engine using the new ModelGenerator
functionality (see SVN 11772), the check for transition rewards was missing
(he explicit engine currently does not support transition rewards for DTMCs and CTMCs).
This commit adds functionality to ModelInfo to determine whether a reward structure
defines transition rewards and adds a corresponding check during reward construction.
Example: prism-examples/dice/dice.pm with R=?[ F s=7 ] and -explicit returns 0 instead
of an error message.
git-svn-id: https://www.prismmodelchecker.org/svn/prism/prism/trunk@11802 bbc10eb1-c90d-0410-af57-cb519fbb1720
- Extended functionality available through the prism.Prism API when using ModelGenerators
- Improvements to ModelGenerator interface wrt handling of rewards (and also labels)
- Explicit engine model checkers now build rewards from a ModelGenerator, not a RewardStruct.
This is now (optionally) attached with the setModulesFileAndPropertiesFile method.
- New code to generate symbolic models from ModelGenerators (useful, if not super efficient)
- Move createVarList() method from ModelGenerator up to ModelInfo
- Some code tidying in LabelList
Code was previously at https://github.com/prismmodelchecker/prism-svn/tree/model-generator
git-svn-id: https://www.prismmodelchecker.org/svn/prism/prism/trunk@11772 bbc10eb1-c90d-0410-af57-cb519fbb1720
Dave Parker