Resolved.

I added a test for negative values and convert each constant to an int directly
at the test value == int(value).

...and while we're testing numbers for validity, we might as well also verify
that they are >= 0, since numbers are only used for action costs, and action
costs may not be negative. (Of course it would also be fine to test this
wherever we associate the number with an action as an action cost -- maybe we
already have such a test anyway?)

If the input contains float literals that are also valid integers, such as
"5.0", won't the translator output also use "5.0"? (If not, where is the float
converted to an int?) It'd be good to convert this to an int as soon as check
that value == int(value) so that we know we'll be dealing with ints and not
writing decimal points to the output.

The translator now aborts if there occurs any fractional number in the PDDL
specification.

Malte, you can pull this change from my repo: branch "issue-114"

I will have a look into that. If it does not imply many changes, I will support
it in the translator, otherwise I will let the translator abort.

I'd rather not support it in the translator and preprocessor if we're not going
to support it in the search. But if that's the solution you prefer, if you want
to implement it and if the changes to the code are not too large, I won't object.

I only talked about the translator, how the search handles
this is an entirely different story.

I only propose to handle fractional action costs correctly
in the translator, because it would be hard for most people
to integrate the support into it by themselves. The search
component is much easier to understand, so if eventually
somebody wants to support fractional action costs in the
planner (or some parts of it), he can do this.

This means that the search currently should simply abort
if it sees fractional costs.

If one of us has too much time (haha), we could also think
about a translator option that does the scaling, but in my
opinion this should be optional.

Here's another one:

>>> 0.1 + 0.1 + 0.1 + 0.1 + 0.1 + 0.1 + 0.1 + 0.1 + 0.1 + 0.1
0.99999999999999989
>>> 10 * 0.1
1.0

The problem is not with the translator but with the search code. For example, a
path consisting of ten actions of cost 0.1 will be considered different from a
path with a single action of cost 1.

>>> print 2.1 - 2 - 0.1
8.32667268469e-17

In C++, what would you expect the following program to print? What does it
print? What does it print when you change the bounds 0 and 1 to 1 and 2?

#include <iostream>
using namespace std;

int main(int, char **) {
    int i = 0;
    for (double x = 0; x < 1; x += 0.1)
        i++;
    cout << "i = " << i << endl;
    return 0;
}

I don't really see that this scaling is necessary, mostly because I
don't see where we need to do much calculations with the action
costs in the translator. And at least with my python
10 * 0.1 == 1. ;-)

> Why don't we simply support fractional costs? It does not sound like so
> much work to me (at least not for the translator component)...

Proper support is another option, of course. But complaining would be much
better than the current behaviour.

If we were to support them, we should promote them to integer costs by scaling
(keeping the scaling factor somewhere so that we can give correct output). 

Using floating-point everywhere would open many cans of worms due to
floating-point inaccuracies; e.g. 10 * 0.1 does not equal 1. And of course
everything would become slower and use more memory.

Why don't we simply support fractional costs? It does not sound like so
much work to me (at least not for the translator component)...

The translator happily accepts problems with fractional action costs, but I
don't think it handles them correctly. (Probably the fractional part is just cut
off?)

It would probably be safest if fractional costs resulted in the translator
aborting with an error during parsing.

Example problem with fractional action costs attached.