> 1) I did that because the compiler complained about ambiguity.

For the future: this happens when there are multiple equally good matches
because some of the passed-in parameters are int and others are size_t. The
recommended solution is to convert them when calling the function so that they
are homogeneous.

Merged and pushed.

1) I did that because the compiler complained about ambiguity.

2) Ok, done.

1) Don't use overloads with different names; this clashes with C++ style. If we
use overloads, they should share the common name.

2) I'm not sure we need a size_t overload. I think it's no problem to bound
pattern size at roughly 2 billion when compiling for 32-bits. With our current
representation as a vector<int>, the actual limit is below 1 billion anyway.
(And even if we used single bytes, there

Also, the other pattern generator ("greedy") uses int for the size bound
parameter (we don't currently use unsigned int options, I think), and I think it
would be odd to have patterns that can only be specified manually.

In summary: I suggest reverting all changes to is_product_within_limit and using
the existing int-based function.

I applied a patch. Does someone wants to have a quick look, e.g. Florian?
https://bitbucket.org/SilvanS/fd-dev/pull-requests/13/issue647/diff

The "is_product_within_limit" from the utils::math package should do, if you
make a copy for size_t.

I was wrong -- I read the 12 as a 2 and thought the result was fine. The
overflow is that large that I need a better test against ist.

I cannot confirm this bug. I agree that num_states could overflow (there is an
explicit comment in the header about assumptions on the size of the given
pattern), but not with the given example.

I patched the code with the attached patch (basically including output and
adding a check for overflow). When executing the command line 

./fast-downward.py --debug domain.pddl 3-4-puzzle-problem-200-01.pddl --search
"astar(pdb(manual([0, 1, 2, 3, 5, 6, 7, 8, 9])))"

I obtain the following output:
1 * 12 = 12
12 * 12 = 144
144 * 12 = 1728
1728 * 12 = 20736
20736 * 12 = 248832
248832 * 12 = 2985984
2985984 * 12 = 35831808
35831808 * 12 = 429981696
429981696 * 12 = 864813056
PDB construction time: 8.97174s

Everything seems fine to me. I did not look at the task to check whether the
code should indeed not report the initial state as a dead end, but if you say
so, then the bug must be somewhere else.

I'll do it.

Any volunteers for working on this? :-)

While playing around with the PDB heuristic, we encountered a bug that is caused
by an overflow of the num_states variable in "pattern_database.*". "num_states
is computed in the constructor of PatternDatabase. 
It happens when using the following pattern: "manual([0, 1, 2, 3, 5, 6, 7, 8,
9])" in the attached task. The heuristic will falsely detect the initial state
as a dead-end. "Falsely" here means that with the given pattern, the PDB should
not be able to detect the task unsolvable in the initial state, although the
task indeed is unsolvable. 
One could probably argue that, when using a manual pattern, you should always be
careful to check for the size of the abstract state space. On the other hand,
including a check is quite easy (in this case), and even just getting an error
is better than a wrong result.