Merged and pushed.

In v8, I moved LabelGroupConstIterator to transition_system.h and changed it to
TSConstIterator, also having a reference to the grouped transitions. This allows
easy iteration over TransitionSystem objects from outside the class.

The performance did not change:
http://ai.cs.unibas.ch/_tmp_files/sieverss/issue571-v8-issue571-base-issue571-base-issue571-v7-issue571-base-issue571-base-issue571-v8-compare.html

To keep track for the overall change, I also included the baseline and compared
the newest version v8 against it. The changes are very small, and there is a
trend for better runtime and more memory consumption.
http://ai.cs.unibas.ch/_tmp_files/sieverss/issue571-v8-issue571-base-issue571-base-issue571-base-v2-issue571-base-issue571-base-issue571-v8-compare.html

In v7, I moved the implementation of the iterator class used for iterating over
label groups of LabelEquivalenceRelation into the cc-file, hence no more
inlining possible for the typical iterator methods. Still, performance did not
really change:
http://ai.cs.unibas.ch/_tmp_files/sieverss/issue571-v7-issue571-base-issue571-base-issue571-v6-issue571-base-issue571-base-issue571-v7-compare.html

In v6, I replaced list by vector for storing LabelGroup objects. Somewhat
surprising for me, this increases memory usage (probably due to reserving memory
to be able to store max num labels many label groups in the worst case), and
slightly reduces runtime for most of the configs, and the other way round for
some others. Again, I am fine with that for now.
http://ai.cs.unibas.ch/_tmp_files/sieverss/issue571-v6-issue571-base-issue571-base-issue571-v5-issue571-base-issue571-base-issue571-v6-compare.html

In v5, I introduced an Iterator class that allows TransitionSystem and others to
iterate over LabelGroup objects more easily without knowing the underlying
container type.
The time slightly increased, but for the moment, I am fine with that:
http://ai.cs.unibas.ch/_tmp_files/sieverss/issue571-v5-issue571-base-issue571-base-issue571-v4-issue571-base-issue571-base-issue571-v5-compare.html

I know, these are just for the record.

In v3 and v4, I moved more functionality from TransitionSystem to
LabelEquivalenceRelation. Together, the change results in a neutral or very
light improvement of performance:
http://ai.cs.unibas.ch/_tmp_files/sieverss/issue571-v3-issue571-base-issue571-base-issue571-v2-issue571-base-issue571-base-issue571-v3-compare.html
http://ai.cs.unibas.ch/_tmp_files/sieverss/issue571-v4-issue571-base-issue571-base-issue571-v3-issue571-base-issue571-base-issue571-v4-compare.html

I won't be able to look at this while I'm on holidays, but this sounds good! :-)
Feel free to merge at any time if you want, or else we can get back to this in
September. (In that case, please ping me again once I'm back!)

I merged from default again, as we had to apply a few fixes in M&S in the
default branch (due to failures on Windows). The results compared to the new
baseline look even better:
http://ai.cs.unibas.ch/_tmp_files/sieverss/issue571-v2-issue571-base-issue571-base-issue571-base-v2-issue571-base-issue571-base-issue571-v2-compare.html

Unrelated to this issue, I also compared the two baseline versions:
http://ai.cs.unibas.ch/_tmp_files/sieverss/issue571-v2-issue571-base-issue571-base-issue571-base-v2-issue571-base-issue571-base-issue571-v2-compare.html
There is a slight increase in memory, and a slight reduction in runtime.

Unfortunately, I conducted the wrong experiments in the link I posted below --
the link name already hints at wrong issue tags, and that was the error indeed.

Here are the correct ones:
http://ai.cs.unibas.ch/_tmp_files/sieverss/issue571-v1-issue571-base-issue571-v1-compare.html

They do not look as promising, but they also do not really worsen performance, I
think. Sometimes, the score search time goes down in average very slightly, but
I think that's ok.

I think that I'll go with 2, at least for this particular issue. I'll also be on
holidays for two weeks while you are.

Sorry, I fear I won't have time to review this properly and/or give proper
recommendations before my holidays. Three options:

1. We keep this on hold until I'm back.
2. You continue working on the refactoring on your own and merge what you like,
and we'll look at the then current version together when I'm back.
3. You keep working on this and get someone else involved for code reviews.

Please take your pick! :-) (Or recommend a fourth option, of course.)

I am not quite sure how to improve from here: TransitionSystem still directly
uses LabelGroup objects quite heavily, i.e. it the information about label
groups is still used as before, but it just lives in a new class now. The same
is true for ShrinkBisimulation and MergeDFP. Should we dissolve this dependence
more, by moving more functionality towards the new class
LabelEquivalenceRelation? I am not sure if this worked well for composite
construction of LabelEquivalenceRelation and computation of the actually local
equivalence relation, as these computations require access to the transitions,
and I don't think that LabelEquivalenceRelation should know anything about
transitions (that was the whole idea of the separation, right?). I also remember
that you thought about changing the way of storing equivalent labels -- should
we do something alone those lines?

Yes: https://bitbucket.org/SilvanS/fd-dev/pull-requests/9/issue571/diff

Nice. :-) Is it possible to look at a diff somewhere?

v1 moves out LabelGroup and all related data structures to a separate class.
TransitionSystem uses the same interface as before, but via the new class. The
experiments look good:
http://ai.cs.unibas.ch/_tmp_files/sieverss/issue571-v1-issue561-base-issue561-v1-compare.html

This is part of meta issue567 and intends to take item B) further, i.e. the
separation of more code from TransitionSystem. In this issue, we want to come up
with a separate data type to store an equivalence relation on the labels. (We
will also clean-up some unrelated things, such as getting rid of the "expensive
statistics" method.)