Without formula simplifications, jltl2ba will produce an APSet L0, L1, ...
With formula simplifications (upcoming commit), some APs can be missing
in the NBA (when irrelevant) or reordered (due to formula simplification).
We handle edge label construction as elsewhere in PRISM for DA, to take
this into account.
git-svn-id: https://www.prismmodelchecker.org/svn/prism/prism/trunk@11186 bbc10eb1-c90d-0410-af57-cb519fbb1720
This is currently caught elsewhere as well, but provides defense-in-depth
for the situation that time bounds in LTL are supported later on.
Bounds on temporal operators don't have the same semantics in CTMCs
as for discrete-time models.
git-svn-id: https://www.prismmodelchecker.org/svn/prism/prism/trunk@11178 bbc10eb1-c90d-0410-af57-cb519fbb1720
If the expected result specified via // RESULT
is an error, we treat a PrismNotSupportedException just
as any other ordinary exception. This allows verifying
the content of a PrismNotSupportedException error message.
Otherwise, we do the usual special handling as before.
git-svn-id: https://www.prismmodelchecker.org/svn/prism/prism/trunk@11173 bbc10eb1-c90d-0410-af57-cb519fbb1720
There's actually JDK library functionality for a hash map that
uses object identity instead of .equals(), making PlainObjectReference
unnecessary. Use IdentityHashMap instead.
git-svn-id: https://www.prismmodelchecker.org/svn/prism/prism/trunk@11169 bbc10eb1-c90d-0410-af57-cb519fbb1720
Previously, subformulas were computed by a DTMCModelChecker
in the embedded DTMC, yielding wrong results. Now, maximal
state subformulas are checked via the CTMCModelChecker and
replaced by labels before calling the LTL model checking
routine on the embedded DTMC.
git-svn-id: https://www.prismmodelchecker.org/svn/prism/prism/trunk@11168 bbc10eb1-c90d-0410-af57-cb519fbb1720
The labels encode the satisfaction sets of the subformulas. This method can be
used to do the standard PCTL* recursion step, i.e., computing Sat(phi) and replacing
phi with an atomic proposition a_phi in the formula.
git-svn-id: https://www.prismmodelchecker.org/svn/prism/prism/trunk@11167 bbc10eb1-c90d-0410-af57-cb519fbb1720
When building a model from the GUI with the explicit engine, constant were sometimes not
updated correctly:
(1) Open xprism, switch to explicit engine
(2) Load a model with undefined constants, e.g., brp.pm
(3) Build the model, setting constants (e.g., 2 and 3)
(4) Build the model again, setting *other* constants (e.g., 22 and 3)
In step (4), the log file reflects the changed constants,
but the generated model has the same number of states as
in step (3) and is fact built with the constants of step (3).
The cause:
If the PRISM file is not reloaded, then the currentModelGenerator
remains the same. In ModulesFileModelGenerator.initialise(), called
from setSomeUndefinedConstants() in step (3), the modulesFile is
overwritten with the modulesFile where the constants set in step (3)
have been replaced in the AST with the concrete values.
In step (4), there are no more AST-elements with undefined constants
and hence the modules file does not reflect the changed constants when
the constants in the constant list are changed.
The fix is to keep a copy of the original modules file in the
ModulesFileModelGenerator which is freshly deepCopyied and
processed in the subsequent calls to initialise().
Regression introduced in SVN r10996 when switching to the
ModulesFileModelGenerator infrastructure.
git-svn-id: https://www.prismmodelchecker.org/svn/prism/prism/trunk@11159 bbc10eb1-c90d-0410-af57-cb519fbb1720
Now, double-clicking on a property will open the editor
for that property. Double-clicking on an empty area of the
property list will open the "new property" editor.
git-svn-id: https://www.prismmodelchecker.org/svn/prism/prism/trunk@11109 bbc10eb1-c90d-0410-af57-cb519fbb1720
Joachim Klein