Issue458

Title handling degenerate inputs to preprocessor and search
Priority bug Status chatting
Superseder Nosy List florian, gabi, jendrik, malte
Assigned To Keywords
Optional summary
Related to issue1069

Created on 2014-08-27.12:12:52 by malte, last changed by gabi.

Summary
Related to issue1069
Messages
msg3365 (view) Author: florian Date: 2014-08-28.11:24:37
I agree with Jendrik.
msg3356 (view) Author: jendrik Date: 2014-08-27.15:29:10
I vote for YAGNI. We can reconsider once someone needs this functionality.
msg3354 (view) Author: malte Date: 2014-08-27.15:09:39
I just found issue54 (our current record holder for the open issue with the
longest period since the last activity, though this will change in a minute),
which describes why right now we essentially don't support derived variables
with more than 2 values. There are two options here:

D1 (YAGNI): Disallow derived variables with more than 2 values. (We never
generate these ourselves.)

D2 (purity): Change the code to make it possible to support them properly. This
will either require a new definition for the "layering property", or moving
layers from the variables to the facts or rules.

Both options look OK to me. D2 would offer some additional useful functionality
for people who generate their finite-domain input directly, but it would have
some implementation cost (not terribly high, I think, but still) and affect the
file format. Opinions?
msg3351 (view) Author: malte Date: 2014-08-27.12:12:52
The preprocessor and search components currently encounter problems with certain
degenerate inputs, such as problems with no goals. Also, such inputs may
complicate the implementation of certain parts of the planner. Given that these
input formats are under our control, we have decided to enforce some
restrictions on degenerate inputs.

In detail, we need to do three things:

1. Translator and preprocessor must ensure that their output follows these
restrictions, e.g. by introducing artificial state variables and goals if necessary.

2. Preprocessor and search must validate their input to verify that it follows
these restrictions, and complain about invalid input if it doesn't.

3. Our documentation for translation and preprocessor output format on the wiki
must describe these restrictions.

The restrictions we want to make are:

A. There must be at least one state variable.
B. There must be at least one goal.
C. Each state variable must have at least two values in its domain.

We have decided *not* to enforce that all variables are relevant and all facts
are relaxed reachable. (For example, this is violated for the artificial
unsolvable problems we generate if the translator detects unsolvability.) In the
past, there used to be code in the variable order finder (and possibly
elsewhere?) that incorrectly made the assumption that all variables are
relevant, or even that the causal graph is connected, and this might still be
the case. It is perhaps worth adding a separate issue for this?

Marking this as a bug because we currently fail on problems whose goal condition
is simplified to "true" in the translator.
History
Date User Action Args
2024-07-08 11:28:10gabisetsummary: Related to issue1069
2014-08-29 15:18:25gabisetnosy: + gabi
2014-08-28 11:24:37floriansetnosy: + florian
messages: + msg3365
2014-08-27 15:29:10jendriksetmessages: + msg3356
2014-08-27 15:09:39maltesetmessages: + msg3354
2014-08-27 15:08:47jendriksetnosy: + jendrik
2014-08-27 12:12:52maltecreate