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.
Previously, a transition reward with [] would match the self loop
transition added for fixing deadlocks in the explicit engine.
Fixes#29 and adds test case.
In attachLabels(), avoid unnecessarily exploring the state space again
when the ModelGenerator indicates that labels aren't used (i.e. when
getNumLabels() == 0).
As noted in #48, DTMCUniformisedSimple does not implement the full range of ModelExplicit methods. Trying to use it outside of the areas where it's currently used in PRISM can then lead to NullPointerExceptions etc.
We add here accessors for the deadlock states, passing through the method calls to the underlying CTMC.
Additionally, point to the fully-featured uniformised DTMC object / construction method.
If there are exceptions during the iteration, we want to have a working HTML file with the iterations up to that point.
By flushing after each vector, we can ensure that the HTML is in a working state.
Switch from
... took X iterations, Y MV-multiplications and Z seconds.
to
... took X iterations, Y multiplications and Z seconds.
as MV-multiplications does not have a terribly intuitive meaning.
Now aligns with the default implementation in explicit.MDP: If there is a choice consisting of a self-loop,
produces value 0 for zero-reward state/choice and infinite value for positive-reward state/choice
(should be catched before in precomputations).
The previous behaviour (self-loops have infinite value) messes with maximal total reward computations with
Gauss-Seidel, e.g.
prism functionality/verify/mdps/rewards/total-reward-2.nm functionality/verify/mdps/rewards/total-reward-2.nm.props -explicit -gs -test -prop 3
for the PRISM test suite fails.
Also, align comments in MDP.mvMultRewJacMinMaxSingle.
Sometimes, we want to use the prob0/1... methods to generate schedulers instead of doing
the standard precomputations and don't want to have the normal log output.
Not inherited using inheritSettings()
When using an iteration method with two alternating solution vectors (power, jacobi),
we did not copy the result to the second vector when we have detected convergence in
an SCC (for topological interval iteration). Subsequently, as the values for finished
SCCs will never be updated anymore, the values for this states will oscillate between
the final value and the value from the iteration step before, potentially preventing
convergence. This will be mitigated if we enfore convergence from below / above, but
at least from below enforcing convergence should not be necessary.
An example would be
prism prism-examples/dice/two_dice.nm -pf 'Rmin=?[ F s1=7]' -explicit -topological -ii:nomonotonicbelow
where oscillation between 0 and 1 inhibits convergence.
To fix, we tell the iteration method when we are done with an SCC so that we can
copy the results. For singleton SCCs, we already copied the results to both vectors.
git-svn-id: https://www.prismmodelchecker.org/svn/prism/prism/trunk@12204 bbc10eb1-c90d-0410-af57-cb519fbb1720
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