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.
This potentially allows checking of "symbolic" expressions for methods/engines
other than the parametric engine. It will also allow simplification of the
mechanisms for storing results from parametric model checking, aligning it
with other parts of the code.
In particular for a whole State, not just a substate.
Also for just some constants, with no variable values.
Can be used to get an expression symbolically in terms of constants.
For now, this provides a cleaner implementation of the default (unspecified)
model type being set to an MDP. Later, this will allow the actual model type
to be omitted or partially specified and derived from langage features.
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.
Dave Parker