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.
|
This PR builds on top of #886. |
…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.
| #include "storm/settings/Option.h" | ||
| #include "storm/settings/OptionBuilder.h" | ||
| #include "storm/settings/SettingsManager.h" | ||
| #include "storm/utility/constants.h" |
There was a problem hiding this comment.
Why does this include become necessary?
There was a problem hiding this comment.
These were left over after removing conditional tolerance. But since they are now back this is necessary again.
| #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.
|
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? |
5 participants
No description provided.