Issue913

Title Wrong behaviour with undefined numeric expressions
Priority bug Status resolved
Superseder Nosy List gabi, malte
Assigned To Keywords translator
Optional summary
TODOs:

- Once this is resolved, report back to Emil, e.g. in the Fast Downward mailing
list thread, replying to Malte's email that referenced this issue (21.05.2019
16:54 CEST).

Created on 2019-05-03.09:15:48 by gabi, last changed by gabi.

Summary
TODOs:

- Once this is resolved, report back to Emil, e.g. in the Fast Downward mailing
list thread, replying to Malte's email that referenced this issue (21.05.2019
16:54 CEST).
Files
File name Uploaded Type Edit Remove
domain.pddl gabi, 2019-05-03.09:15:48 application/octet-stream
p01.pddl gabi, 2019-05-03.09:16:01 application/octet-stream
Messages
msg11570 (view) Author: gabi Date: 2024-02-01.17:43:49
Thanks Remo for the review! The change has been merged.
msg11556 (view) Author: gabi Date: 2024-01-31.14:18:40
I fixed the bug as discussed. Any takers for a review?

We see the effect of the change clearly in the output of the model computation (translator_auxiliary_atoms, translator_relevant_atoms, translator_final_queue_length, translator_queue_pushes). Auxiliary atoms are the ones included when splitting rules of the Prolog program. The atoms added for taking care of the numeric expressions are counted towards the relevant atoms. I am somewhat surprised that the number of auxiliary atoms and queue_pushes decreases in some domains. Malte, you know the inner workings of the Prolog model transformations. Can this make sense?

Apart from this, the runtime for generating and normalizing the program is only mildly affected. Computing the model is slightly slower in some domains but the changes in the overall time for instantiation looks ok to me (overall a few seconds faster but lots of variance in both directions).

Since the bug did not occur on the benchmarks, the instantiated operators are not affected (as expected).

Pull request: https://github.com/aibasel/downward/pull/216
Experiments: https://ai.dmi.unibas.ch/_experiments/ai/downward/issue913/data/issue913-v1-eval/issue913-v1-23499409976f669b036ef162b2835832f01d2fb2-issue913-v1-compare.html
msg11546 (view) Author: gabi Date: 2024-01-30.12:10:10
We agreed to resolve this in the reachability analysis.
msg8832 (view) Author: malte Date: 2019-06-06.11:16:12
I think the warnings would definitely be useful, though. Perhaps we can make
them an optional feature.
msg8769 (view) Author: gabi Date: 2019-05-04.08:40:09
Making this part of the grounding algorithm would have the advantage that we
could also eliminate other, then unreachable action.
msg8768 (view) Author: malte Date: 2019-05-03.12:46:24
My first impulse was to integrate the testing of well-definedness in the
grounding algorithm (for efficiency), but then we cannot easily get such
warnings because the failing actions are never generated.
msg8767 (view) Author: gabi Date: 2019-05-03.09:15:48
This was mentioned by Emil Keyder on the mailing list.

If some action refers to an uninitialized numeric expression, the translator
stops with "AssertionError: Could not find instantiation for PNE!". The correct
behaviour would be to simply not instantiate this action.

Maybe we should in this case include an output that the action was removed,
because otherwise this behaviour could easily hide modelling mistakes.
History
Date User Action Args
2024-02-01 17:43:49gabisetstatus: reviewing -> resolved
messages: + msg11570
2024-01-31 14:18:40gabisetstatus: chatting -> reviewing
messages: + msg11556
2024-01-30 12:10:10gabisetmessages: + msg11546
2019-06-06 11:18:01maltesetsummary: TODOs: - Once this is resolved, report back to Emil, e.g. in the Fast Downward mailing list thread, replying to Malte's email that referenced this issue (21.05.2019 16:54 CEST).
2019-06-06 11:16:12maltesetmessages: + msg8832
2019-05-04 08:40:09gabisetmessages: + msg8769
2019-05-03 12:46:24maltesetstatus: unread -> chatting
nosy: + malte
messages: + msg8768
2019-05-03 09:16:01gabisetfiles: + p01.pddl
2019-05-03 09:15:48gabicreate