Thanks! :-)

Done.

Can you also add documentation?

http://www.fast-downward.org/OptionSyntax seems the right place for me. There is
already some discussion of integer arguments in section "Notes". I would either
expand it or break it out into a separate section.

Merged :-)

I left one more comment. Nicely done to capture the corner cases in the limits
test. I'm not sure I would have limited it to lower_limit < 0 and upper_limit >=
0, but I see that this simplifies the code, and with the given assertions I have
no objections.

Thanks! This is ready for another review.

I left some comments.

I created a pull request at
https://bitbucket.org/jendrikseipp/downward/pull-requests/119 .

I'm also in favor of having K, M, G, since I may have had the problem of having
extra or too few 0s as well...

Scientific notation for floats is actually already supported: for example, we
can write max_time=3e2 .

I agree with Malte. I think the K, M, G suffixes would also be very nice to make
configuration strings more human-readable.

I think K/M/G are widely used in other programs and could be nice. For me this
is not an urgently missing feature, so in the interest of keeping the tracker
lean, I think we should only keep this issue open if we actively want to pursue
this in the next few months.

Larger suffixes than G make no sense because anything larger than 2G is
unsupported. (We are limited by what fits into a 32-bit int.)

I'm currently not in favour of floating point suffixes because I don't see a
widely accepted standard and it's currently a case of YAGNI. We have very few
floating point options anyway.

I feel slightly more positive about scientific notation. I would not permit it
for integer options; I think it's good to follow the lead of common programming
languages, and these only use scientific notation for floats, not integers. 

Regarding scientific notation for floats, I don't think it's worth the time and
code complexity before we see an actual (not hypothetical) use case where it
makes things much nicer. So I would call YAGNI here, too.

I like the idea to add such a feature.

+ K, M, G is short and is intuitive (for computer scientist)
- Why not also T, P, E (because you currently do not need it)? And what about
very small numbers for float parameters? Somebody might want to work with some
parameter 0.0005, 0.00005, ... (should we use m, µ, n, p?)

What do you think about adding support for numbers in scientific notation? This
notation is widely used (also not in CS areas) and allows more freedom than any
hardcoded suffix can ever give us.
5e3 (5K), 2e7 (20M), 1e9 (1G) and respective for float options 1.1e2, 2e-4?

Many of the configurations that I use contain large integer values, e.g.,
"max_transitions=20000000" and it's easy to add or forget a trailing 0. What do
you think about adding support for K, M and G suffixes to the planner, i.e.,
allow writing 5K, 20M and 1G for integer options instead of 5000, 20000000 and
1000000000? (Let's hope the number of zeros is correct :-))