Merged.

Yes, please merge. Thanks!

Ok, I inserted the std::sort. Experiments in debug mode show that the assertion
no longer fails, and experiments in release mode show that the change did no
significant damage:

http://ai.cs.unibas.ch/_tmp_files/pommeren/issue482-base-issue482-v1-compare-debug.html#unexplained-errors

http://ai.cs.unibas.ch/_tmp_files/pommeren/issue482-base-issue482-v1-compare-release.html

Should I merge?

This is not time-critical, so if std::sort is fastest, that would be my
preferred solution.

I can think of several ways to get a sorted vector in this function and have
little intuition which would be best.

1) std::sort would result in the simplest code.
2) erase-remove idiom (filtering out the elements from the vector that are not
in the hash_set) should have amortized linear runtime but more complicated code.
I'm not sure if it would pay off on the smallish patterns.
3) We could copy from the hash_set to a std::set and then to the vector.
4) We could use a std::set instead of the hash_set throughout the whole method.

I think it's a good idea to keep the assertion. Sorting patterns is cheap, and
normalized data is often useful, e.g. for debugging. Sorting patterns also helps
finding duplicates.

The pattern database heuristic asserts that its pattern is sorted. I don't know
if this assumption is used somewhere currently. However,
PatternGenerationEdelkamp creates ZeroOnePDBsHeuristics with pattern collections
of unsorted patterns, e.g. in airport/p16.
I had a look at the code and it looks like patterns are sorted up until the call
to remove_irrelevant_variables. This method uses a hash set to filter some
variables from the pattern and iterating over this set returns the variables
without order.

We could either keep the variables sorted here or change the assertion if
unsorted patterns are acceptable.