- 09 Nov, 2018 8 commits
-
-
Hans-Peter Deifel authored
-
Hans-Peter Deifel authored
ma -> copar
-
Hans-Peter Deifel authored
-
Hans-Peter Deifel authored
-
Hans-Peter Deifel authored
-
Hans-Peter Deifel authored
Previously we injected each state into `a`, which had to implement `Ord`. Now the caller has to supply `(State -> State -> Ordering)` and handle the comparision itself. This is more efficient if the caller knows a better way than to dynamically dispatch on the Ord interface. Note that unfortunately there is now way around the constant boxing and unboxing of `State` values at the boundary of the higher order function.
-
Hans-Peter Deifel authored
Fixes #1
-
Hans-Peter Deifel authored
Bools can't be unpacked as of GHC <= 8.6, because Bool ain't a single-constructor data type.
-
- 08 Nov, 2018 1 commit
-
-
Thorsten Wißmann authored
We don't need to know the count of edges that go outside of the block of interest. It only matters whether there is one, so that we can correctly return H3 in update.
-
- 07 Nov, 2018 3 commits
-
-
Hans-Peter Deifel authored
-
Hans-Peter Deifel authored
-
Hans-Peter Deifel authored
-
- 06 Nov, 2018 4 commits
-
-
Hans-Peter Deifel authored
The pattern x <- read foo modify foo (+1) unfortunately generates one more actual read than x <- read foo write foo (x+1)
-
Hans-Peter Deifel authored
The property-arrays for StateRepr and BlockRepr were always stored as a struct of arrays instead of an array of structs, but the way that Data.Vector.Unbox works meant that you could not write to one array without also writing to the other one. In Haskell, code like write vec i struct { field1 = value } would write all fields of `struct` instead of only `field1`, since the compiler doesn't know that the fields can be stored separately. This is now fixed by hand-implementing the struct-of-arrays data layout.
-
Hans-Peter Deifel authored
-
Hans-Peter Deifel authored
-
- 05 Nov, 2018 5 commits
-
-
Hans-Peter Deifel authored
At least for the from/to values, as they are just Ints. Labels can be anything, which means that they have to be boxed. This means that were we previously had Edges: | | | | \ `- (Int, , Int) | `- Label We now have: TOs: Int | Int | Int FROMs: Int | Int | Int Labels: | | \ `- Label Which results in faster access to edges, especially if the label is not required. (E.g. when enumerating predecessors of a state).
-
Hans-Peter Deifel authored
-
Hans-Peter Deifel authored
-
Hans-Peter Deifel authored
-
Hans-Peter Deifel authored
This gives a small speed boost, but most importantly can save lot's of space and pointer indirections.
-
- 02 Nov, 2018 19 commits
-
-
Hans-Peter Deifel authored
This merge commit adds an NFData instance on SomeLabel in the RELEASE case.
-
Hans-Peter Deifel authored
-
Hans-Peter Deifel authored
-
Hans-Peter Deifel authored
-
Hans-Peter Deifel authored
-
Hans-Peter Deifel authored
-
Hans-Peter Deifel authored
This changes the command line flag from --apply-ast-transforms to --no-functor-transforms.
-
Hans-Peter Deifel authored
-
Hans-Peter Deifel authored
-
Hans-Peter Deifel authored
While AbsorbingPolynomial has brought down the running time in many cases, it unfortunately required quite a bit more memory than the old Polynomial, even though the number of states and edges was reduced. The problem here was that: 1. The overall number of labels, weights and H1 values was _not_ reduced, they were just moved into the corresponding type of AbsorbingPolynomial. The only thing saved was the `Sorted` layer on the inner data. 2. On the flip side, the old Polynomial implementation could use very memory efficient unboxed vectors for nearly everything, whereas AbsorbingPolynomial has to store wrapped SomeFunctor values (which are not unboxable). This is now solved by being very memory conscious in the implementation of Label, H1, H3 and Weight for AbsorbingPolynomial. E.g we use the primitive SmallArray type instead of Vector and try to avoid indirections introduced by Maybe or Either wrappers wherever possible.
-
Hans-Peter Deifel authored
-
Hans-Peter Deifel authored
This interprets the P(AxX) functor in MDPs slightly differently. Instead of using labels for choices, we use unlabeled transitions and partition the choice-states on their choice instead in the initial partition. This corresponds more faithfully to the graph representation of the coalgebra in our program.
-
Hans-Peter Deifel authored
For much a much better GHCi experience!
-
Hans-Peter Deifel authored
-
Hans-Peter Deifel authored
-
Hans-Peter Deifel authored
There was a typo so that it would always parse as the summand 0. Yay, tests!
-
Hans-Peter Deifel authored
These are just the tests originally from Polynomial. Some of them are failing right now.
-
Hans-Peter Deifel authored
-
Hans-Peter Deifel authored
-