Issue401

Title Master plan for state representation
Priority meta Status chatting
Superseder Nosy List florian, jendrik, malte
Assigned To Keywords
Optional summary
- ~~Temporary states should not cause a permanent overhead (issue386)
  Solved by using temporary state registries.~~
- ~~Think about making SearchNodes include a state rather than a State ID.
  We decided against doing this. Now that we unpack states, they are heavy
  weight objects again and should not be copied unnecessarily.~~
- ~~States should be stored more compactly (issue214).~~
- Think about when to unpack states (issue348).
- Get rid of global state registry (issue416).
- Use task interface in search engines and state registries (issue509).

- Separate the state-related code into a separate subdirectory and namespace
  with a clearly documented (and small) interface to the main code. This module
  should contain:
  - StateRegistry
  - IntPacker
  - PerStateInformation
  - StateId
  - GlobalState (maybe renamed to RegisteredState)
  - Try to avoid dependency on the semantic of operators.
  - Maybe even make this module completely independent of the task interface at
all. 
    (only assume that there are states that have a factored representation of
    multivalued variables with given domain sizes).

Created on 2013-12-16.10:45:10 by florian, last changed by florian.

Summary
- Temporary states should not cause a permanent overhead (issue386)
  Solved by using temporary state registries.
- Think about making SearchNodes include a state rather than a State ID.
  We decided against doing this. Now that we unpack states, they are heavy
  weight objects again and should not be copied unnecessarily.
- States should be stored more compactly (issue214).
- Think about when to unpack states (issue348).
- Get rid of global state registry (issue416).
- Use task interface in search engines and state registries (issue509).

- Separate the state-related code into a separate subdirectory and namespace
  with a clearly documented (and small) interface to the main code. This module
  should contain:
  - StateRegistry
  - IntPacker
  - PerStateInformation
  - StateId
  - GlobalState (maybe renamed to RegisteredState)
  - Try to avoid dependency on the semantic of operators.
  - Maybe even make this module completely independent of the task interface at
all. 
    (only assume that there are states that have a factored representation of
    multivalued variables with given domain sizes).
Messages
msg5100 (view) Author: florian Date: 2016-01-16.12:44:59
There is a lot of work left to do that is more related to supporting the task
interface than to the state representation. I think this fits better into
issue509. We should finish supporting the task interface in the search code,
before we continue here.
msg5096 (view) Author: florian Date: 2016-01-15.23:10:36
Added a summary of the previous points and the results of our meeting today.
msg3893 (view) Author: malte Date: 2014-11-09.20:19:56
Hi Florian, sorry for the confusion, "meta" issues are the ones with priority
"meta" rather than the "meta" keyword. Keyword "meta" is old and unused; we used
it for non-code things (the website, mainly).
msg3667 (view) Author: florian Date: 2014-10-06.10:23:05
issue423 and issue424 are also follow up work on issue214. We might also want to
do them as part of step 3).
msg3666 (view) Author: florian Date: 2014-10-06.10:16:34
Some of the steps are done. Here is the updated version

1) [DONE] Temporary states should not cause a permanent overhead (issue386)
   Solved by using temporary state registries.
2) [DONE] Think about making SearchNodes include a state rather than a State ID.
   We decided against doing this. Now that we unpack states, they are heavy
weight objects again
   and should not be copied unnecessarily.
3) States should be stored more compactly
   The main work here is merged already (issue214).
   We are still working on follow-up work in issue348.
4) Get rid of global state registry (issue416)
5) Separate the state-related code into a separate subdirectory and namespace
with a clearly documented (and small) interface to the main code.
msg3640 (view) Author: malte Date: 2014-10-04.19:57:11
Is this master plan still up to date?
msg2801 (view) Author: malte Date: 2013-12-16.10:46:15
4) Separate the state-related code into a separate subdirectory and namespace
with a clearly documented (and small) interface to the main code.
msg2800 (view) Author: florian Date: 2013-12-16.10:45:10
This is a meta-issue where we want to collect more long-term ideas for the way
states are represented in the planner.

1) Temporary states should not cause a permanent overhead (issue386)
2) Think about making SearchNodes include a state rather than a State ID.
3) States should be stored more compactly (issue214)
History
Date User Action Args
2016-01-16 12:45:00floriansetmessages: + msg5100
summary: - ~~Temporary states should not cause a permanent overhead (issue386) Solved by using temporary state registries.~~ - ~~Think about making SearchNodes include a state rather than a State ID. We decided against doing this. Now that we unpack states, they are heavy weight objects again and should not be copied unnecessarily.~~ - ~~States should be stored more compactly (issue214).~~ - Think about when to unpack states (issue348). - Get rid of global state registry (issue416). - Use task interface in pruning methods. - Use task interface in search engines. - Separate the state-related code into a separate subdirectory and namespace with a clearly documented (and small) interface to the main code. This module should contain: - StateRegistry - IntPacker - PerStateInformation - StateId - GlobalState (maybe renamed to RegisteredState) - Try to avoid dependency on the semantic of operators. - Maybe even make this module completely independent of the task interface at all. (only assume that there are states that have a factored representation of multivalued variables with given domain sizes). -> - ~~Temporary states should not cause a permanent overhead (issue386) Solved by using temporary state registries.~~ - ~~Think about making SearchNodes include a state rather than a State ID. We decided against doing this. Now that we unpack states, they are heavy weight objects again and should not be copied unnecessarily.~~ - ~~States should be stored more compactly (issue214).~~ - Think about when to unpack states (issue348). - Get rid of global state registry (issue416). - Use task interface in search engines and state registries (issue509). - Separate the state-related code into a separate subdirectory and namespace with a clearly documented (and small) interface to the main code. This module should contain: - StateRegistry - IntPacker - PerStateInformation - StateId - GlobalState (maybe renamed to RegisteredState) - Try to avoid dependency on the semantic of operators. - Maybe even make this module completely independent of the task interface at all. (only assume that there are states that have a factored representation of multivalued variables with given domain sizes).
2016-01-15 23:10:36floriansetmessages: + msg5096
summary: - ~~Temporary states should not cause a permanent overhead (issue386) Solved by using temporary state registries.~~ - ~~Think about making SearchNodes include a state rather than a State ID. We decided against doing this. Now that we unpack states, they are heavy weight objects again and should not be copied unnecessarily.~~ - ~~States should be stored more compactly (issue214).~~ - Think about when to unpack states (issue348). - Get rid of global state registry (issue416). - Use task interface in pruning methods. - Use task interface in search engines. - Separate the state-related code into a separate subdirectory and namespace with a clearly documented (and small) interface to the main code. This module should contain: - StateRegistry - IntPacker - PerStateInformation - StateId - GlobalState (maybe renamed to RegisteredState) - Try to avoid dependency on the semantic of operators. - Maybe even make this module completely independent of the task interface at all. (only assume that there are states that have a factored representation of multivalued variables with given domain sizes).
2014-12-15 12:18:46jendriksetnosy: + jendrik
2014-11-09 20:19:56maltesetpriority: wish -> meta
messages: + msg3893
keyword: - meta
2014-10-26 00:36:42floriansetkeyword: + meta
2014-10-06 10:23:05floriansetmessages: + msg3667
2014-10-06 10:16:34floriansetmessages: + msg3666
2014-10-04 19:57:11maltesetmessages: + msg3640
2013-12-16 10:46:15maltesetmessages: + msg2801
2013-12-16 10:45:10floriancreate