Closed.

I agree -- ready to merge.

Here are the results:
http://ai.cs.unibas.ch/_tmp_files/sieverss/2014-02-13-issue411-v1-conf.html

Except for some smallish memory changes, I cannot see anything strange.

I was just trying to avoid unnecessary work. :-)

Well, I already set up the scripts (and tagged revisions) and these are very
small experiments anyway. And if I wanted to combine them, I'd need to integrate
two branches into a different repo/branch whatsoever. So I think unless you
don't insist on only having one experiment, I'll do two (for the moment).

For what it's worth, I think it's definitely enough to run one experiment for
all the current changes to iPDB rather than one for each change.

I changed the handling of pair<int, int>.

I'll run a small experiment to make sure everything is okay.

Looks good to me, but I didn't have much time to look carefully. (If you prefer
to have a more careful review, maybe ask someone else to have a look since I'm
overbooked for the next week.) The one change I'd make is to return the
pair<int,int> rather than pass it as an output parameter.

I removed the special case, incorporated your suggested note for the parser and
split up hill_climbing into smaller pieces.

I would prefer to get rid of the special case because it's more code, and even
with it, we still have to get the general case correct in corner cases where the
set of candidates runs empty, e.g. because we have included all possible
patterns. (By "empty" here I mean "logically empty", e.g. full of 0 entries.)

To avoid problems like in issue408, one thing we could try to do is break up the
hill_climbing method into smaller chunks. I think it is so large that it is very
easy to introduce bugs at the moment.

You are right that we actually do not need any additional test against empty
initial candidate patterns.  The questions is whether we want to take any
measurements to prevent such problems in future from happening again and/or how
we would fix the problem from this issue in issue408.

Malte, I sent you a code review invitation.

The bug in question can only occur in the branch issue408, see msg2905.

I still implemented a few changes to prevent such accidents in future.

If pdb_max_size is of size such that no goal-pattern can be extended without
compromising the allowed maximum size, then a segmentation fault occurs when
trying to access a candidate pattern at an invalid index.