In particular, we currently cache the numerical method convergence settings.
This allows the values that were used for solution to be recalled at the Java level.
There is no explicit model type keyword added to the parser.
Instead, LTSs are auto-detected by the absence of probabilities.
ConstructModel is extended to build LTSs. Model checking (CTL+LTL)
can be done out of the box using the existing NonProbModelChecker class.
A few MDP regression tests are clarified to make it clear that the
models are MDPs, not LTSs.
The States header in HOA automata is optional. Previously, we aborted
if it was missing. As we can allocate states in the generated DA
on-the-fly, to support parsing a HOA automaton with absent State
header, we just have to dynamically allocated states and track that
all states that are used somewhere are actually defined.
Rename the class to match those for other models stored in this way.
And add some missing methods to make it usable as a normal model.
Also tidy up the class a bit.
Make this method, which is used to check that doubles are (approximately) equal,
use relative rather than absolute error, which is more robust in general.
This is now used in places where the same check was done, but with an (identical)
hard-coded epsilon of 1e-12. Property.getExpectedResultString has also been changed,
which previously used 1e-10, but there seems no reason for this not to use 1e-12.
This just sets a null action for all existing transitions. Previously,
this was in DTMCExplicit, but has been removed from there. This means
it can also be removed from DTMCView.
In fact the implementation is taken from DTMCView, which was cleaner.
Furthermore, the same mechanism is now also used for implementing
getTransitionsAndActionsIterator in DTMCFromMDPMemorylessAdversary.
This accesses the MDP storage directly, rather than via getTransitionsIterator.
Not really used at the moment since methods that need to be fast, like matrix-vector
multiplication, are directly implemented already.
Currently these do not actually make much sense anyway since the class is primarily
intended to store distributions over indices into some other list (e.g., states).
This returns a map view of the (optionally stored) label info,
i.e., a map from label name strings to Bitsets of satisfying states.
A default implementation is added using existing methods.
Move getNumTransitions(int) to Model from DTMC.
There is a default implementation using getSuccessorsIterator(int).
This allows us to provide a default implementation of getNumTransitions() too.
Also move getNumTransitions(PrimitiveIterator.OfInt) to Model from DTMC/NondetModel.
In the C++ code, use |v1-v2/v1| rather than |v1-v2/v2|.
In the Java code, remove the special case where v1 and v2 are < 1e-12.
Should have minimal effect on convergence in practice,
but makes debugging easier to have engines consistent.
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.
Instead, store the variable name and DeclarationType separately.
DeclarationType stores the type info we actually need, e.g.,
ranges for bounded integer variables. Declaration has other
information such as initial values, which is not needed here.
A new addVar(name, declType) method is added (and preferred).
Methods to add variables via Declarations remain, for convenience.
VarList should focus on the range, structure, etc. of the variables.
The initial values of the variables for a model are stored separately.
This info was only accessed from Modules2MTBDD,
which now extracts initial variable values itself,
and uses the VarList.encodeToInt helper method.
Checking that bounded integer vars are in range is now moved there.
Dave Parker