Issue397

Title Treat conditional effects differently
Priority feature Status in-progress
Superseder Nosy List florian, gabi, haz, jendrik, malte, silvan
Assigned To jendrik Keywords
Optional summary

Created on 2013-11-18.17:59:38 by gabi, last changed by gabi.

Messages
msg6865 (view) Author: gabi Date: 2018-03-15.16:33:09
I re-assigned this to Jendrik because he currently is much more familiar with
the code than I am.
msg6863 (view) Author: jendrik Date: 2018-03-15.15:52:52
If it's fine with you, Gabi, I'd open a pull request for this issue.
msg6763 (view) Author: jendrik Date: 2017-12-23.13:09:01
I updated the patch. It now calls "SASOperator._canonical_pre_post()" again, but 
preserves the required order of effects.
msg6754 (view) Author: jendrik Date: 2017-12-18.14:21:40
Since I'd like to use the changes from this issue for IPC 2018, I have merged the 
current default branch from the master repository into the issue397 branch from 
Gabi's IPC 2014 repository. You can find the result at 
https://bitbucket.org/jendrikseipp/downward/branch/issue397 . I had to remove the 
call to "SASOperator._canonical_pre_post()" since it reorders the effects (this 
was introduced in issue533). If we decide to merge issue397, we should probably 
delete the "SASOperator._canonical_pre_post()" method. However, we should also 
think about whether we want to remove duplicate effects as is done in 
"SASOperator._canonical_pre_post()". I'm not sure whether any other changes to 
the translator since January 2014 interfere with the changes in the issue397 
branch.
msg2895 (view) Author: malte Date: 2014-01-06.23:28:33
I wondered if this had been addressed by some translator changes from a while
ago. Perhaps it has.
msg2894 (view) Author: florian Date: 2014-01-06.23:26:45
I did a local experiment on suite_satisficing_with_ipc11 and
suite_optimal_with_ipc11 and did not find any task with this condition. Maybe we
live in a better world than we thought.
msg2887 (view) Author: malte Date: 2014-01-06.19:54:09
Can you find out in which domains these occur? Maybe we can then implement the
comment from the function:

            // In a better world, these would never be included in the
            // input in the first place.
msg2886 (view) Author: florian Date: 2014-01-06.19:50:12
The check in verify_no_cond_effects() also is no longer valid under the new
semantics (as we discussed offline). I removed it for now. Did we discuss an
alternative that allows to recognize unproblematic special cases?
msg2884 (view) Author: malte Date: 2014-01-06.18:37:17
Under the new semantics, you can only do this if no earlier effect can change
the value of that variable to something else.
msg2883 (view) Author: gabi Date: 2014-01-06.18:29:34
Just to make this clear: in the example in msg2881, removing the effect
condition {x=2} would not change the operator because effect 2 would trigger
whenever the operator is applied, independently of this effect condition.

However, I just had a look at the code and in translate.py lines 296-297 an
effect is dropped if it sets the variable to the same value as required by the
precondition. At the moment, I do not see why we can do this.
msg2882 (view) Author: jendrik Date: 2014-01-06.17:56:24
Sorry for the spam, Florian just told me that first all effects that trigger are 
collected and only in a second step their effects are applied.
msg2881 (view) Author: jendrik Date: 2014-01-06.16:59:15
In the issue397 branch in the IPC repo effect conditions that are also preconditions are removed. Is 
this still valid for the new semantics? Consider the following operator:

precondition: {x=2}
effect1: {} -> x=3
effect2: {x=2} -> {y=3}

If we remove the effect condition from effect2 both effects will trigger when the action is applied, 
otherwise only effect1 will trigger (assuming effect2 is evaluated after effect1).
msg2776 (view) Author: malte Date: 2013-12-10.14:57:44
OK, let's make it part of the input then.
msg2775 (view) Author: gabi Date: 2013-12-10.14:49:24
I do not think we can cheaply regain this information in the search component.
In the translator we know that two effects on a variable that stem from PDDL add
effects will never trigger together (otherwise the invariant synthesis would be
incorrect). However, for finding this out we would need to use all mutex
information again.
msg2773 (view) Author: malte Date: 2013-12-10.14:32:55
I think this is a good idea.

I would suggest to do implement this marking directly in the search component
rather than have it be present in the input. (In general, we want to be able to
verify that the input makes sense, and for this we'd be able to verify such
markings in the input anyway. And then we might as well recompute them.)
msg2770 (view) Author: gabi Date: 2013-12-10.13:35:26
I just started working on the sequential evaluation of effects. 

I think it would make sense to mark effects that can possibly be overwritten by
later effects as such. This would allow a protecting flag for heuristics that do
not support the new semantics. In addition, for heuristics that do support the
new semantics, knowing that an effect won't be overwritten can save overhead.

What do you think?
msg2694 (view) Author: jendrik Date: 2013-11-19.16:57:07
I removed issue146 from the "replaced by" list since otherwise the issue doesn't 
appear in the overall list of open issues.
msg2689 (view) Author: gabi Date: 2013-11-18.17:59:38
Currently the translator ensures that the effect conditions of all effects on
the same variable are mutually exclusive. However, this can significantly
increase the size of the operator, so a different way of treating conditional
effects could be helpful.

Gabi in issue146:
"My implementation "guards" negative conditional effects. Let for example V=v 
be a SAS+ variable/value pair for a propositional atom A and let formula phi 
denote the condition that any (original) add effect on V triggers. A 
conditional delete effect on atom A with condition psi is then translated to an 
effect "if psi and V=v and not phi then V=none-of-those". The potential problem 
lies in the "not phi" part because it gets expanded in the "multiply out 
conditions" code (cf. issue165)."

Malte in issue146:
"In the long term, it would be nice to have a closer look at various ways of
compiling these things, and maybe a simple way to do it would be to have a
convention similar to PDDL's "add effect wins over delete effects" to avoid
having to encode these "non-triggering" conditions. Or maybe we should simply go
with a semantics where effects are processed sequentially and make sure that the
ones that should "win" according to PDDL semantics are mentioned last."
History
Date User Action Args
2018-03-15 16:33:09gabisetassignedto: gabi -> jendrik
messages: + msg6865
2018-03-15 15:52:52jendriksetmessages: + msg6863
2017-12-23 13:09:01jendriksetmessages: + msg6763
2017-12-18 14:21:40jendriksetmessages: + msg6754
2014-01-06 23:28:33maltesetmessages: + msg2895
2014-01-06 23:26:45floriansetmessages: + msg2894
2014-01-06 19:54:09maltesetmessages: + msg2887
2014-01-06 19:50:12floriansetmessages: + msg2886
2014-01-06 18:37:17maltesetmessages: + msg2884
2014-01-06 18:29:34gabisetmessages: + msg2883
2014-01-06 17:56:24jendriksetmessages: + msg2882
2014-01-06 16:59:42jendriksetnosy: + silvan
2014-01-06 16:59:15jendriksetmessages: + msg2881
2013-12-10 14:57:44maltesetmessages: + msg2776
2013-12-10 14:49:24gabisetmessages: + msg2775
2013-12-10 14:32:55maltesetmessages: + msg2773
2013-12-10 13:35:26gabisetstatus: chatting -> in-progress
nosy: + florian
messages: + msg2770
assignedto: gabi
2013-11-20 05:52:08hazsetnosy: + haz
2013-11-19 16:57:07jendriksetstatus: unread -> chatting
nosy: + malte, jendrik
superseder: - operators that conditionally delete/add the same fact not implemented
messages: + msg2694
2013-11-18 17:59:38gabicreate