Thanks! Merged and pushed. I'll send a quick announcement to downward-dev.

Looks good to me, though I didn't try to predict how it appears in the help
output and/or wiki documentation.

I have implemented your suggestion. The code at
https://bitbucket.org/jendrikseipp/downward/pull-request/33
uses the new Bounds object where we previously used a manual check and called 
parser.error() if the check failed (i.e. gapdb and ipdb). Can you have a look at 
the code, please?

> My plan would be to remove the optional OptionFlags argument and add optional
> lower_bound = "" and upper_bound = "" arguments.

Too many positional arguments make for hard to read code, especially if they are
all the same type (all strings), since the compiler won't be helpful. It may be
better to wrap the extra information up in a type that communicates the intent
clearly, e.g instead of

    add_option(lots, of, options, "10", "100")

something like

    add_option(lots, of, options, Bounds("10", "100"))

would be clearer and would cause an error if the positions are counted wrong.
(It's a pity C++ doesn't have something like keyword arguments, but techniques
like this one can be used to simulate them to some extent, especially when
combined with variadic functions.)

Regarding msg4387: for what it's worth, it would be interesting to see how well
an "unbiased" configurator that does not get expert information like "don't try
high values of m in h^m" would perform, in particular how the results compare to
one with a "biased" set like the one we currently use.

This seems like an interesting research challenge for the programming by
optimization community: how much expert information do we need, and for which
parts of the problem can our algorithms do better than the human? For that it
would be very nice to have an automated SMAC output that reflects the true
parameter space.

Currently, I am using a subclass of DocPrinter to write the SMAC files (issue550). 
This class is passed each Plugin as a DocStruct, which in turn holds documentation 
about its parameters in a vector of ArgumentInfo. Since this vector is not 
efficiently indexable by parameter name, I'd propose to add the parameter ranges 
to the ArgumentInfo at the same time, the remaining ArgumentInfo attributes are 
set. This would require passing the bounds to parser.add_option(). 

My plan would be to remove the optional OptionFlags argument and add optional 
lower_bound = "" and upper_bound = "" arguments. The strings would be turned into 
the respective types in the same way as is currently done for the default value. 
What do you think about this approach?

That's true. However, I believe that there are some cases where we can define 
helpful lower bounds. This would remove a little bit of the manual work for 
writing SMAC parameter files and would improve our input sanity checks (e.g. we 
can at the moment pass values < 1 to h^m without the parser noticing). 
Depending on the amount of work required for this, I might or might not pursue 
this issue now.

Just a word of warning: I'm not sure how useful this will be for SMAC. The
allowed range and the range you want to ask SMAC to consider can be quite
different in many cases. For example for weighted evaluators we can allow ranges
between -2^31 and +2^31 - 1 (maybe make them narrower to avoid overflow issues,
but any given limit would be rather arbitrary), but in your SMAC experiments the
ideas was to only consider the range 1..10. For h^m and lm_hm, we shoud permit
arbitrarily large values {1..2^31 - 1}, but for SMAC you probably want to limit
it to something like {1, 2, 3, 4}. I guess the majority of cases will be like that.

Allow specifying parameter ranges in the option parser. This allows us to check 
the values already during parsing and makes the code more consistent. E.g. 
currently these checks are performed in different places for each heuristic. 

Also, that information could be used for generating parameter files for tools 
like SMAC which need parameter ranges for the tuning process.