Wrong kind of problem

[Shi-Raida]

The following problems are using fluent with RealType but the problem does not have the kind CONTINUOUS_NUMBERS. Is it not a bug?

• up:robot_with_static_fluents_duration
• up:robot_with_static_fluents_duration_timed_goals
• up:matchcellar_static_duration
• up:locations_connected_cost_minimize

[Framba-Luca]

Hi @Shi-Raida. We decided to remove the CONTINUOUS_NUMBERS flag when the RealType fluent is not used as a number in the expressions but only as a "placeholder" for actions durations and action costs (the 2 examples here).

Ineed, those problems you mentioned don't have the CONTINUOUS_NUMBERS flag but have the STATIC_FLUENTS_IN_DURATIONS (the first 3) and STATIC_FLUENTS_IN_ACTIONS_COST the 4th one.

A small example: you want to write the duration of an action move(l_from, l_to) as something depending from l_from and l_to. You need to define a fluent (for example distance), you set the duration as distance(l_from, l_to) (or any expression containing it) and then assign a value to each possible distance (e.g. distance(l1, l2), distance(l2, l3) etc.). This example is different from handling numbers in expressions as, after the grounding, you can just assign a fixed number to the different durations of the move action (because the distance fluent is static).

So, if a planner can handle this particular situation, but not numeric fluents in general, only the STATIC_FLUENTS_IN_DURATIONS flag will be specified.

[arbimo]

... This example is different from handling numbers in expressions as, after the grounding, you can just assign a fixed number to the different durations of the move action (because the distance fluent is static). ...

I think this is where we have a problem in this case: the problem kind should apply to the problem as it is currently, not as it may appear after an hypothetical transformation. In particular, one should not assume that the problem will be grounded.

[Framba-Luca]

I get that. The idea behind the decision is that CONTINUOUS_NUMBERS and STATIC_FLUENTS_IN_DURATIONS are 2 different features of the problem, and might be handled differently by an engine; this offers more granularity for the declared supported_kind.

The grouding was just to make an example

[alvalentini]

The motivation under this choice is more that with CONTINUOUS_NUMBERS we mean continuous numbers in numeric planning.

When we have only STATIC_FLUENTS_IN_DURATIONS and STATIC_FLUENTS_IN_ACTIONS_COST the problem is not numeric.

We followed in some way the semantic of the PDDL requirement :action-cost: https://ipc08.icaps-conference.org/deterministic/PddlActionCosts.html.

@arbimo Do you see any cases where an engine cannot correctly specify its specific supported kind?

[arbimo]

Comparison with PDDL is a bit misleading I believe since there is no notion of integer types there. So any cost, duration or numeric effect implies continuous numbers.

For instance, in a development branch of Aries, we currently support integer expressions (with static or non-static fluents) in durations, effects, and action costs. We do not support real expressions anywhere.

Currently, the only option that we have to have the problem kind faithfully capture this absence of support for continuous number is to remove the features:

• continuous time: even though we support it for any integer duration of actions. (note that continuous time is the default so it is very restrictive)
• action costs: even though we support any integer action cost expression (and all our examples are integer costs). because no kind allow distinguishing the presence of real values in the cost expression. However, I believe every example that we have uses integer for the costs

The motivation under this choice is more that with CONTINUOUS_NUMBERS we mean continuous numbers in numeric planning.

Then the name is very misleading. There are continuous numbers in this problem. (this is also what we stated in the report and documentation for problem kind)

When we have only STATIC_FLUENTS_IN_DURATIONS and STATIC_FLUENTS_IN_ACTIONS_COST the problem is not numeric.

I get what you mean and this is I believe accurately captured by the (SIMPLE|GENERAL)_NUMERIC_PLANNING kind. Yet anybody manipulating the problem in its current form must be able to deal with continuous numbers in expressions.

I don't think we would loose anything by giving {CONTINUOUS, DISCRETE, BOUNDED}_NUMBERS there obvious definition: the corresponding type appear in an expression. It would only require that temporal/optimal planners declare supporting continuous numbers in expressions. This in turn allows other solvers to declare that they do not support it.

[alvalentini]

Ok I get your point!
Then we should update how we set CONTINUOUS_NUMBERS and DISCRETE_NUMBERS and then update the supported kind of classical planners that handle action costs.

[alvalentini]

Hi @arbimo! We discussed this issue with @mikand and we propose to replace NUMERIC_FLUENTS, CONTINUOUS_NUMBERS and DISCRETE_NUMBERS with 8 different ProblemKind features:

• INT_FLUENTS
• REAL_FLUENTS
• REAL_TYPE_DURATIONS
• INT_TYPE_DURATIONS
• REAL_NUMBERS_IN_ACTIONS_COST
• INT_NUMBERS_IN_ACTIONS_COST
• REAL_NUMBERS_IN_OVERSUBSCRIPTION
• INT_NUMBERS_IN_OVERSUBSCRIPTION

What do you think?

We will try to keep the backward compatibility using the ProblemKind version introduced in #446

[arbimo]

I think that sounds great!

Just a quick question: would you coalesce INT to REAL if both are present?
For instance, if I have both actions with int costs and actions with real costs, would I have both features on or only the REAL_* one?

Both answers are correct I believe as from my understanding, the REAl_* variant is always more general than the INT_* one. So anyone support a REAL_XXX must also support its INT_XXX special case.

By only deprecating the previous features I think it should be possible to maintain backward compatibility. But I am struggling to see an elegant way where the user does not have to opt-in 😨

[alvalentini]

I would set both the REAL_* and the INT_* features in that cases.