Title Do not store values of derived variables
Priority feature Status in-progress
Superseder Nosy List florian, gabi, jendrik, malte
Assigned To gabi Keywords
Optional summary

Created on 2015-06-29.15:10:23 by gabi, last changed by malte.

msg5090 (view) Author: malte Date: 2016-01-14.19:12:20
Yes, thanks! I closed that one. The discussion there also said that the
discussion of issue214 was relevant to this. I didn't go through it, but wanted
to copy this information over here now that issue423 is closed.
msg5088 (view) Author: florian Date: 2016-01-14.19:07:38
Is this a duplicate of issue423?
msg4298 (view) Author: malte Date: 2015-07-01.12:44:06
Perhaps just a small (five-minute, or even only one minute) experiment with
LM-Cut, and one of the main merge-and-shrink configurations to be sure? I also
often run blind search because there runs tend to be not too noisy.
msg4297 (view) Author: gabi Date: 2015-07-01.11:23:53
The first draft of the implementation is finished and experiments for
inadmissible heuristics (especially cea and cg) are in the queue. 

What optimal configurations should I test? None of our good heuristics supports
derived variables, so the main concern will be to verify that I did not break
anything for axiom-free tasks. Since my implementation does not change the
variable order, the only expected effect is a 4KB larger memory usage.
msg4286 (view) Author: gabi Date: 2015-06-29.15:10:23
To save memory, we do not want to store the values of derived variables anymore
but instead recompute them each time a state is unpacked. As a side effect, the
preprocessor will no longer fix a total variable order.
Date User Action Args
2016-01-14 19:12:20maltesetmessages: + msg5090
2016-01-14 19:07:38floriansetmessages: + msg5088
2015-07-03 12:02:10floriansetnosy: + florian
2015-07-01 12:44:06maltesetmessages: + msg4298
2015-07-01 11:23:53gabisetmessages: + msg4297
2015-06-29 15:24:18jendriksetnosy: + jendrik
2015-06-29 15:16:04maltesetnosy: + malte
2015-06-29 15:10:23gabicreate