Only filter(state, ...) has special handling for TypeVoid results (special
results such as e.g. pareto results from multi-objective model checking).
git-svn-id: https://www.prismmodelchecker.org/svn/prism/prism/trunk@12034 bbc10eb1-c90d-0410-af57-cb519fbb1720
Multi-objective model checking only supports checking for a single state.
Previously, this check required a state-filter with a single matching state (e.g.,
the default filter(state, ..., "init") placed around a top-level expression).
Now, we check that statesOfInterest is a singleton set.
Thus, now expressions such as
filter(max, multi(P=?[...]. P>0.5[...], "label")
filter(print, multi(P=?[...]. P>0.5[...], "label")
with single-state labels will work.
git-svn-id: https://www.prismmodelchecker.org/svn/prism/prism/trunk@12033 bbc10eb1-c90d-0410-af57-cb519fbb1720
Additionally, provide more consistent JavaDoc/@Override annotations for these methods.
Often, we are only interested in a subset of the states. E.g., for the top-level
expression, PRISM by default only reports on the initial states; for filters, only
the filtered states are of interest, etc.
By providing a statesOfInterest set to the check methods, they can in principle
exploit this knowledge. One prominent candidate is the automata-based LTL model
checking, which can start the product construction only from the states of interest
instead of from all states. The statesOfInterest information is merely a hint, i.e.,
a checkXYZ method can return values for more states than those specified as the states
of interest. However, the caller should not rely on any results beyond those for
the statesOfInterest.
This commit only provides the basic infrastructure, i.e., adding the stateOfInterest
argument to the method signatures, passing this set to recursive method calls where
appropriate, etc, but does not yet exploit this information. Subsequent commits will
then begin to exploit this information.
The called checkXYZ method is responsible for dereferencing the JDDNode for the
statesOfInterest set. Generally, care should be taken that statesOfInterest is indeed
an MTBDD over the row-variables of the model and that it is a subset of the reachable
states of the model. If one is interested in results for all states, use
model.getReach().copy() as the statesOfInterest.
An analoguous mechanism already exists for the explicit engine.
git-svn-id: https://www.prismmodelchecker.org/svn/prism/prism/trunk@12032 bbc10eb1-c90d-0410-af57-cb519fbb1720
findMaximalStableSetOld has not been in use since 2013 (replaced by findMaximalStableset),
maxStableSetTrans is replaced by getStableTransReln.
Methods were private, so we just remove instead of marking as deprecated.
git-svn-id: https://www.prismmodelchecker.org/svn/prism/prism/trunk@12029 bbc10eb1-c90d-0410-af57-cb519fbb1720
Numeric computations (relying on sum of outgoing transitions > 1 - epsilon to detect choices that
remain in the EC) are not precise, better to just do a graph-based computation.
git-svn-id: https://www.prismmodelchecker.org/svn/prism/prism/trunk@12028 bbc10eb1-c90d-0410-af57-cb519fbb1720
Currently, the hybrid engine internally uses int (signed 32bit) index variables
So, if the number of states is larger than Integer.MAX_VALUE, there is a problem
and the code will most probably crash or do nonsensical things.
We check this before calling into the native hybrid engine code and
throw a PrismNotSupportedException.
git-svn-id: https://www.prismmodelchecker.org/svn/prism/prism/trunk@12021 bbc10eb1-c90d-0410-af57-cb519fbb1720
Currently, the sparse engine internally uses int (signed 32bit) index variables
So, if the number of states is larger than Integer.MAX_VALUE, there is a problem
and the code will most probably crash or do nonsensical things.
We check this before calling into the native sparse engine code and
throw a PrismNotSupportedException.
git-svn-id: https://www.prismmodelchecker.org/svn/prism/prism/trunk@12020 bbc10eb1-c90d-0410-af57-cb519fbb1720
Before, the ODD offsets (for indexing into the reachable states) were
stored as longs, resulting in inconsistent numbers of (symbolic)
states that can be treated. In particular, on Win64, long is 32bit.
We switch to int64_t for the ODD offsets everywhere, allowing
MTBDD computations for models with >2^31 states.
Additionally, we check for arithmetic overflow in the offset
computations. Due to the symbolic storage for the models and the
state space explosion, it's possible to construct simple model files
that reach the 2^63 states limit.
If this limit is reached, we now throw an error message. In the future
it might be worthwile to ensure that PRISM can deal with the absence
of an ODD for all the computations that don't absolutely require it
and carry on (most MTBDD engine algorithms should be fine).
git-svn-id: https://www.prismmodelchecker.org/svn/prism/prism/trunk@12019 bbc10eb1-c90d-0410-af57-cb519fbb1720
We check after each DD operation whether the returned DdNode* is NULL
and abort the computation. The NULL return value is then caught in the
JDD.ptrToNode() method, which raises a CuddOutOfMemoryException.
git-svn-id: https://www.prismmodelchecker.org/svn/prism/prism/trunk@12008 bbc10eb1-c90d-0410-af57-cb519fbb1720
We check after each DD operation whether the returned DdNode* is NULL
and abort the computation. The NULL return value is then caught in the
JDD.ptrToNode() method, which raises a CuddOutOfMemoryException.
git-svn-id: https://www.prismmodelchecker.org/svn/prism/prism/trunk@12007 bbc10eb1-c90d-0410-af57-cb519fbb1720
Missing case for NE operator in BoxRegion.cmpOp. This affects the check routines
for the != operator in the parametric/exact engines, e.g., for state formulas
such as s!=t
git-svn-id: https://www.prismmodelchecker.org/svn/prism/prism/trunk@11976 bbc10eb1-c90d-0410-af57-cb519fbb1720
If the ProbModelTransformationOperator does not modify the non-row / non-column
variables in the transformation of the transition function, it can also be used
for MDPs (modifying the successor state only depending on the originating state).
This can be useful in standard product transformations that are agnostic of
the non-deterministic choice.
git-svn-id: https://www.prismmodelchecker.org/svn/prism/prism/trunk@11947 bbc10eb1-c90d-0410-af57-cb519fbb1720
By specifying a NondetModelTransformationOperator, we can easily transform
a given symbolic NondetModel (MDP) to a transformed model. The necessary
handling of the meta-information is done in NondetModelModel.getTransformed.
git-svn-id: https://www.prismmodelchecker.org/svn/prism/prism/trunk@11946 bbc10eb1-c90d-0410-af57-cb519fbb1720
By specifying a ProbModelTransformationOperator, we can easily transform
a given symbolic ProbModel (DTMC/CTMC) to a transformed model. The necessary
handling of the meta-information is done in ProbModel.getTransformed.
git-svn-id: https://www.prismmodelchecker.org/svn/prism/prism/trunk@11945 bbc10eb1-c90d-0410-af57-cb519fbb1720
The -ddextrastatevars setting allows to change the number of state variable pairs that are preallocated
before the actual model state variables. Previously, 20 state variable pairs were allocated for the
product construction (LTL). From now on, this is the default, but the amount can be changed, e.g., to
0 to force all automaton states to be allocated at the bottom of the MTBDD.
From now on, additionally, we also preallocate 20 action variables at the top of the MTBDD,
which will provide extra action / non-deterministic choice bits for symbolic model transformations
that require additional non-deterministic choices, e.g., additional special actions, etc.
The number of preallocated action variables is configurable by the -ddextraactionvars setting.
Adding the additional variables should not have a performance impact, as they are "don't cares"
in the normal MTBDD encoding of the models.
For the sparse and hybrid engine, allocating the nondeterministic choice variables at the top
makes sense for performance reasons (the submatrix for each choice is a sub-MTBDD), so we currently
only support extra action variables at the top.
git-svn-id: https://www.prismmodelchecker.org/svn/prism/prism/trunk@11944 bbc10eb1-c90d-0410-af57-cb519fbb1720
The current behaviour for the -o2 (MTBDD) variable order (no
pre-allocation of state variables before the model variables) is there
since the initial support for LTL in PRISM. We need some benchmarks
to see if it's a good idea to use preallocation as for the -o1 order.
git-svn-id: https://www.prismmodelchecker.org/svn/prism/prism/trunk@11943 bbc10eb1-c90d-0410-af57-cb519fbb1720
Joachim Klein