Conversation
…nal for scheduler parameter
…nclude IntervalForward in tests
…related components and added tests - Updated AddUncertainty transformer to handle RationalNumber types, allowing for exact arithmetic with RationalInterval. - Modified various helper functions and model checkers to accommodate RationalNumber and RationalInterval. - Introduced new tests for RationalNumber scenarios in model checking and uncertainty transformations. - Ensured compatibility with existing models while expanding functionality for uncertain models using RationalNumber.
…reachable from any condition states
|
The failing tests have to deal with some irritating floating point errors leading to incorrect values for pMin and pMax in bisection advanced. The failing test specifically has a pMax that is about 10^-9 below the true value. This is also outside the standard 10^-12 bound we keep for floating point comparisons. The result of the floating point error is a lower bound > 1 by about 10^-6 (i.e. 1.0000001). I am not entirely sure how to tackle this. Using the conditional tolerance does not seem right. |
|
Without sound methods in the backend, this can indeed happen. I would mark the tests as skip/expect fail maybe. We should probably open an issue to ensure that we have the ability to run this with a sound backend and make sure that we test the logic with exact arithmetic as well. |
…omputeConditionalProbabilities function
tquatmann
left a comment
tquatmann
left a comment
There was a problem hiding this comment.
Thank you for the PR! Great Work :)
I have some of the usual nitpickings.
Most importantly, I'm not a big fan of introducing the top level tolerance in this PR because it would (for now) only apply to conditional probabilities.
Also, --minmax:precision 0 might have some weird side-effects that we are currently unaware of.
| #pragma once | ||
|
|
||
| #include "storm-config.h" | ||
| #include "storm/adapters/RationalNumberAdapter.h" |
There was a problem hiding this comment.
(Without having any knowledge of the rest) Is it possible to use RationalNumberForward here? I think this include spreads through some parts of the code base and it would be best if we could avoid including the header here.
There was a problem hiding this comment.
For other settings, we just use double here and convert to rational in the Environment. I don't mind having rationals here, though.
There was a problem hiding this comment.
I went for double as there is no good rational argument yet as far as I could find.
|
precision zero should not be necessary anymore if the precision does not control the tolerance... I think tolerance was introduced exactly to also allow non-zero precision in the exact case. |
|
Ahh, I see. Exact arithmetics with non-exact solutions is something that we can't really specify right now. Imo, the current solution is a bit unclear (what is the difference between tolerance vs. precision?). But it's also not obvious to me how to solve this. Do we have to introduce support for that in this PR? |
tquatmann
left a comment
tquatmann
left a comment
There was a problem hiding this comment.
I believe the precision configuration should be streamlined with other algorithms. See LongRunAverageSolver[Environment|Settings.h for example.
- For the sake of consistency, should we call it "precision" and not "tolerance"?
- The ConditionalModelCheckerEnvironment needs a
bool relativeflag. Right now this is apparently always read fromminmaxsettings. - The tolerance/precision setting in the ConditionalModelCheckerEnvironment should also apply for the restart method and for the (unconditional) reachability analysis used to obtain the Normal form (we can configure the
analysisEnvin theConditionalHelperaccordingly - Conditional DTMC model checking should now also read the precisions from the ConditionalModelCheckerEnvironment now.
- In the CLI, we can currently set e.g.
--precision 1e-10which then applies to all kinds of precisions. Setting--exact(without specifying a precision) always yields the exact rational number result. I'm very much in favour of keeping it this way with conditionals. This would require a new settings module, though. See e.g.LongRunAverageSolverSettings.hfor example. To handle cases where we want to have an approximate solution with exact arithmetics, I suggest something like--exact --conditional:precision 1e-4. In settings modules, we have been usingbool is[...]SetFromDefaultValue()functions to implement this kind of behaviour.
Once that is clarified, we're ready to merge (as far as I'm concerned).
…g of precision when exact.
|
I only have not found a solution to let DTMC conditional queries use the conditional precision. This is because many different precisions could be used depending on the linear equation solver type. It is not clear to me how I could set the precision used for the conditional queries. (Looking at the tests they set many different precisions for different possible environments) |
5 participants
No description provided.