- 12 Apr, 2019 3 commits
-
-
Hans-Peter Deifel authored
-
Hans-Peter Deifel authored
-
Hans-Peter Deifel authored
-
- 11 Apr, 2019 1 commit
-
-
Hans-Peter Deifel authored
-
- 10 Apr, 2019 1 commit
-
-
Hans-Peter Deifel authored
-
- 09 Apr, 2019 8 commits
-
-
Hans-Peter Deifel authored
-
Hans-Peter Deifel authored
-
Hans-Peter Deifel authored
-
Hans-Peter Deifel authored
-
Hans-Peter Deifel authored
-
Hans-Peter Deifel authored
Changes the previous hard error into a warning. We now just cap the number of transitions at the maximum which allows for easier bisection benchmarks that start at a low number of states.
-
Hans-Peter Deifel authored
The existing algorithm for generating unique transitions is inefficient if the transition count is close to the maximal number of transitions. This now switches to a different algorithm if the transition count is above 70% of the maximum.
-
Hans-Peter Deifel authored
-
- 08 Apr, 2019 3 commits
-
-
Hans-Peter Deifel authored
When the user requests more transitions than the maximal number for the given automaton, the current generator runs into an endless loop trying to find new unused transitions. We now detect this case early and throw an error.
-
Hans-Peter Deifel authored
It's now used to specify how many transitions you want instead of how many transitions per state. This is strictly more powerful because you can always just specify states*out-degree as transition count.
-
Hans-Peter Deifel authored
-
- 05 Apr, 2019 4 commits
-
-
Hans-Peter Deifel authored
64bit ints were just too small to fit the number of edges in very big graphs.
-
Hans-Peter Deifel authored
The current way of iterating trough all possible edges and deciding for each edge if we take it or not has proven not to scale to large but sparse graphs. Instead, we now generate the edges that we want directly.
-
Hans-Peter Deifel authored
-
Hans-Peter Deifel authored
-
- 04 Apr, 2019 4 commits
-
-
Hans-Peter Deifel authored
-
Hans-Peter Deifel authored
This already does all we need, so instead of duplicating the whole implementation, just use it.
-
Hans-Peter Deifel authored
Even if it only allows a range of [1,2], it's there for completeness and makes the benchmark script a bit easier.
-
Hans-Peter Deifel authored
This is currently only implemented for the case where --different-values is supplied. When the random experiment says that we should generate non-zero edge, we should rule out the possibility that this edge gets assigned a random weight of zero. With small --different-values, zero edges would have become way more likely.
-
- 03 Apr, 2019 3 commits
-
-
Hans-Peter Deifel authored
-
Hans-Peter Deifel authored
Otherwise states get one of 2^64 different values in the initial partition, meaning that they will be distinguished already.
-
Hans-Peter Deifel authored
This switches from floats to a sort of arbitrary precision base10 floating point implementation where we can easily generate uniform random numbers. The problem with floats is that they aren't distributed equally across the whole range and thus a random number in [0, 1) is not uniform.
-
- 28 Mar, 2019 1 commit
-
-
Hans-Peter Deifel authored
This was also renamed accordingly in CoPaR itself
-
- 25 Mar, 2019 6 commits
-
-
Hans-Peter Deifel authored
Hides ugly debug output from stderr but instead persists it in the generated file, in case someone wants to re-generate it (e.g. after fixing a bug in the generator).
-
Hans-Peter Deifel authored
-
Hans-Peter Deifel authored
-
Hans-Peter Deifel authored
-
Hans-Peter Deifel authored
-
Hans-Peter Deifel authored
-
- 22 Mar, 2019 1 commit
-
-
Hans-Peter Deifel authored
-
- 21 Mar, 2019 3 commits
-
-
Hans-Peter Deifel authored
This highlights the fact that they represent finite sets and the value syntax are hexadecimal unsigned integers.
-
-
Hans-Peter Deifel authored
-
- 18 Mar, 2019 1 commit
-
-
Hans-Peter Deifel authored
-
- 14 Mar, 2019 1 commit
-
-
Hans-Peter Deifel authored
-