 09 Apr, 2019 4 commits


HansPeter Deifel authored

HansPeter 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.

HansPeter 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.

HansPeter Deifel authored

 08 Apr, 2019 3 commits


HansPeter 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.

HansPeter 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*outdegree as transition count.

HansPeter Deifel authored

 05 Apr, 2019 4 commits


HansPeter Deifel authored
64bit ints were just too small to fit the number of edges in very big graphs.

HansPeter 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.

HansPeter Deifel authored

HansPeter Deifel authored

 04 Apr, 2019 4 commits


HansPeter Deifel authored

HansPeter Deifel authored
This already does all we need, so instead of duplicating the whole implementation, just use it.

HansPeter 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.

HansPeter Deifel authored
This is currently only implemented for the case where differentvalues is supplied. When the random experiment says that we should generate nonzero edge, we should rule out the possibility that this edge gets assigned a random weight of zero. With small differentvalues, zero edges would have become way more likely.

 03 Apr, 2019 3 commits


HansPeter Deifel authored

HansPeter Deifel authored
Otherwise states get one of 2^64 different values in the initial partition, meaning that they will be distinguished already.

HansPeter 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


HansPeter Deifel authored
This was also renamed accordingly in CoPaR itself

 25 Mar, 2019 6 commits


HansPeter Deifel authored
Hides ugly debug output from stderr but instead persists it in the generated file, in case someone wants to regenerate it (e.g. after fixing a bug in the generator).

HansPeter Deifel authored

HansPeter Deifel authored

HansPeter Deifel authored

HansPeter Deifel authored

HansPeter Deifel authored

 22 Mar, 2019 1 commit


HansPeter Deifel authored

 21 Mar, 2019 3 commits


HansPeter Deifel authored
This highlights the fact that they represent finite sets and the value syntax are hexadecimal unsigned integers.

Thorsten Wißmann authored

HansPeter Deifel authored

 18 Mar, 2019 1 commit


HansPeter Deifel authored

 14 Mar, 2019 10 commits


HansPeter Deifel authored

HansPeter Deifel authored
Fixes a syntax error that prevented this example from being parsed.

HansPeter Deifel authored
Corrects some typos and fixes the stack command used to execute the examples.

HansPeter Deifel authored
Removes lots of code duplication

HansPeter Deifel authored

HansPeter Deifel authored

HansPeter Deifel authored

HansPeter Deifel authored

HansPeter Deifel authored

HansPeter Deifel authored
