Issue987

Title Clean up landmark implementation
Priority meta Status chatting
Superseder Nosy List clemens, jendrik, malte, salome, silvan, thomas
Assigned To Keywords
Optional summary
goals (see further details in msg9768):
1. The LandmarkGraph should be constant after creation, particularly it should not track the achieved status of landmarks in the currently evaluated state (issue988).
2. The LandmarkFactory should be cleaned up: it provides many methods as well as access to the exploration object which does not belong there (issue990).
3. We want a common LandmarkNode class from which the different types of landmarks (atomic, conjunctive, disjunctive, disjunctive action) inherit (issue999).
---------
4. Check if special treatment for cycles and landmarks that can be achieved simultaneously is necessary.
5. Look at used data structures and determine if there are better options.
6. Avoid storing information at weird places.
7. Check for obsolete code parts.
(Goals 4-7 are more abstract and might require more discussion)


related issues:
cleanup and redesign:
 - issue160: automatically detect whether preferred operators should be computed
 - issue334: separate landmark generation and heuristic
 - issue384: use variables instead of predicate names for disjunctive landmarks
 - issue686: handle task transformations in path-dependent heuristics (currently there is a guard against accidental misuse, see issue845)
 - issue988: make the landmark graph constant after creation (goal 1)
 - issue989: make LandmarkGraph more readable and adapt code style
 - issue990: separate between relaxation-based and other landmark factories; move exploration to relaxation-based ones
 - issue992: make the landmark code consistent with coding conventions
 - issue993: make landmark graph objects be one-shot constructed by landmark (graph) factories
 - issue995: refactor LandmarkFactory options
 - issue996: create landmark factory that makes landmark graph acyclic
 - issue999: implement LandmarkNode as abstract class from which specific implementations for atomic, conjunctive, disjunctive ... landmarks inherit
 - issue1000: fix performance loss introduced in issue988
new features:
 - issue124: distinguish between first and all achievers when computing the lmcount heuristic
 - issue202: explore use of reasonable orders in admissible heuristics
 - issue257: allow overlapping landmarks in the same landmark graph
 - issue994: allow cyclic landmark graphs
 - issue1011: determine unsolvability based on landmark graph
bugs:
 - issue247: lm heuristic crashes / wrongly reports dead ends
 - issue383: reasonable orders not always generated
 - issue442: lm_rhw detects wrong orderings
 - issue467: assertion failure with unsolvable tasks
 - issue984: segfault in h^m landmark factory
 - issue937: breaking cycles chokes on unsolvable tasks (related to issue467)
 - issue998: lm_zg does not handle unsolvable tasks properly (related to issue467 and issue998)
 - issue1004: lm_rhw produces wrong greedy-neccessary orders
 - issue1009: compute correct landmark costs in all factories

important configurations for experiments testing changes in landmark factories:
satisficing:
- lama-first (alias)
- like lama-first however with pref=True in lm_rhw
- lmcount(lm_zg(reasonable_orders=false))

optimal:
- --evaluator 'lmc=lmcount(lm_exhaust(),admissible=true)' --search 'astar(lmc,lazy_evaluator=lmc)'
- --evaluator 'lmc=lmcount(lm_hm(m=2),admissible=true)' --search 'astar(lmc,lazy_evaluator=lmc)'
- --alias seq-opt-bjolp
- like seq-opt-bjolp but with optimal=True in lmcount (this requires an installed LP solver)

Created on 2021-01-19.17:04:01 by clemens, last changed by thomas.

Summary
goals (see further details in msg9768):
1. The LandmarkGraph should be constant after creation, particularly it should not track the achieved status of landmarks in the currently evaluated state (issue988).
2. The LandmarkFactory should be cleaned up: it provides many methods as well as access to the exploration object which does not belong there (issue990).
3. We want a common LandmarkNode class from which the different types of landmarks (atomic, conjunctive, disjunctive, disjunctive action) inherit (issue999).
---------
4. Check if special treatment for cycles and landmarks that can be achieved simultaneously is necessary.
5. Look at used data structures and determine if there are better options.
6. Avoid storing information at weird places.
7. Check for obsolete code parts.
(Goals 4-7 are more abstract and might require more discussion)


related issues:
cleanup and redesign:
 - issue160: automatically detect whether preferred operators should be computed
 - issue334: separate landmark generation and heuristic
 - issue384: use variables instead of predicate names for disjunctive landmarks
 - issue686: handle task transformations in path-dependent heuristics (currently there is a guard against accidental misuse, see issue845)
 - issue988: make the landmark graph constant after creation (goal 1)
 - issue989: make LandmarkGraph more readable and adapt code style
 - issue990: separate between relaxation-based and other landmark factories; move exploration to relaxation-based ones
 - issue992: make the landmark code consistent with coding conventions
 - issue993: make landmark graph objects be one-shot constructed by landmark (graph) factories
 - issue995: refactor LandmarkFactory options
 - issue996: create landmark factory that makes landmark graph acyclic
 - issue999: implement LandmarkNode as abstract class from which specific implementations for atomic, conjunctive, disjunctive ... landmarks inherit
 - issue1000: fix performance loss introduced in issue988
new features:
 - issue124: distinguish between first and all achievers when computing the lmcount heuristic
 - issue202: explore use of reasonable orders in admissible heuristics
 - issue257: allow overlapping landmarks in the same landmark graph
 - issue994: allow cyclic landmark graphs
 - issue1011: determine unsolvability based on landmark graph
bugs:
 - issue247: lm heuristic crashes / wrongly reports dead ends
 - issue383: reasonable orders not always generated
 - issue442: lm_rhw detects wrong orderings
 - issue467: assertion failure with unsolvable tasks
 - issue984: segfault in h^m landmark factory
 - issue937: breaking cycles chokes on unsolvable tasks (related to issue467)
 - issue998: lm_zg does not handle unsolvable tasks properly (related to issue467 and issue998)
 - issue1004: lm_rhw produces wrong greedy-neccessary orders
 - issue1009: compute correct landmark costs in all factories

important configurations for experiments testing changes in landmark factories:
satisficing:
- lama-first (alias)
- like lama-first however with pref=True in lm_rhw
- lmcount(lm_zg(reasonable_orders=false))

optimal:
- --evaluator 'lmc=lmcount(lm_exhaust(),admissible=true)' --search 'astar(lmc,lazy_evaluator=lmc)'
- --evaluator 'lmc=lmcount(lm_hm(m=2),admissible=true)' --search 'astar(lmc,lazy_evaluator=lmc)'
- --alias seq-opt-bjolp
- like seq-opt-bjolp but with optimal=True in lmcount (this requires an installed LP solver)
Messages
msg10090 (view) Author: thomas Date: 2021-02-18.12:52:08
add issue1011
msg10066 (view) Author: thomas Date: 2021-02-15.11:57:43
I had the same problem as Salome desribes in msg10036 and removed the duplicate optimal configuration from the summary
msg10043 (view) Author: clemens Date: 2021-02-11.18:01:42
I must have overlooked that one. Yes, this is exactly the same as BJOLP but with lm_hm(m=2) instead of lm_merged(...).
msg10041 (view) Author: salome Date: 2021-02-11.17:55:01
Sorry, with above I meant --evaluator 'lmc=lmcount(lm_hm(m=2),admissible=true)' --search 'astar(lmc,lazy_evaluator=lmc)'.
msg10040 (view) Author: clemens Date: 2021-02-11.17:41:39
I don't think so, Salomé. seq-opt-bjolp is an alias for lm_merged([lm_rhw(), lm_hm(m=1)]), which is definitely not the same as lm_hm(m=2). Or did you not refer to seq-opt-bjolp with "the same as above it"?
msg10036 (view) Author: salome Date: 2021-02-11.17:23:36
Just tried to run some experiments with the recommended configurations for issue995, but my experiment complained that "like seq-opt-bjolp but with lm_hm(m=2) instead of lm_merged(...)" is the same as the configuration above it. Did I miss something or could we remove this?
msg9979 (view) Author: silvan Date: 2021-02-02.18:22:14
Fix typo.
msg9969 (view) Author: silvan Date: 2021-02-01.11:05:28
Update configs.
msg9926 (view) Author: silvan Date: 2021-01-29.08:49:13
Link issue989.
msg9900 (view) Author: silvan Date: 2021-01-28.18:45:19
Link issue1000.
msg9896 (view) Author: silvan Date: 2021-01-28.18:24:42
Update configurations to test in experiments affecting the landmark factories.
msg9878 (view) Author: salome Date: 2021-01-28.12:22:06
When looking into the experiments for issue990 we detected a bug in the lm_zg factory, where unsolvable tasks are not handled properly. I created a new issue (issue998) and added it to the bug section of the summary here.
msg9868 (view) Author: thomas Date: 2021-01-27.20:50:22
Summary: add issue996
msg9837 (view) Author: silvan Date: 2021-01-27.09:33:10
Ok. Then I suggest to broaden the title of issue990 again because with the current title, I would consider the issue done.
msg9835 (view) Author: thomas Date: 2021-01-27.08:45:54
Silvan, I wasn't aware of the first item on your list, and I don't think it fits issue990. I guess it makes sense to have that one be part of the issue that introduces classes for the different kinds of landmarks (goal 3 in the summary). The other 3 are part of issue990.
msg9833 (view) Author: silvan Date: 2021-01-27.08:31:59
Summary: update name of issue993.
msg9830 (view) Author: silvan Date: 2021-01-27.08:29:46
Thomas, we also discussed various issues related to "post-processing" of the landmark graph and came to the conclusion that we would like figure out the following:
- which landmark factory generates which types of landmarks
- based on the findings, make options such as "only causal landmarks" only available to factories where it makes sense
- the same applies for approximate_reasonable_orders and reasonable orders, and maybe also making the graph acyclic
- let all individual factories be responsible for post-processing (removing orders, making acyclic etc.)

I thought that we decided to figure these things out in issue990, but I saw that you wanted to treat this one is done. This is fine, but the successor issue993 also doesn't sound like it wanted to tackle these items. Where do you want to tackle the above items? (I saw that there is issue994 for looking into the acyclic graph issue.)
msg9829 (view) Author: silvan Date: 2021-01-27.08:19:27
Add to summary:
- issue990: separate between relaxation-based and other landmark factories; move exploration to relaxation-based ones
msg9817 (view) Author: thomas Date: 2021-01-26.21:16:12
We discussed several issues with the landmark code today, and we didn't know what to do with the following two:

- the class LandmarkFactory contains a variable no_orders (which is protected once issue990 is merged) that is set by a command line option "no_orders" and a protected function use_orders that returns the negation of no_orders. It should be sufficient to directly access the variable in the subclasses of LandmarkFactory, and I find it confusing that the command line option is a negated concept. I'd propose to change this s.t. there is only a variable "use_orders" and s.t. the command line option is "positive" (i.e., it's called use_orders as well).
- The class LandmarkFactoryMerged exits if it encounters a conjunctive fact landmark. I don't see a conceptual issue with this, but even if there was one, it doesn't make sense to live with the conceptual issue if it is implemented in a landmark factory, but reject it if the same landmark factory is embedded into a LandmarkFactoryMerged.

We should determine if these two can be ignored, if we should add them to the summary or even create issues for them.
msg9770 (view) Author: clemens Date: 2021-01-20.12:30:24
Add new issue988 for refactoring the LandmarkGraph class as described in msg9768 point (1.).
msg9768 (view) Author: thomas Date: 2021-01-20.10:24:06
We had a meeting yesterday with the aim of creating subtasks for this issue. We decided to start with the following three tasks (these might be further divided into smaller bits, looking closer at the code will tell):

1. The LandmarkGraph should be constant after creation. Currently, landmark nodes have a status that is used to track which landmarks have been achieved, and we'd like to move that functionality somewhere else.
2. The LandmarkFactory should be cleaned up, Currently, the class provides many methods as well as access to the exploration object that do not belong here. Instead, the functionality should be moved to the classes that inherit from LandmarkFactory.
3. The LandmarkNode class is currently a joint implementation of different kind of landmarks: AtomicLMs, ConjunctiveAtomicLMs, DisjunctiveAtomicLMs and DisjunctiveActionLMs. We'd like to replace this with different classes that inherit from a common LandmarkNode class. This task depends on task 1.

We also discussed some further (currently still quite abstract) issues with the code that might be approached in this sprint or might not (I continue with the numbers to make it easier to discuss these):

4. Some LandMarkFactories treat cycles and landmarks that can be achieved at the same time specially. We'd like to check if this special treatment is even necessary.
5. Look at used data structures and determine if there are better options
6. Avoid storing information at weired places
7. Check for obsolete code parts (e.g., the requirement that the task that is passed to a LandmarkFactory must always be the same); it's possible that there are code parts that are dead for all possible / reasonable (?) planner configurations.

To test changes, these two planner configurations use much of the code:
1. Lamafirst (satisficing)
2. Seqoptbjolp (optimal)

- Once we are at the point to run a proper experiment, we should additionally consider these configurations:
3. Lama (non-admissible version)
4. one configuration for every landmark factory not covered by the previous ones
msg9767 (view) Author: clemens Date: 2021-01-19.17:59:36
And I found even more open issues concerned with landmarks:

issue247 reports wrongly reported dead ends which might have to do with conditional effects.

And issue442 reports that lm_rhw introduces wrong greedy-necessary orderings.
msg9766 (view) Author: clemens Date: 2021-01-19.17:46:16
issue160 addresses that LM-count should automatically detect whether to compute preferred operators or not.
msg9765 (view) Author: clemens Date: 2021-01-19.17:04:01
The landmark code is an old and messy part of Fast Downward. During our January 2021 Fast Downward sprint, we intend to clean it up. Below, I summarize problems and related issues in this context.

General:
========
Responsibilities are not intuitive. For example, one core element is the class LandmarkGraph. It not only stores landmarks and orderings (=dependencies) between them, but also information used by the LM-count heuristic. This is also reflected in issue334. There should be a clear distinction between information belonging to the landmarks and information about them required by some other component.

Landmark factories produce such LM-graphs. There are several methods to generate landmarks, which all implement the abstract class LandmarkFactory. However, LandmarkFactory implements several functions which should actually be part of its child-classes. This should be changed accordingly to make the distinction between these landmark generators much cleaner.

Logic:
======
issue202 discusses problems with theory and implementation of approximating reasonable orderings and how they are used to maintain which landmarks are reached/accepted in the LM-count heuristic.

issue257 reports that landmarks are only added to LM-graphs if they do not intersect. It is not clear to me why it is implemented like this. In my honest opinion, this is very random. We should dig deeper to clarify the intention behind this.

issue383 reports odd behaviour when changing another thing which seems very random. The issue was set aside until after the long planned refactoring with the comment "Let's hope its not another 3.5 years." Guess what: this was 4 years ago ;-)

Other:
======
issue124 is concerned with how LAMA deals with landmark costs.

issue384 was an attempt to change the way disjunctive landmarks are derived, but  seems abandoned.

issue686 and issue845 are concerned with using different task representations at the same code level. More details can be found at http://www.fast-downward.org/ForDevelopers/LongTermPlans#Task_Transformations.

Bugs:
=====
After the refactoring, we should also address known bugs of the current code. For example, issue467 and issue937 report failing assertions, and issue984 reports a segfault.
History
Date User Action Args
2021-02-18 12:52:08thomassetmessages: + msg10090
summary: goals (see further details in msg9768): 1. The LandmarkGraph should be constant after creation, particularly it should not track the achieved status of landmarks in the currently evaluated state (issue988). 2. The LandmarkFactory should be cleaned up: it provides many methods as well as access to the exploration object which does not belong there (issue990). 3. We want a common LandmarkNode class from which the different types of landmarks (atomic, conjunctive, disjunctive, disjunctive action) inherit (issue999). --------- 4. Check if special treatment for cycles and landmarks that can be achieved simultaneously is necessary. 5. Look at used data structures and determine if there are better options. 6. Avoid storing information at weird places. 7. Check for obsolete code parts. (Goals 4-7 are more abstract and might require more discussion) related issues: cleanup and redesign: - issue160: automatically detect whether preferred operators should be computed - issue334: separate landmark generation and heuristic - issue384: use variables instead of predicate names for disjunctive landmarks - issue686: handle task transformations in path-dependent heuristics (currently there is a guard against accidental misuse, see issue845) - issue988: make the landmark graph constant after creation (goal 1) - issue989: make LandmarkGraph more readable and adapt code style - issue990: separate between relaxation-based and other landmark factories; move exploration to relaxation-based ones - issue992: make the landmark code consistent with coding conventions - issue993: make landmark graph objects be one-shot constructed by landmark (graph) factories - issue995: refactor LandmarkFactory options - issue996: create landmark factory that makes landmark graph acyclic - issue999: implement LandmarkNode as abstract class from which specific implementations for atomic, conjunctive, disjunctive ... landmarks inherit - issue1000: fix performance loss introduced in issue988 new features: - issue124: distinguish between first and all achievers when computing the lmcount heuristic - issue202: explore use of reasonable orders in admissible heuristics - issue257: allow overlapping landmarks in the same landmark graph - issue994: allow cyclic landmark graphs bugs: - issue247: lm heuristic crashes / wrongly reports dead ends - issue383: reasonable orders not always generated - issue442: lm_rhw detects wrong orderings - issue467: assertion failure with unsolvable tasks - issue984: segfault in h^m landmark factory - issue937: breaking cycles chokes on unsolvable tasks (related to issue467) - issue998: lm_zg does not handle unsolvable tasks properly (related to issue467 and issue998) - issue1004: lm_rhw produces wrong greedy-neccessary orders - issue1009: compute correct landmark costs in all factories important configurations for experiments testing changes in landmark factories: satisficing: - lama-first (alias) - like lama-first however with pref=True in lm_rhw - lmcount(lm_zg(reasonable_orders=false)) optimal: - --evaluator 'lmc=lmcount(lm_exhaust(),admissible=true)' --search 'astar(lmc,lazy_evaluator=lmc)' - --evaluator 'lmc=lmcount(lm_hm(m=2),admissible=true)' --search 'astar(lmc,lazy_evaluator=lmc)' - --alias seq-opt-bjolp - like seq-opt-bjolp but with optimal=True in lmcount (this requires an installed LP solver) -> goals (see further details in msg9768): 1. The LandmarkGraph should be constant after creation, particularly it should not track the achieved status of landmarks in the currently evaluated state (issue988). 2. The LandmarkFactory should be cleaned up: it provides many methods as well as access to the exploration object which does not belong there (issue990). 3. We want a common LandmarkNode class from which the different types of landmarks (atomic, conjunctive, disjunctive, disjunctive action) inherit (issue999). --------- 4. Check if special treatment for cycles and landmarks that can be achieved simultaneously is necessary. 5. Look at used data structures and determine if there are better options. 6. Avoid storing information at weird places. 7. Check for obsolete code parts. (Goals 4-7 are more abstract and might require more discussion) related issues: cleanup and redesign: - issue160: automatically detect whether preferred operators should be computed - issue334: separate landmark generation and heuristic - issue384: use variables instead of predicate names for disjunctive landmarks - issue686: handle task transformations in path-dependent heuristics (currently there is a guard against accidental misuse, see issue845) - issue988: make the landmark graph constant after creation (goal 1) - issue989: make LandmarkGraph more readable and adapt code style - issue990: separate between relaxation-based and other landmark factories; move exploration to relaxation-based ones - issue992: make the landmark code consistent with coding conventions - issue993: make landmark graph objects be one-shot constructed by landmark (graph) factories - issue995: refactor LandmarkFactory options - issue996: create landmark factory that makes landmark graph acyclic - issue999: implement LandmarkNode as abstract class from which specific implementations for atomic, conjunctive, disjunctive ... landmarks inherit - issue1000: fix performance loss introduced in issue988 new features: - issue124: distinguish between first and all achievers when computing the lmcount heuristic - issue202: explore use of reasonable orders in admissible heuristics - issue257: allow overlapping landmarks in the same landmark graph - issue994: allow cyclic landmark graphs - issue1011: determine unsolvability based on landmark graph bugs: - issue247: lm heuristic crashes / wrongly reports dead ends - issue383: reasonable orders not always generated - issue442: lm_rhw detects wrong orderings - issue467: assertion failure with unsolvable tasks - issue984: segfault in h^m landmark factory - issue937: breaking cycles chokes on unsolvable tasks (related to issue467) - issue998: lm_zg does not handle unsolvable tasks properly (related to issue467 and issue998) - issue1004: lm_rhw produces wrong greedy-neccessary orders - issue1009: compute correct landmark costs in all factories important configurations for experiments testing changes in landmark factories: satisficing: - lama-first (alias) - like lama-first however with pref=True in lm_rhw - lmcount(lm_zg(reasonable_orders=false)) optimal: - --evaluator 'lmc=lmcount(lm_exhaust(),admissible=true)' --search 'astar(lmc,lazy_evaluator=lmc)' - --evaluator 'lmc=lmcount(lm_hm(m=2),admissible=true)' --search 'astar(lmc,lazy_evaluator=lmc)' - --alias seq-opt-bjolp - like seq-opt-bjolp but with optimal=True in lmcount (this requires an installed LP solver)
2021-02-15 11:57:43thomassetmessages: + msg10066
summary: goals (see further details in msg9768): 1. The LandmarkGraph should be constant after creation, particularly it should not track the achieved status of landmarks in the currently evaluated state (issue988). 2. The LandmarkFactory should be cleaned up: it provides many methods as well as access to the exploration object which does not belong there (issue990). 3. We want a common LandmarkNode class from which the different types of landmarks (atomic, conjunctive, disjunctive, disjunctive action) inherit (issue999). --------- 4. Check if special treatment for cycles and landmarks that can be achieved simultaneously is necessary. 5. Look at used data structures and determine if there are better options. 6. Avoid storing information at weird places. 7. Check for obsolete code parts. (Goals 4-7 are more abstract and might require more discussion) related issues: cleanup and redesign: - issue160: automatically detect whether preferred operators should be computed - issue334: separate landmark generation and heuristic - issue384: use variables instead of predicate names for disjunctive landmarks - issue686: handle task transformations in path-dependent heuristics (currently there is a guard against accidental misuse, see issue845) - issue988: make the landmark graph constant after creation (goal 1) - issue989: make LandmarkGraph more readable and adapt code style - issue990: separate between relaxation-based and other landmark factories; move exploration to relaxation-based ones - issue992: make the landmark code consistent with coding conventions - issue993: make landmark graph objects be one-shot constructed by landmark (graph) factories - issue995: refactor LandmarkFactory options - issue996: create landmark factory that makes landmark graph acyclic - issue999: implement LandmarkNode as abstract class from which specific implementations for atomic, conjunctive, disjunctive ... landmarks inherit - issue1000: fix performance loss introduced in issue988 new features: - issue124: distinguish between first and all achievers when computing the lmcount heuristic - issue202: explore use of reasonable orders in admissible heuristics - issue257: allow overlapping landmarks in the same landmark graph - issue994: allow cyclic landmark graphs bugs: - issue247: lm heuristic crashes / wrongly reports dead ends - issue383: reasonable orders not always generated - issue442: lm_rhw detects wrong orderings - issue467: assertion failure with unsolvable tasks - issue984: segfault in h^m landmark factory - issue937: breaking cycles chokes on unsolvable tasks (related to issue467) - issue998: lm_zg does not handle unsolvable tasks properly (related to issue467 and issue998) - issue1004: lm_rhw produces wrong greedy-neccessary orders - issue1009: compute correct landmark costs in all factories important configurations for experiments testing changes in landmark factories: satisficing: - lama-first (alias) - like lama-first however with pref=True in lm_rhw - lmcount(lm_zg(reasonable_orders=false)) optimal: - --evaluator 'lmc=lmcount(lm_exhaust(),admissible=true)' --search 'astar(lmc,lazy_evaluator=lmc)' - --evaluator 'lmc=lmcount(lm_hm(m=2),admissible=true)' --search 'astar(lmc,lazy_evaluator=lmc)' - --alias seq-opt-bjolp - like seq-opt-bjolp but with lm_hm(m=2) instead of lm_merged(...) - like seq-opt-bjolp but with optimal=True in lmcount (this requires an installed LP solver) -> goals (see further details in msg9768): 1. The LandmarkGraph should be constant after creation, particularly it should not track the achieved status of landmarks in the currently evaluated state (issue988). 2. The LandmarkFactory should be cleaned up: it provides many methods as well as access to the exploration object which does not belong there (issue990). 3. We want a common LandmarkNode class from which the different types of landmarks (atomic, conjunctive, disjunctive, disjunctive action) inherit (issue999). --------- 4. Check if special treatment for cycles and landmarks that can be achieved simultaneously is necessary. 5. Look at used data structures and determine if there are better options. 6. Avoid storing information at weird places. 7. Check for obsolete code parts. (Goals 4-7 are more abstract and might require more discussion) related issues: cleanup and redesign: - issue160: automatically detect whether preferred operators should be computed - issue334: separate landmark generation and heuristic - issue384: use variables instead of predicate names for disjunctive landmarks - issue686: handle task transformations in path-dependent heuristics (currently there is a guard against accidental misuse, see issue845) - issue988: make the landmark graph constant after creation (goal 1) - issue989: make LandmarkGraph more readable and adapt code style - issue990: separate between relaxation-based and other landmark factories; move exploration to relaxation-based ones - issue992: make the landmark code consistent with coding conventions - issue993: make landmark graph objects be one-shot constructed by landmark (graph) factories - issue995: refactor LandmarkFactory options - issue996: create landmark factory that makes landmark graph acyclic - issue999: implement LandmarkNode as abstract class from which specific implementations for atomic, conjunctive, disjunctive ... landmarks inherit - issue1000: fix performance loss introduced in issue988 new features: - issue124: distinguish between first and all achievers when computing the lmcount heuristic - issue202: explore use of reasonable orders in admissible heuristics - issue257: allow overlapping landmarks in the same landmark graph - issue994: allow cyclic landmark graphs bugs: - issue247: lm heuristic crashes / wrongly reports dead ends - issue383: reasonable orders not always generated - issue442: lm_rhw detects wrong orderings - issue467: assertion failure with unsolvable tasks - issue984: segfault in h^m landmark factory - issue937: breaking cycles chokes on unsolvable tasks (related to issue467) - issue998: lm_zg does not handle unsolvable tasks properly (related to issue467 and issue998) - issue1004: lm_rhw produces wrong greedy-neccessary orders - issue1009: compute correct landmark costs in all factories important configurations for experiments testing changes in landmark factories: satisficing: - lama-first (alias) - like lama-first however with pref=True in lm_rhw - lmcount(lm_zg(reasonable_orders=false)) optimal: - --evaluator 'lmc=lmcount(lm_exhaust(),admissible=true)' --search 'astar(lmc,lazy_evaluator=lmc)' - --evaluator 'lmc=lmcount(lm_hm(m=2),admissible=true)' --search 'astar(lmc,lazy_evaluator=lmc)' - --alias seq-opt-bjolp - like seq-opt-bjolp but with optimal=True in lmcount (this requires an installed LP solver)
2021-02-11 18:01:42clemenssetmessages: + msg10043
2021-02-11 17:55:01salomesetmessages: + msg10041
2021-02-11 17:41:39clemenssetmessages: + msg10040
2021-02-11 17:23:36salomesetmessages: + msg10036
2021-02-11 13:27:54salomesetsummary: goals (see further details in msg9768): 1. The LandmarkGraph should be constant after creation, particularly it should not track the achieved status of landmarks in the currently evaluated state (issue988). 2. The LandmarkFactory should be cleaned up: it provides many methods as well as access to the exploration object which does not belong there (issue990). 3. We want a common LandmarkNode class from which the different types of landmarks (atomic, conjunctive, disjunctive, disjunctive action) inherit (issue999). --------- 4. Check if special treatment for cycles and landmarks that can be achieved simultaneously is necessary. 5. Look at used data structures and determine if there are better options. 6. Avoid storing information at weird places. 7. Check for obsolete code parts. (Goals 4-7 are more abstract and might require more discussion) related issues: cleanup and redesign: - issue160: automatically detect whether preferred operators should be computed - issue334: separate landmark generation and heuristic - issue384: use variables instead of predicate names for disjunctive landmarks - issue686: handle task transformations in path-dependent heuristics (currently there is a guard against accidental misuse, see issue845) - issue988: make the landmark graph constant after creation (goal 1) - issue989: make LandmarkGraph more readable and adapt code style - issue990: separate between relaxation-based and other landmark factories; move exploration to relaxation-based ones - issue992: make the landmark code consistent with coding conventions - issue993: make landmark graph objects be one-shot constructed by landmark (graph) factories - issue995: refactor LandmarkFactory options - issue996: create landmark factory that makes landmark graph acyclic - issue999: implement LandmarkNode as abstract class from which specific implementations for atomic, conjunctive, disjunctive ... landmarks inherit - issue1000: fix performance loss introduced in issue988 new features: - issue124: distinguish between first and all achievers when computing the lmcount heuristic - issue202: explore use of reasonable orders in admissible heuristics - issue257: allow overlapping landmarks in the same landmark graph - issue994: allow cyclic landmark graphs bugs: - issue247: lm heuristic crashes / wrongly reports dead ends - issue383: reasonable orders not always generated - issue442: lm_rhw detects wrong orderings - issue467: assertion failure with unsolvable tasks - issue984: segfault in h^m landmark factory - issue937: breaking cycles chokes on unsolvable tasks (related to issue467) - issue998: lm_zg does not handle unsolvable tasks properly (related to issue467 and issue998) - issue1004: lm_rhw produces wrong greedy-neccessary orders important configurations for experiments testing changes in landmark factories: satisficing: - lama-first (alias) - like lama-first however with pref=True in lm_rhw - lmcount(lm_zg(reasonable_orders=false)) optimal: - --evaluator 'lmc=lmcount(lm_exhaust(),admissible=true)' --search 'astar(lmc,lazy_evaluator=lmc)' - --evaluator 'lmc=lmcount(lm_hm(m=2),admissible=true)' --search 'astar(lmc,lazy_evaluator=lmc)' - --alias seq-opt-bjolp - like seq-opt-bjolp but with lm_hm(m=2) instead of lm_merged(...) - like seq-opt-bjolp but with optimal=True in lmcount (this requires an installed LP solver) -> goals (see further details in msg9768): 1. The LandmarkGraph should be constant after creation, particularly it should not track the achieved status of landmarks in the currently evaluated state (issue988). 2. The LandmarkFactory should be cleaned up: it provides many methods as well as access to the exploration object which does not belong there (issue990). 3. We want a common LandmarkNode class from which the different types of landmarks (atomic, conjunctive, disjunctive, disjunctive action) inherit (issue999). --------- 4. Check if special treatment for cycles and landmarks that can be achieved simultaneously is necessary. 5. Look at used data structures and determine if there are better options. 6. Avoid storing information at weird places. 7. Check for obsolete code parts. (Goals 4-7 are more abstract and might require more discussion) related issues: cleanup and redesign: - issue160: automatically detect whether preferred operators should be computed - issue334: separate landmark generation and heuristic - issue384: use variables instead of predicate names for disjunctive landmarks - issue686: handle task transformations in path-dependent heuristics (currently there is a guard against accidental misuse, see issue845) - issue988: make the landmark graph constant after creation (goal 1) - issue989: make LandmarkGraph more readable and adapt code style - issue990: separate between relaxation-based and other landmark factories; move exploration to relaxation-based ones - issue992: make the landmark code consistent with coding conventions - issue993: make landmark graph objects be one-shot constructed by landmark (graph) factories - issue995: refactor LandmarkFactory options - issue996: create landmark factory that makes landmark graph acyclic - issue999: implement LandmarkNode as abstract class from which specific implementations for atomic, conjunctive, disjunctive ... landmarks inherit - issue1000: fix performance loss introduced in issue988 new features: - issue124: distinguish between first and all achievers when computing the lmcount heuristic - issue202: explore use of reasonable orders in admissible heuristics - issue257: allow overlapping landmarks in the same landmark graph - issue994: allow cyclic landmark graphs bugs: - issue247: lm heuristic crashes / wrongly reports dead ends - issue383: reasonable orders not always generated - issue442: lm_rhw detects wrong orderings - issue467: assertion failure with unsolvable tasks - issue984: segfault in h^m landmark factory - issue937: breaking cycles chokes on unsolvable tasks (related to issue467) - issue998: lm_zg does not handle unsolvable tasks properly (related to issue467 and issue998) - issue1004: lm_rhw produces wrong greedy-neccessary orders - issue1009: compute correct landmark costs in all factories important configurations for experiments testing changes in landmark factories: satisficing: - lama-first (alias) - like lama-first however with pref=True in lm_rhw - lmcount(lm_zg(reasonable_orders=false)) optimal: - --evaluator 'lmc=lmcount(lm_exhaust(),admissible=true)' --search 'astar(lmc,lazy_evaluator=lmc)' - --evaluator 'lmc=lmcount(lm_hm(m=2),admissible=true)' --search 'astar(lmc,lazy_evaluator=lmc)' - --alias seq-opt-bjolp - like seq-opt-bjolp but with lm_hm(m=2) instead of lm_merged(...) - like seq-opt-bjolp but with optimal=True in lmcount (this requires an installed LP solver)
2021-02-02 18:22:15silvansetmessages: + msg9979
summary: goals (see further details in msg9768): 1. The LandmarkGraph should be constant after creation, particularly it should not track the achieved status of landmarks in the currently evaluated state (issue988). 2. The LandmarkFactory should be cleaned up: it provides many methods as well as access to the exploration object which does not belong there (issue990). 3. We want a common LandmarkNode class from which the different types of landmarks (atomic, conjunctive, disjunctive, disjunctive action) inherit (issue999). --------- 4. Check if special treatment for cycles and landmarks that can be achieved simultaneously is necessary. 5. Look at used data structures and determine if there are better options. 6. Avoid storing information at weird places. 7. Check for obsolete code parts. (Goals 4-7 are more abstract and might require more discussion) related issues: cleanup and redesign: - issue160: automatically detect whether preferred operators should be computed - issue334: separate landmark generation and heuristic - issue384: use variables instead of predicate names for disjunctive landmarks - issue686: handle task transformations in path-dependent heuristics (currently there is a guard against accidental misuse, see issue845) - issue988: make the landmark graph constant after creation (goal 1) - issue998: make LandmarkGraph more readable and adapt code style - issue990: separate between relaxation-based and other landmark factories; move exploration to relaxation-based ones - issue992: make the landmark code consistent with coding conventions - issue993: make landmark graph objects be one-shot constructed by landmark (graph) factories - issue995: refactor LandmarkFactory options - issue996: create landmark factory that makes landmark graph acyclic - issue999: implement LandmarkNode as abstract class from which specific implementations for atomic, conjunctive, disjunctive ... landmarks inherit - issue1000: fix performance loss introduced in issue988 new features: - issue124: distinguish between first and all achievers when computing the lmcount heuristic - issue202: explore use of reasonable orders in admissible heuristics - issue257: allow overlapping landmarks in the same landmark graph - issue994: allow cyclic landmark graphs bugs: - issue247: lm heuristic crashes / wrongly reports dead ends - issue383: reasonable orders not always generated - issue442: lm_rhw detects wrong orderings - issue467: assertion failure with unsolvable tasks - issue984: segfault in h^m landmark factory - issue937: breaking cycles chokes on unsolvable tasks (related to issue467) - issue998: lm_zg does not handle unsolvable tasks properly (related to issue467 and issue998) - issue1004: lm_rhw produces wrong greedy-neccessary orders important configurations for experiments testing changes in landmark factories: satisficing: - lama-first (alias) - like lama-first however with pref=True in lm_rhw - lmcount(lm_zg(reasonable_orders=false)) optimal: - --evaluator 'lmc=lmcount(lm_exhaust(),admissible=true)' --search 'astar(lmc,lazy_evaluator=lmc)' - --evaluator 'lmc=lmcount(lm_hm(m=2),admissible=true)' --search 'astar(lmc,lazy_evaluator=lmc)' - --alias seq-opt-bjolp - like seq-opt-bjolp but with lm_hm(m=2) instead of lm_merged(...) - like seq-opt-bjolp but with optimal=True in lmcount (this requires an installed LP solver) -> goals (see further details in msg9768): 1. The LandmarkGraph should be constant after creation, particularly it should not track the achieved status of landmarks in the currently evaluated state (issue988). 2. The LandmarkFactory should be cleaned up: it provides many methods as well as access to the exploration object which does not belong there (issue990). 3. We want a common LandmarkNode class from which the different types of landmarks (atomic, conjunctive, disjunctive, disjunctive action) inherit (issue999). --------- 4. Check if special treatment for cycles and landmarks that can be achieved simultaneously is necessary. 5. Look at used data structures and determine if there are better options. 6. Avoid storing information at weird places. 7. Check for obsolete code parts. (Goals 4-7 are more abstract and might require more discussion) related issues: cleanup and redesign: - issue160: automatically detect whether preferred operators should be computed - issue334: separate landmark generation and heuristic - issue384: use variables instead of predicate names for disjunctive landmarks - issue686: handle task transformations in path-dependent heuristics (currently there is a guard against accidental misuse, see issue845) - issue988: make the landmark graph constant after creation (goal 1) - issue989: make LandmarkGraph more readable and adapt code style - issue990: separate between relaxation-based and other landmark factories; move exploration to relaxation-based ones - issue992: make the landmark code consistent with coding conventions - issue993: make landmark graph objects be one-shot constructed by landmark (graph) factories - issue995: refactor LandmarkFactory options - issue996: create landmark factory that makes landmark graph acyclic - issue999: implement LandmarkNode as abstract class from which specific implementations for atomic, conjunctive, disjunctive ... landmarks inherit - issue1000: fix performance loss introduced in issue988 new features: - issue124: distinguish between first and all achievers when computing the lmcount heuristic - issue202: explore use of reasonable orders in admissible heuristics - issue257: allow overlapping landmarks in the same landmark graph - issue994: allow cyclic landmark graphs bugs: - issue247: lm heuristic crashes / wrongly reports dead ends - issue383: reasonable orders not always generated - issue442: lm_rhw detects wrong orderings - issue467: assertion failure with unsolvable tasks - issue984: segfault in h^m landmark factory - issue937: breaking cycles chokes on unsolvable tasks (related to issue467) - issue998: lm_zg does not handle unsolvable tasks properly (related to issue467 and issue998) - issue1004: lm_rhw produces wrong greedy-neccessary orders important configurations for experiments testing changes in landmark factories: satisficing: - lama-first (alias) - like lama-first however with pref=True in lm_rhw - lmcount(lm_zg(reasonable_orders=false)) optimal: - --evaluator 'lmc=lmcount(lm_exhaust(),admissible=true)' --search 'astar(lmc,lazy_evaluator=lmc)' - --evaluator 'lmc=lmcount(lm_hm(m=2),admissible=true)' --search 'astar(lmc,lazy_evaluator=lmc)' - --alias seq-opt-bjolp - like seq-opt-bjolp but with lm_hm(m=2) instead of lm_merged(...) - like seq-opt-bjolp but with optimal=True in lmcount (this requires an installed LP solver)
2021-02-02 18:19:07clemenssetsummary: goals (see further details in msg9768): 1. The LandmarkGraph should be constant after creation, particularly it should not track the achieved status of landmarks in the currently evaluated state (issue988). 2. The LandmarkFactory should be cleaned up: it provides many methods as well as access to the exploration object which does not belong there (issue990). 3. We want a common LandmarkNode class from which the different types of landmarks (atomic, conjunctive, disjunctive, disjunctive action) inherit (issue999). --------- 4. Check if special treatment for cycles and landmarks that can be achieved simultaneously is necessary. 5. Look at used data structures and determine if there are better options. 6. Avoid storing information at weird places. 7. Check for obsolete code parts. (Goals 4-7 are more abstract and might require more discussion) related issues: cleanup and redesign: - issue160: automatically detect whether preferred operators should be computed - issue334: separate landmark generation and heuristic - issue384: use variables instead of predicate names for disjunctive landmarks - issue686: handle task transformations in path-dependent heuristics (currently there is a guard against accidental misuse, see issue845) - issue988: make the landmark graph constant after creation (goal 1) - issue998: make LandmarkGraph more readable and adapt code style - issue990: separate between relaxation-based and other landmark factories; move exploration to relaxation-based ones - issue992: make the landmark code consistent with coding conventions - issue993: make landmark graph objects be one-shot constructed by landmark (graph) factories - issue995: refactor LandmarkFactory options - issue996: create landmark factory that makes landmark graph acyclic - issue999: implement LandmarkNode as abstract class from which specific implementations for atomic, conjunctive, disjunctive ... landmarks inherit - issue1000: fix performance loss introduced in issue988 new features: - issue124: distinguish between first and all achievers when computing the lmcount heuristic - issue202: explore use of reasonable orders in admissible heuristics - issue257: allow overlapping landmarks in the same landmark graph - issue994: allow cyclic landmark graphs bugs: - issue247: lm heuristic crashes / wrongly reports dead ends - issue383: reasonable orders not always generated - issue442: lm_rhw detects wrong orderings - issue467: assertion failure with unsolvable tasks - issue984: segfault in h^m landmark factory - issue937: breaking cycles chokes on unsolvable tasks (related to issue467) - issue998: lm_zg does not handle unsolvable tasks properly (related to issue467 and issue998) important configurations for experiments testing changes in landmark factories: satisficing: - lama-first (alias) - like lama-first however with pref=True in lm_rhw - lmcount(lm_zg(reasonable_orders=false)) optimal: - --evaluator 'lmc=lmcount(lm_exhaust(),admissible=true)' --search 'astar(lmc,lazy_evaluator=lmc)' - --evaluator 'lmc=lmcount(lm_hm(m=2),admissible=true)' --search 'astar(lmc,lazy_evaluator=lmc)' - --alias seq-opt-bjolp - like seq-opt-bjolp but with lm_hm(m=2) instead of lm_merged(...) - like seq-opt-bjolp but with optimal=True in lmcount (this requires an installed LP solver) -> goals (see further details in msg9768): 1. The LandmarkGraph should be constant after creation, particularly it should not track the achieved status of landmarks in the currently evaluated state (issue988). 2. The LandmarkFactory should be cleaned up: it provides many methods as well as access to the exploration object which does not belong there (issue990). 3. We want a common LandmarkNode class from which the different types of landmarks (atomic, conjunctive, disjunctive, disjunctive action) inherit (issue999). --------- 4. Check if special treatment for cycles and landmarks that can be achieved simultaneously is necessary. 5. Look at used data structures and determine if there are better options. 6. Avoid storing information at weird places. 7. Check for obsolete code parts. (Goals 4-7 are more abstract and might require more discussion) related issues: cleanup and redesign: - issue160: automatically detect whether preferred operators should be computed - issue334: separate landmark generation and heuristic - issue384: use variables instead of predicate names for disjunctive landmarks - issue686: handle task transformations in path-dependent heuristics (currently there is a guard against accidental misuse, see issue845) - issue988: make the landmark graph constant after creation (goal 1) - issue998: make LandmarkGraph more readable and adapt code style - issue990: separate between relaxation-based and other landmark factories; move exploration to relaxation-based ones - issue992: make the landmark code consistent with coding conventions - issue993: make landmark graph objects be one-shot constructed by landmark (graph) factories - issue995: refactor LandmarkFactory options - issue996: create landmark factory that makes landmark graph acyclic - issue999: implement LandmarkNode as abstract class from which specific implementations for atomic, conjunctive, disjunctive ... landmarks inherit - issue1000: fix performance loss introduced in issue988 new features: - issue124: distinguish between first and all achievers when computing the lmcount heuristic - issue202: explore use of reasonable orders in admissible heuristics - issue257: allow overlapping landmarks in the same landmark graph - issue994: allow cyclic landmark graphs bugs: - issue247: lm heuristic crashes / wrongly reports dead ends - issue383: reasonable orders not always generated - issue442: lm_rhw detects wrong orderings - issue467: assertion failure with unsolvable tasks - issue984: segfault in h^m landmark factory - issue937: breaking cycles chokes on unsolvable tasks (related to issue467) - issue998: lm_zg does not handle unsolvable tasks properly (related to issue467 and issue998) - issue1004: lm_rhw produces wrong greedy-neccessary orders important configurations for experiments testing changes in landmark factories: satisficing: - lama-first (alias) - like lama-first however with pref=True in lm_rhw - lmcount(lm_zg(reasonable_orders=false)) optimal: - --evaluator 'lmc=lmcount(lm_exhaust(),admissible=true)' --search 'astar(lmc,lazy_evaluator=lmc)' - --evaluator 'lmc=lmcount(lm_hm(m=2),admissible=true)' --search 'astar(lmc,lazy_evaluator=lmc)' - --alias seq-opt-bjolp - like seq-opt-bjolp but with lm_hm(m=2) instead of lm_merged(...) - like seq-opt-bjolp but with optimal=True in lmcount (this requires an installed LP solver)
2021-02-01 11:05:28silvansetmessages: + msg9969
summary: goals (see further details in msg9768): 1. The LandmarkGraph should be constant after creation, particularly it should not track the achieved status of landmarks in the currently evaluated state (issue988). 2. The LandmarkFactory should be cleaned up: it provides many methods as well as access to the exploration object which does not belong there (issue990). 3. We want a common LandmarkNode class from which the different types of landmarks (atomic, conjunctive, disjunctive, disjunctive action) inherit (issue999). --------- 4. Check if special treatment for cycles and landmarks that can be achieved simultaneously is necessary. 5. Look at used data structures and determine if there are better options. 6. Avoid storing information at weird places. 7. Check for obsolete code parts. (Goals 4-7 are more abstract and might require more discussion) related issues: cleanup and redesign: - issue160: automatically detect whether preferred operators should be computed - issue334: separate landmark generation and heuristic - issue384: use variables instead of predicate names for disjunctive landmarks - issue686: handle task transformations in path-dependent heuristics (currently there is a guard against accidental misuse, see issue845) - issue988: make the landmark graph constant after creation (goal 1) - issue998: make LandmarkGraph more readable and adapt code style - issue990: separate between relaxation-based and other landmark factories; move exploration to relaxation-based ones - issue992: make the landmark code consistent with coding conventions - issue993: make landmark graph objects be one-shot constructed by landmark (graph) factories - issue995: refactor LandmarkFactory options - issue996: create landmark factory that makes landmark graph acyclic - issue999: implement LandmarkNode as abstract class from which specific implementations for atomic, conjunctive, disjunctive ... landmarks inherit - issue1000: fix performance loss introduced in issue988 new features: - issue124: distinguish between first and all achievers when computing the lmcount heuristic - issue202: explore use of reasonable orders in admissible heuristics - issue257: allow overlapping landmarks in the same landmark graph - issue994: allow cyclic landmark graphs bugs: - issue247: lm heuristic crashes / wrongly reports dead ends - issue383: reasonable orders not always generated - issue442: lm_rhw detects wrong orderings - issue467: assertion failure with unsolvable tasks - issue984: segfault in h^m landmark factory - issue937: breaking cycles chokes on unsolvable tasks (related to issue467) - issue998: lm_zg does not handle unsolvable tasks properly (related to issue467 and issue998) important configurations for experiments testing changes in landmark factories: satisficing: - lama-first (alias) - like lama-first however with pref=True in lm_rhw - lmcount(lm_zg(reasonable_orders=false)) optimal: - lmcount(lm_exhaust(), admissible=true) - seq-opt-bjolp (alias) - like seq-opt-bjolp but with lm_hm(m=2) instead of lm_merged(...) - like seq-opt-bjolp but with optimal=True in lmcount (this requires an installed LP solver) -> goals (see further details in msg9768): 1. The LandmarkGraph should be constant after creation, particularly it should not track the achieved status of landmarks in the currently evaluated state (issue988). 2. The LandmarkFactory should be cleaned up: it provides many methods as well as access to the exploration object which does not belong there (issue990). 3. We want a common LandmarkNode class from which the different types of landmarks (atomic, conjunctive, disjunctive, disjunctive action) inherit (issue999). --------- 4. Check if special treatment for cycles and landmarks that can be achieved simultaneously is necessary. 5. Look at used data structures and determine if there are better options. 6. Avoid storing information at weird places. 7. Check for obsolete code parts. (Goals 4-7 are more abstract and might require more discussion) related issues: cleanup and redesign: - issue160: automatically detect whether preferred operators should be computed - issue334: separate landmark generation and heuristic - issue384: use variables instead of predicate names for disjunctive landmarks - issue686: handle task transformations in path-dependent heuristics (currently there is a guard against accidental misuse, see issue845) - issue988: make the landmark graph constant after creation (goal 1) - issue998: make LandmarkGraph more readable and adapt code style - issue990: separate between relaxation-based and other landmark factories; move exploration to relaxation-based ones - issue992: make the landmark code consistent with coding conventions - issue993: make landmark graph objects be one-shot constructed by landmark (graph) factories - issue995: refactor LandmarkFactory options - issue996: create landmark factory that makes landmark graph acyclic - issue999: implement LandmarkNode as abstract class from which specific implementations for atomic, conjunctive, disjunctive ... landmarks inherit - issue1000: fix performance loss introduced in issue988 new features: - issue124: distinguish between first and all achievers when computing the lmcount heuristic - issue202: explore use of reasonable orders in admissible heuristics - issue257: allow overlapping landmarks in the same landmark graph - issue994: allow cyclic landmark graphs bugs: - issue247: lm heuristic crashes / wrongly reports dead ends - issue383: reasonable orders not always generated - issue442: lm_rhw detects wrong orderings - issue467: assertion failure with unsolvable tasks - issue984: segfault in h^m landmark factory - issue937: breaking cycles chokes on unsolvable tasks (related to issue467) - issue998: lm_zg does not handle unsolvable tasks properly (related to issue467 and issue998) important configurations for experiments testing changes in landmark factories: satisficing: - lama-first (alias) - like lama-first however with pref=True in lm_rhw - lmcount(lm_zg(reasonable_orders=false)) optimal: - --evaluator 'lmc=lmcount(lm_exhaust(),admissible=true)' --search 'astar(lmc,lazy_evaluator=lmc)' - --evaluator 'lmc=lmcount(lm_hm(m=2),admissible=true)' --search 'astar(lmc,lazy_evaluator=lmc)' - --alias seq-opt-bjolp - like seq-opt-bjolp but with lm_hm(m=2) instead of lm_merged(...) - like seq-opt-bjolp but with optimal=True in lmcount (this requires an installed LP solver)
2021-01-29 08:49:14silvansetmessages: + msg9926
summary: goals (see further details in msg9768): 1. The LandmarkGraph should be constant after creation, particularly it should not track the achieved status of landmarks in the currently evaluated state (issue988). 2. The LandmarkFactory should be cleaned up: it provides many methods as well as access to the exploration object which does not belong there (issue990). 3. We want a common LandmarkNode class from which the different types of landmarks (atomic, conjunctive, disjunctive, disjunctive action) inherit (issue999). --------- 4. Check if special treatment for cycles and landmarks that can be achieved simultaneously is necessary. 5. Look at used data structures and determine if there are better options. 6. Avoid storing information at weird places. 7. Check for obsolete code parts. (Goals 4-7 are more abstract and might require more discussion) related issues: cleanup and redesign: - issue160: automatically detect whether preferred operators should be computed - issue334: separate landmark generation and heuristic - issue384: use variables instead of predicate names for disjunctive landmarks - issue686: handle task transformations in path-dependent heuristics (currently there is a guard against accidental misuse, see issue845) - issue988: make the landmark graph constant after creation (goal 1) - issue990: separate between relaxation-based and other landmark factories; move exploration to relaxation-based ones - issue992: make the landmark code consistent with coding conventions - issue993: make landmark graph objects be one-shot constructed by landmark (graph) factories - issue995: refactor LandmarkFactory options - issue996: create landmark factory that makes landmark graph acyclic - issue999: implement LandmarkNode as abstract class from which specific implementations for atomic, conjunctive, disjunctive ... landmarks inherit - issue1000: fix performance loss introduced in issue988 new features: - issue124: distinguish between first and all achievers when computing the lmcount heuristic - issue202: explore use of reasonable orders in admissible heuristics - issue257: allow overlapping landmarks in the same landmark graph - issue994: allow cyclic landmark graphs bugs: - issue247: lm heuristic crashes / wrongly reports dead ends - issue383: reasonable orders not always generated - issue442: lm_rhw detects wrong orderings - issue467: assertion failure with unsolvable tasks - issue984: segfault in h^m landmark factory - issue937: breaking cycles chokes on unsolvable tasks (related to issue467) - issue998: lm_zg does not handle unsolvable tasks properly (related to issue467 and issue998) important configurations for experiments testing changes in landmark factories: satisficing: - lama-first (alias) - like lama-first however with pref=True in lm_rhw - lmcount(lm_zg(reasonable_orders=false)) optimal: - lmcount(lm_exhaust(), admissible=true) - seq-opt-bjolp (alias) - like seq-opt-bjolp but with lm_hm(m=2) instead of lm_merged(...) - like seq-opt-bjolp but with optimal=True in lmcount (this requires an installed LP solver) -> goals (see further details in msg9768): 1. The LandmarkGraph should be constant after creation, particularly it should not track the achieved status of landmarks in the currently evaluated state (issue988). 2. The LandmarkFactory should be cleaned up: it provides many methods as well as access to the exploration object which does not belong there (issue990). 3. We want a common LandmarkNode class from which the different types of landmarks (atomic, conjunctive, disjunctive, disjunctive action) inherit (issue999). --------- 4. Check if special treatment for cycles and landmarks that can be achieved simultaneously is necessary. 5. Look at used data structures and determine if there are better options. 6. Avoid storing information at weird places. 7. Check for obsolete code parts. (Goals 4-7 are more abstract and might require more discussion) related issues: cleanup and redesign: - issue160: automatically detect whether preferred operators should be computed - issue334: separate landmark generation and heuristic - issue384: use variables instead of predicate names for disjunctive landmarks - issue686: handle task transformations in path-dependent heuristics (currently there is a guard against accidental misuse, see issue845) - issue988: make the landmark graph constant after creation (goal 1) - issue998: make LandmarkGraph more readable and adapt code style - issue990: separate between relaxation-based and other landmark factories; move exploration to relaxation-based ones - issue992: make the landmark code consistent with coding conventions - issue993: make landmark graph objects be one-shot constructed by landmark (graph) factories - issue995: refactor LandmarkFactory options - issue996: create landmark factory that makes landmark graph acyclic - issue999: implement LandmarkNode as abstract class from which specific implementations for atomic, conjunctive, disjunctive ... landmarks inherit - issue1000: fix performance loss introduced in issue988 new features: - issue124: distinguish between first and all achievers when computing the lmcount heuristic - issue202: explore use of reasonable orders in admissible heuristics - issue257: allow overlapping landmarks in the same landmark graph - issue994: allow cyclic landmark graphs bugs: - issue247: lm heuristic crashes / wrongly reports dead ends - issue383: reasonable orders not always generated - issue442: lm_rhw detects wrong orderings - issue467: assertion failure with unsolvable tasks - issue984: segfault in h^m landmark factory - issue937: breaking cycles chokes on unsolvable tasks (related to issue467) - issue998: lm_zg does not handle unsolvable tasks properly (related to issue467 and issue998) important configurations for experiments testing changes in landmark factories: satisficing: - lama-first (alias) - like lama-first however with pref=True in lm_rhw - lmcount(lm_zg(reasonable_orders=false)) optimal: - lmcount(lm_exhaust(), admissible=true) - seq-opt-bjolp (alias) - like seq-opt-bjolp but with lm_hm(m=2) instead of lm_merged(...) - like seq-opt-bjolp but with optimal=True in lmcount (this requires an installed LP solver)
2021-01-28 18:45:19silvansetmessages: + msg9900
summary: goals (see further details in msg9768): 1. The LandmarkGraph should be constant after creation, particularly it should not track the achieved status of landmarks in the currently evaluated state (issue988). 2. The LandmarkFactory should be cleaned up: it provides many methods as well as access to the exploration object which does not belong there (issue990). 3. We want a common LandmarkNode class from which the different types of landmarks (atomic, conjunctive, disjunctive, disjunctive action) inherit (issue999). --------- 4. Check if special treatment for cycles and landmarks that can be achieved simultaneously is necessary. 5. Look at used data structures and determine if there are better options. 6. Avoid storing information at weird places. 7. Check for obsolete code parts. (Goals 4-7 are more abstract and might require more discussion) related issues: cleanup and redesign: - issue160: automatically detect whether preferred operators should be computed - issue334: separate landmark generation and heuristic - issue384: use variables instead of predicate names for disjunctive landmarks - issue686: handle task transformations in path-dependent heuristics (currently there is a guard against accidental misuse, see issue845) - issue988: make the landmark graph constant after creation (goal 1) - issue990: separate between relaxation-based and other landmark factories; move exploration to relaxation-based ones - issue992: make the landmark code consistent with coding conventions - issue993: make landmark graph objects be one-shot constructed by landmark (graph) factories - issue995: refactor LandmarkFactory options - issue996: create landmark factory that makes landmark graph acyclic - issue999: implement LandmarkNode as abstract class from which specific implementations for atomic, conjunctive, disjunctive ... landmarks inherit new features: - issue124: distinguish between first and all achievers when computing the lmcount heuristic - issue202: explore use of reasonable orders in admissible heuristics - issue257: allow overlapping landmarks in the same landmark graph - issue994: allow cyclic landmark graphs bugs: - issue247: lm heuristic crashes / wrongly reports dead ends - issue383: reasonable orders not always generated - issue442: lm_rhw detects wrong orderings - issue467: assertion failure with unsolvable tasks - issue984: segfault in h^m landmark factory - issue937: breaking cycles chokes on unsolvable tasks (related to issue467) - issue998: lm_zg does not handle unsolvable tasks properly (related to issue467 and issue998) important configurations for experiments testing changes in landmark factories: satisficing: - lama-first (alias) - like lama-first however with pref=True in lm_rhw - lmcount(lm_zg(reasonable_orders=false)) optimal: - lmcount(lm_exhaust(), admissible=true) - seq-opt-bjolp (alias) - like seq-opt-bjolp but with lm_hm(m=2) instead of lm_merged(...) - like seq-opt-bjolp but with optimal=True in lmcount (this requires an installed LP solver) -> goals (see further details in msg9768): 1. The LandmarkGraph should be constant after creation, particularly it should not track the achieved status of landmarks in the currently evaluated state (issue988). 2. The LandmarkFactory should be cleaned up: it provides many methods as well as access to the exploration object which does not belong there (issue990). 3. We want a common LandmarkNode class from which the different types of landmarks (atomic, conjunctive, disjunctive, disjunctive action) inherit (issue999). --------- 4. Check if special treatment for cycles and landmarks that can be achieved simultaneously is necessary. 5. Look at used data structures and determine if there are better options. 6. Avoid storing information at weird places. 7. Check for obsolete code parts. (Goals 4-7 are more abstract and might require more discussion) related issues: cleanup and redesign: - issue160: automatically detect whether preferred operators should be computed - issue334: separate landmark generation and heuristic - issue384: use variables instead of predicate names for disjunctive landmarks - issue686: handle task transformations in path-dependent heuristics (currently there is a guard against accidental misuse, see issue845) - issue988: make the landmark graph constant after creation (goal 1) - issue990: separate between relaxation-based and other landmark factories; move exploration to relaxation-based ones - issue992: make the landmark code consistent with coding conventions - issue993: make landmark graph objects be one-shot constructed by landmark (graph) factories - issue995: refactor LandmarkFactory options - issue996: create landmark factory that makes landmark graph acyclic - issue999: implement LandmarkNode as abstract class from which specific implementations for atomic, conjunctive, disjunctive ... landmarks inherit - issue1000: fix performance loss introduced in issue988 new features: - issue124: distinguish between first and all achievers when computing the lmcount heuristic - issue202: explore use of reasonable orders in admissible heuristics - issue257: allow overlapping landmarks in the same landmark graph - issue994: allow cyclic landmark graphs bugs: - issue247: lm heuristic crashes / wrongly reports dead ends - issue383: reasonable orders not always generated - issue442: lm_rhw detects wrong orderings - issue467: assertion failure with unsolvable tasks - issue984: segfault in h^m landmark factory - issue937: breaking cycles chokes on unsolvable tasks (related to issue467) - issue998: lm_zg does not handle unsolvable tasks properly (related to issue467 and issue998) important configurations for experiments testing changes in landmark factories: satisficing: - lama-first (alias) - like lama-first however with pref=True in lm_rhw - lmcount(lm_zg(reasonable_orders=false)) optimal: - lmcount(lm_exhaust(), admissible=true) - seq-opt-bjolp (alias) - like seq-opt-bjolp but with lm_hm(m=2) instead of lm_merged(...) - like seq-opt-bjolp but with optimal=True in lmcount (this requires an installed LP solver)
2021-01-28 18:24:42silvansetmessages: + msg9896
summary: goals (see further details in msg9768): 1. The LandmarkGraph should be constant after creation, particularly it should not track the achieved status of landmarks in the currently evaluated state (issue988). 2. The LandmarkFactory should be cleaned up: it provides many methods as well as access to the exploration object which does not belong there (issue990). 3. We want a common LandmarkNode class from which the different types of landmarks (atomic, conjunctive, disjunctive, disjunctive action) inherit (issue999). --------- 4. Check if special treatment for cycles and landmarks that can be achieved simultaneously is necessary. 5. Look at used data structures and determine if there are better options. 6. Avoid storing information at weird places. 7. Check for obsolete code parts. (Goals 4-7 are more abstract and might require more discussion) related issues: cleanup and redesign: - issue160: automatically detect whether preferred operators should be computed - issue334: separate landmark generation and heuristic - issue384: use variables instead of predicate names for disjunctive landmarks - issue686: handle task transformations in path-dependent heuristics (currently there is a guard against accidental misuse, see issue845) - issue988: make the landmark graph constant after creation (goal 1) - issue990: separate between relaxation-based and other landmark factories; move exploration to relaxation-based ones - issue992: make the landmark code consistent with coding conventions - issue993: make landmark graph objects be one-shot constructed by landmark (graph) factories - issue995: refactor LandmarkFactory options - issue996: create landmark factory that makes landmark graph acyclic - issue999: implement LandmarkNode as abstract class from which specific implementations for atomic, conjunctive, disjunctive ... landmarks inherit new features: - issue124: distinguish between first and all achievers when computing the lmcount heuristic - issue202: explore use of reasonable orders in admissible heuristics - issue257: allow overlapping landmarks in the same landmark graph - issue994: allow cyclic landmark graphs bugs: - issue247: lm heuristic crashes / wrongly reports dead ends - issue383: reasonable orders not always generated - issue442: lm_rhw detects wrong orderings - issue467: assertion failure with unsolvable tasks - issue984: segfault in h^m landmark factory - issue937: breaking cycles chokes on unsolvable tasks (related to issue467) - issue998: lm_zg does not handle unsolvable tasks properly (related to issue467 and issue998) important configurations for experiments: 1. Lamafirst (satisficing) 2. Seqoptbjolp (optimal) 3. Lama (non-admissible version) 4. one configuration for every landmark factory not covered by the previous ones -> goals (see further details in msg9768): 1. The LandmarkGraph should be constant after creation, particularly it should not track the achieved status of landmarks in the currently evaluated state (issue988). 2. The LandmarkFactory should be cleaned up: it provides many methods as well as access to the exploration object which does not belong there (issue990). 3. We want a common LandmarkNode class from which the different types of landmarks (atomic, conjunctive, disjunctive, disjunctive action) inherit (issue999). --------- 4. Check if special treatment for cycles and landmarks that can be achieved simultaneously is necessary. 5. Look at used data structures and determine if there are better options. 6. Avoid storing information at weird places. 7. Check for obsolete code parts. (Goals 4-7 are more abstract and might require more discussion) related issues: cleanup and redesign: - issue160: automatically detect whether preferred operators should be computed - issue334: separate landmark generation and heuristic - issue384: use variables instead of predicate names for disjunctive landmarks - issue686: handle task transformations in path-dependent heuristics (currently there is a guard against accidental misuse, see issue845) - issue988: make the landmark graph constant after creation (goal 1) - issue990: separate between relaxation-based and other landmark factories; move exploration to relaxation-based ones - issue992: make the landmark code consistent with coding conventions - issue993: make landmark graph objects be one-shot constructed by landmark (graph) factories - issue995: refactor LandmarkFactory options - issue996: create landmark factory that makes landmark graph acyclic - issue999: implement LandmarkNode as abstract class from which specific implementations for atomic, conjunctive, disjunctive ... landmarks inherit new features: - issue124: distinguish between first and all achievers when computing the lmcount heuristic - issue202: explore use of reasonable orders in admissible heuristics - issue257: allow overlapping landmarks in the same landmark graph - issue994: allow cyclic landmark graphs bugs: - issue247: lm heuristic crashes / wrongly reports dead ends - issue383: reasonable orders not always generated - issue442: lm_rhw detects wrong orderings - issue467: assertion failure with unsolvable tasks - issue984: segfault in h^m landmark factory - issue937: breaking cycles chokes on unsolvable tasks (related to issue467) - issue998: lm_zg does not handle unsolvable tasks properly (related to issue467 and issue998) important configurations for experiments testing changes in landmark factories: satisficing: - lama-first (alias) - like lama-first however with pref=True in lm_rhw - lmcount(lm_zg(reasonable_orders=false)) optimal: - lmcount(lm_exhaust(), admissible=true) - seq-opt-bjolp (alias) - like seq-opt-bjolp but with lm_hm(m=2) instead of lm_merged(...) - like seq-opt-bjolp but with optimal=True in lmcount (this requires an installed LP solver)
2021-01-28 15:35:45clemenssetsummary: goals (see further details in msg9768): 1. The LandmarkGraph should be constant after creation, particularly it should not track the achieved status of landmarks in the currently evaluated state (issue988). 2. The LandmarkFactory should be cleaned up: it provides many methods as well as access to the exploration object which does not belong there (issue990). 3. We want a common LandmarkNode class from which the different types of landmarks (atomic, conjunctive, disjunctive, disjunctive action) inherit. --------- 4. Check if special treatment for cycles and landmarks that can be achieved simultaneously is necessary. 5. Look at used data structures and determine if there are better options. 6. Avoid storing information at weird places. 7. Check for obsolete code parts. (Goals 4-7 are more abstract and might require more discussion) related issues: cleanup and redesign: - issue160: automatically detect whether preferred operators should be computed - issue334: separate landmark generation and heuristic - issue384: use variables instead of predicate names for disjunctive landmarks - issue686: handle task transformations in path-dependent heuristics (currently there is a guard against accidental misuse, see issue845) - issue988: make the landmark graph constant after creation (goal 1) - issue990: separate between relaxation-based and other landmark factories; move exploration to relaxation-based ones - issue992: make the landmark code consistent with coding conventions - issue993: make landmark graph objects be one-shot constructed by landmark (graph) factories - issue995: refactor LandmarkFactory options - issue996: create landmark factory that makes landmark graph acyclic new features: - issue124: distinguish between first and all achievers when computing the lmcount heuristic - issue202: explore use of reasonable orders in admissible heuristics - issue257: allow overlapping landmarks in the same landmark graph - issue994: allow cyclic landmark graphs bugs: - issue247: lm heuristic crashes / wrongly reports dead ends - issue383: reasonable orders not always generated - issue442: lm_rhw detects wrong orderings - issue467: assertion failure with unsolvable tasks - issue984: segfault in h^m landmark factory - issue937: breaking cycles chokes on unsolvable tasks (related to issue467) - issue998: lm_zg does not handle unsolvable tasks properly (related to issue467 and issue998) important configurations for experiments: 1. Lamafirst (satisficing) 2. Seqoptbjolp (optimal) 3. Lama (non-admissible version) 4. one configuration for every landmark factory not covered by the previous ones -> goals (see further details in msg9768): 1. The LandmarkGraph should be constant after creation, particularly it should not track the achieved status of landmarks in the currently evaluated state (issue988). 2. The LandmarkFactory should be cleaned up: it provides many methods as well as access to the exploration object which does not belong there (issue990). 3. We want a common LandmarkNode class from which the different types of landmarks (atomic, conjunctive, disjunctive, disjunctive action) inherit (issue999). --------- 4. Check if special treatment for cycles and landmarks that can be achieved simultaneously is necessary. 5. Look at used data structures and determine if there are better options. 6. Avoid storing information at weird places. 7. Check for obsolete code parts. (Goals 4-7 are more abstract and might require more discussion) related issues: cleanup and redesign: - issue160: automatically detect whether preferred operators should be computed - issue334: separate landmark generation and heuristic - issue384: use variables instead of predicate names for disjunctive landmarks - issue686: handle task transformations in path-dependent heuristics (currently there is a guard against accidental misuse, see issue845) - issue988: make the landmark graph constant after creation (goal 1) - issue990: separate between relaxation-based and other landmark factories; move exploration to relaxation-based ones - issue992: make the landmark code consistent with coding conventions - issue993: make landmark graph objects be one-shot constructed by landmark (graph) factories - issue995: refactor LandmarkFactory options - issue996: create landmark factory that makes landmark graph acyclic - issue999: implement LandmarkNode as abstract class from which specific implementations for atomic, conjunctive, disjunctive ... landmarks inherit new features: - issue124: distinguish between first and all achievers when computing the lmcount heuristic - issue202: explore use of reasonable orders in admissible heuristics - issue257: allow overlapping landmarks in the same landmark graph - issue994: allow cyclic landmark graphs bugs: - issue247: lm heuristic crashes / wrongly reports dead ends - issue383: reasonable orders not always generated - issue442: lm_rhw detects wrong orderings - issue467: assertion failure with unsolvable tasks - issue984: segfault in h^m landmark factory - issue937: breaking cycles chokes on unsolvable tasks (related to issue467) - issue998: lm_zg does not handle unsolvable tasks properly (related to issue467 and issue998) important configurations for experiments: 1. Lamafirst (satisficing) 2. Seqoptbjolp (optimal) 3. Lama (non-admissible version) 4. one configuration for every landmark factory not covered by the previous ones
2021-01-28 12:22:06salomesetmessages: + msg9878
summary: goals (see further details in msg9768): 1. The LandmarkGraph should be constant after creation, particularly it should not track the achieved status of landmarks in the currently evaluated state (issue988). 2. The LandmarkFactory should be cleaned up: it provides many methods as well as access to the exploration object which does not belong there (issue990). 3. We want a common LandmarkNode class from which the different types of landmarks (atomic, conjunctive, disjunctive, disjunctive action) inherit. --------- 4. Check if special treatment for cycles and landmarks that can be achieved simultaneously is necessary. 5. Look at used data structures and determine if there are better options. 6. Avoid storing information at weird placs. 7. Check for obsolete code parts. (Goals 4-7 are more abstract and might require more discussion) related issues: cleanup and redesign: - issue160: automatically detect whether preferred operators should be computed - issue334: separate landmark generation and heuristic - issue384: use variables instead of predicate names for disjunctive landmarks - issue686: handle task transformations in path-dependent heuristics (currently there is a guard against accidental misuse, see issue845) - issue988: make the landmark graph constant after creation (goal 1) - issue990: separate between relaxation-based and other landmark factories; move exploration to relaxation-based ones - issue992: make the landmark code consistent with coding conventions - issue993: make landmark graph objects be one-shot constructed by landmark (graph) factories - issue995: refactor LandmarkFactory options - issue996: create landmark factory that makes landmark graph acyclic new features: - issue124: distinguish between first and all achievers when computing the lmcount heuristic - issue202: explore use of reasonable orders in admissible heuristics - issue257: allow overlapping landmarks in the same landmark graph - issue994: allow cyclic landmark graphs bugs: - issue247: lm heuristic crashes / wrongly reports dead ends - issue383: reasonable orders not always generated - issue442: lm_rhw detects wrong orderings - issue467: assertion failure with unsolvable tasks - issue984: segfault in h^m landmark factory - issue937: breaking cycles chokes on unsolvable tasks (related to issue467) important onfigurations for experiments: 1. Lamafirst (satisficing) 2. Seqoptbjolp (optimal) 3. Lama (non-admissible version) 4. one configuration for every landmark factory not covered by the previous ones -> goals (see further details in msg9768): 1. The LandmarkGraph should be constant after creation, particularly it should not track the achieved status of landmarks in the currently evaluated state (issue988). 2. The LandmarkFactory should be cleaned up: it provides many methods as well as access to the exploration object which does not belong there (issue990). 3. We want a common LandmarkNode class from which the different types of landmarks (atomic, conjunctive, disjunctive, disjunctive action) inherit. --------- 4. Check if special treatment for cycles and landmarks that can be achieved simultaneously is necessary. 5. Look at used data structures and determine if there are better options. 6. Avoid storing information at weird places. 7. Check for obsolete code parts. (Goals 4-7 are more abstract and might require more discussion) related issues: cleanup and redesign: - issue160: automatically detect whether preferred operators should be computed - issue334: separate landmark generation and heuristic - issue384: use variables instead of predicate names for disjunctive landmarks - issue686: handle task transformations in path-dependent heuristics (currently there is a guard against accidental misuse, see issue845) - issue988: make the landmark graph constant after creation (goal 1) - issue990: separate between relaxation-based and other landmark factories; move exploration to relaxation-based ones - issue992: make the landmark code consistent with coding conventions - issue993: make landmark graph objects be one-shot constructed by landmark (graph) factories - issue995: refactor LandmarkFactory options - issue996: create landmark factory that makes landmark graph acyclic new features: - issue124: distinguish between first and all achievers when computing the lmcount heuristic - issue202: explore use of reasonable orders in admissible heuristics - issue257: allow overlapping landmarks in the same landmark graph - issue994: allow cyclic landmark graphs bugs: - issue247: lm heuristic crashes / wrongly reports dead ends - issue383: reasonable orders not always generated - issue442: lm_rhw detects wrong orderings - issue467: assertion failure with unsolvable tasks - issue984: segfault in h^m landmark factory - issue937: breaking cycles chokes on unsolvable tasks (related to issue467) - issue998: lm_zg does not handle unsolvable tasks properly (related to issue467 and issue998) important configurations for experiments: 1. Lamafirst (satisficing) 2. Seqoptbjolp (optimal) 3. Lama (non-admissible version) 4. one configuration for every landmark factory not covered by the previous ones
2021-01-27 20:50:22thomassetmessages: + msg9868
summary: goals (see further details in msg9768): 1. The LandmarkGraph should be constant after creation, particularly it should not track the achieved status of landmarks in the currently evaluated state (issue988). 2. The LandmarkFactory should be cleaned up: it provides many methods as well as access to the exploration object which does not belong there (issue990). 3. We want a common LandmarkNode class from which the different types of landmarks (atomic, conjunctive, disjunctive, disjunctive action) inherit. --------- 4. Check if special treatment for cycles and landmarks that can be achieved simultaneously is necessary. 5. Look at used data structures and determine if there are better options. 6. Avoid storing information at weird placs. 7. Check for obsolete code parts. (Goals 4-7 are more abstract and might require more discussion) related issues: cleanup and redesign: - issue160: automatically detect whether preferred operators should be computed - issue334: separate landmark generation and heuristic - issue384: use variables instead of predicate names for disjunctive landmarks - issue686: handle task transformations in path-dependent heuristics (currently there is a guard against accidental misuse, see issue845) - issue988: make the landmark graph constant after creation (goal 1) - issue990: separate between relaxation-based and other landmark factories; move exploration to relaxation-based ones - issue992: make the landmark code consistent with coding conventions - issue993: make landmark graph objects be one-shot constructed by landmark (graph) factories - issue995: refactor LandmarkFactory options new features: - issue124: distinguish between first and all achievers when computing the lmcount heuristic - issue202: explore use of reasonable orders in admissible heuristics - issue257: allow overlapping landmarks in the same landmark graph - issue994: allow cyclic landmark graphs bugs: - issue247: lm heuristic crashes / wrongly reports dead ends - issue383: reasonable orders not always generated - issue442: lm_rhw detects wrong orderings - issue467: assertion failure with unsolvable tasks - issue984: segfault in h^m landmark factory - issue937: breaking cycles chokes on unsolvable tasks (related to issue467) important onfigurations for experiments: 1. Lamafirst (satisficing) 2. Seqoptbjolp (optimal) 3. Lama (non-admissible version) 4. one configuration for every landmark factory not covered by the previous ones -> goals (see further details in msg9768): 1. The LandmarkGraph should be constant after creation, particularly it should not track the achieved status of landmarks in the currently evaluated state (issue988). 2. The LandmarkFactory should be cleaned up: it provides many methods as well as access to the exploration object which does not belong there (issue990). 3. We want a common LandmarkNode class from which the different types of landmarks (atomic, conjunctive, disjunctive, disjunctive action) inherit. --------- 4. Check if special treatment for cycles and landmarks that can be achieved simultaneously is necessary. 5. Look at used data structures and determine if there are better options. 6. Avoid storing information at weird placs. 7. Check for obsolete code parts. (Goals 4-7 are more abstract and might require more discussion) related issues: cleanup and redesign: - issue160: automatically detect whether preferred operators should be computed - issue334: separate landmark generation and heuristic - issue384: use variables instead of predicate names for disjunctive landmarks - issue686: handle task transformations in path-dependent heuristics (currently there is a guard against accidental misuse, see issue845) - issue988: make the landmark graph constant after creation (goal 1) - issue990: separate between relaxation-based and other landmark factories; move exploration to relaxation-based ones - issue992: make the landmark code consistent with coding conventions - issue993: make landmark graph objects be one-shot constructed by landmark (graph) factories - issue995: refactor LandmarkFactory options - issue996: create landmark factory that makes landmark graph acyclic new features: - issue124: distinguish between first and all achievers when computing the lmcount heuristic - issue202: explore use of reasonable orders in admissible heuristics - issue257: allow overlapping landmarks in the same landmark graph - issue994: allow cyclic landmark graphs bugs: - issue247: lm heuristic crashes / wrongly reports dead ends - issue383: reasonable orders not always generated - issue442: lm_rhw detects wrong orderings - issue467: assertion failure with unsolvable tasks - issue984: segfault in h^m landmark factory - issue937: breaking cycles chokes on unsolvable tasks (related to issue467) important onfigurations for experiments: 1. Lamafirst (satisficing) 2. Seqoptbjolp (optimal) 3. Lama (non-admissible version) 4. one configuration for every landmark factory not covered by the previous ones
2021-01-27 11:17:00salomesetsummary: goals (see further details in msg9768): 1. The LandmarkGraph should be constant after creation, particularly it should not track the achieved status of landmarks in the currently evaluated state (issue988). 2. The LandmarkFactory should be cleaned up: it provides many methods as well as access to the exploration object which does not belong there (issue990). 3. We want a common LandmarkNode class from which the different types of landmarks (atomic, conjunctive, disjunctive, disjunctive action) inherit. --------- 4. Check if special treatment for cycles and landmarks that can be achieved simultaneously is necessary. 5. Look at used data structures and determine if there are better options. 6. Avoid storing information at weird placs. 7. Check for obsolete code parts. (Goals 4-7 are more abstract and might require more discussion) related issues: cleanup and redesign: - issue160: automatically detect whether preferred operators should be computed - issue334: separate landmark generation and heuristic - issue384: use variables instead of predicate names for disjunctive landmarks - issue686: handle task transformations in path-dependent heuristics (currently there is a guard against accidental misuse, see issue845) - issue988: make the landmark graph constant after creation (goal 1) - issue990: separate between relaxation-based and other landmark factories; move exploration to relaxation-based ones - issue992: make the landmark code consistent with coding conventions - issue993: make landmark graph objects be one-shot constructed by landmark (graph) factories new features: - issue124: distinguish between first and all achievers when computing the lmcount heuristic - issue202: explore use of reasonable orders in admissible heuristics - issue257: allow overlapping landmarks in the same landmark graph - issue994: allow cyclic landmark graphs bugs: - issue247: lm heuristic crashes / wrongly reports dead ends - issue383: reasonable orders not always generated - issue442: lm_rhw detects wrong orderings - issue467: assertion failure with unsolvable tasks - issue984: segfault in h^m landmark factory - issue937: breaking cycles chokes on unsolvable tasks (related to issue467) important onfigurations for experiments: 1. Lamafirst (satisficing) 2. Seqoptbjolp (optimal) 3. Lama (non-admissible version) 4. one configuration for every landmark factory not covered by the previous ones -> goals (see further details in msg9768): 1. The LandmarkGraph should be constant after creation, particularly it should not track the achieved status of landmarks in the currently evaluated state (issue988). 2. The LandmarkFactory should be cleaned up: it provides many methods as well as access to the exploration object which does not belong there (issue990). 3. We want a common LandmarkNode class from which the different types of landmarks (atomic, conjunctive, disjunctive, disjunctive action) inherit. --------- 4. Check if special treatment for cycles and landmarks that can be achieved simultaneously is necessary. 5. Look at used data structures and determine if there are better options. 6. Avoid storing information at weird placs. 7. Check for obsolete code parts. (Goals 4-7 are more abstract and might require more discussion) related issues: cleanup and redesign: - issue160: automatically detect whether preferred operators should be computed - issue334: separate landmark generation and heuristic - issue384: use variables instead of predicate names for disjunctive landmarks - issue686: handle task transformations in path-dependent heuristics (currently there is a guard against accidental misuse, see issue845) - issue988: make the landmark graph constant after creation (goal 1) - issue990: separate between relaxation-based and other landmark factories; move exploration to relaxation-based ones - issue992: make the landmark code consistent with coding conventions - issue993: make landmark graph objects be one-shot constructed by landmark (graph) factories - issue995: refactor LandmarkFactory options new features: - issue124: distinguish between first and all achievers when computing the lmcount heuristic - issue202: explore use of reasonable orders in admissible heuristics - issue257: allow overlapping landmarks in the same landmark graph - issue994: allow cyclic landmark graphs bugs: - issue247: lm heuristic crashes / wrongly reports dead ends - issue383: reasonable orders not always generated - issue442: lm_rhw detects wrong orderings - issue467: assertion failure with unsolvable tasks - issue984: segfault in h^m landmark factory - issue937: breaking cycles chokes on unsolvable tasks (related to issue467) important onfigurations for experiments: 1. Lamafirst (satisficing) 2. Seqoptbjolp (optimal) 3. Lama (non-admissible version) 4. one configuration for every landmark factory not covered by the previous ones
2021-01-27 09:33:10silvansetmessages: + msg9837
2021-01-27 08:45:55thomassetmessages: + msg9835
2021-01-27 08:31:59silvansetmessages: + msg9833
summary: goals (see further details in msg9768): 1. The LandmarkGraph should be constant after creation, particularly it should not track the achieved status of landmarks in the currently evaluated state (issue988). 2. The LandmarkFactory should be cleaned up: it provides many methods as well as access to the exploration object which does not belong there (issue990). 3. We want a common LandmarkNode class from which the different types of landmarks (atomic, conjunctive, disjunctive, disjunctive action) inherit. --------- 4. Check if special treatment for cycles and landmarks that can be achieved simultaneously is necessary. 5. Look at used data structures and determine if there are better options. 6. Avoid storing information at weird placs. 7. Check for obsolete code parts. (Goals 4-7 are more abstract and might require more discussion) related issues: cleanup and redesign: - issue160: automatically detect whether preferred operators should be computed - issue334: separate landmark generation and heuristic - issue384: use variables instead of predicate names for disjunctive landmarks - issue686: handle task transformations in path-dependent heuristics (currently there is a guard against accidental misuse, see issue845) - issue988: make the landmark graph constant after creation (goal 1) - issue990: separate between relaxation-based and other landmark factories; move exploration to relaxation-based ones - issue992: make the landmark code consistent with coding conventions - issue993: collect information on a landmark graph inside a landmark factory and create the landmark graph as a constant object new features: - issue124: distinguish between first and all achievers when computing the lmcount heuristic - issue202: explore use of reasonable orders in admissible heuristics - issue257: allow overlapping landmarks in the same landmark graph - issue994: allow cyclic landmark graphs bugs: - issue247: lm heuristic crashes / wrongly reports dead ends - issue383: reasonable orders not always generated - issue442: lm_rhw detects wrong orderings - issue467: assertion failure with unsolvable tasks - issue984: segfault in h^m landmark factory - issue937: breaking cycles chokes on unsolvable tasks (related to issue467) important onfigurations for experiments: 1. Lamafirst (satisficing) 2. Seqoptbjolp (optimal) 3. Lama (non-admissible version) 4. one configuration for every landmark factory not covered by the previous ones -> goals (see further details in msg9768): 1. The LandmarkGraph should be constant after creation, particularly it should not track the achieved status of landmarks in the currently evaluated state (issue988). 2. The LandmarkFactory should be cleaned up: it provides many methods as well as access to the exploration object which does not belong there (issue990). 3. We want a common LandmarkNode class from which the different types of landmarks (atomic, conjunctive, disjunctive, disjunctive action) inherit. --------- 4. Check if special treatment for cycles and landmarks that can be achieved simultaneously is necessary. 5. Look at used data structures and determine if there are better options. 6. Avoid storing information at weird placs. 7. Check for obsolete code parts. (Goals 4-7 are more abstract and might require more discussion) related issues: cleanup and redesign: - issue160: automatically detect whether preferred operators should be computed - issue334: separate landmark generation and heuristic - issue384: use variables instead of predicate names for disjunctive landmarks - issue686: handle task transformations in path-dependent heuristics (currently there is a guard against accidental misuse, see issue845) - issue988: make the landmark graph constant after creation (goal 1) - issue990: separate between relaxation-based and other landmark factories; move exploration to relaxation-based ones - issue992: make the landmark code consistent with coding conventions - issue993: make landmark graph objects be one-shot constructed by landmark (graph) factories new features: - issue124: distinguish between first and all achievers when computing the lmcount heuristic - issue202: explore use of reasonable orders in admissible heuristics - issue257: allow overlapping landmarks in the same landmark graph - issue994: allow cyclic landmark graphs bugs: - issue247: lm heuristic crashes / wrongly reports dead ends - issue383: reasonable orders not always generated - issue442: lm_rhw detects wrong orderings - issue467: assertion failure with unsolvable tasks - issue984: segfault in h^m landmark factory - issue937: breaking cycles chokes on unsolvable tasks (related to issue467) important onfigurations for experiments: 1. Lamafirst (satisficing) 2. Seqoptbjolp (optimal) 3. Lama (non-admissible version) 4. one configuration for every landmark factory not covered by the previous ones
2021-01-27 08:29:46silvansetmessages: + msg9830
2021-01-27 08:19:27silvansetmessages: + msg9829
summary: goals (see further details in msg9768): 1. The LandmarkGraph should be constant after creation, particularly it should not track the achieved status of landmarks in the currently evaluated state (issue988). 2. The LandmarkFactory should be cleaned up: it provides many methods as well as access to the exploration object which does not belong there (issue990). 3. We want a common LandmarkNode class from which the different types of landmarks (atomic, conjunctive, disjunctive, disjunctive action) inherit. --------- 4. Check if special treatment for cycles and landmarks that can be achieved simultaneously is necessary. 5. Look at used data structures and determine if there are better options. 6. Avoid storing information at weird placs. 7. Check for obsolete code parts. (Goals 4-7 are more abstract and might require more discussion) related issues: cleanup and redesign: - issue160: automatically detect whether preferred operators should be computed - issue334: separate landmark generation and heuristic - issue384: use variables instead of predicate names for disjunctive landmarks - issue686: handle task transformations in path-dependent heuristics (currently there is a guard against accidental misuse, see issue845) - issue988: make the landmark graph constant after creation (goal 1) - issue992: make the landmark code consistent with coding conventions - issue993: collect information on a landmark graph inside a landmark factory and create the landmark graph as a constant object new features: - issue124: distinguish between first and all achievers when computing the lmcount heuristic - issue202: explore use of reasonable orders in admissible heuristics - issue257: allow overlapping landmarks in the same landmark graph - issue994: allow cyclic landmark graphs bugs: - issue247: lm heuristic crashes / wrongly reports dead ends - issue383: reasonable orders not always generated - issue442: lm_rhw detects wrong orderings - issue467: assertion failure with unsolvable tasks - issue984: segfault in h^m landmark factory - issue937: breaking cycles chokes on unsolvable tasks (related to issue467) important onfigurations for experiments: 1. Lamafirst (satisficing) 2. Seqoptbjolp (optimal) 3. Lama (non-admissible version) 4. one configuration for every landmark factory not covered by the previous ones -> goals (see further details in msg9768): 1. The LandmarkGraph should be constant after creation, particularly it should not track the achieved status of landmarks in the currently evaluated state (issue988). 2. The LandmarkFactory should be cleaned up: it provides many methods as well as access to the exploration object which does not belong there (issue990). 3. We want a common LandmarkNode class from which the different types of landmarks (atomic, conjunctive, disjunctive, disjunctive action) inherit. --------- 4. Check if special treatment for cycles and landmarks that can be achieved simultaneously is necessary. 5. Look at used data structures and determine if there are better options. 6. Avoid storing information at weird placs. 7. Check for obsolete code parts. (Goals 4-7 are more abstract and might require more discussion) related issues: cleanup and redesign: - issue160: automatically detect whether preferred operators should be computed - issue334: separate landmark generation and heuristic - issue384: use variables instead of predicate names for disjunctive landmarks - issue686: handle task transformations in path-dependent heuristics (currently there is a guard against accidental misuse, see issue845) - issue988: make the landmark graph constant after creation (goal 1) - issue990: separate between relaxation-based and other landmark factories; move exploration to relaxation-based ones - issue992: make the landmark code consistent with coding conventions - issue993: collect information on a landmark graph inside a landmark factory and create the landmark graph as a constant object new features: - issue124: distinguish between first and all achievers when computing the lmcount heuristic - issue202: explore use of reasonable orders in admissible heuristics - issue257: allow overlapping landmarks in the same landmark graph - issue994: allow cyclic landmark graphs bugs: - issue247: lm heuristic crashes / wrongly reports dead ends - issue383: reasonable orders not always generated - issue442: lm_rhw detects wrong orderings - issue467: assertion failure with unsolvable tasks - issue984: segfault in h^m landmark factory - issue937: breaking cycles chokes on unsolvable tasks (related to issue467) important onfigurations for experiments: 1. Lamafirst (satisficing) 2. Seqoptbjolp (optimal) 3. Lama (non-admissible version) 4. one configuration for every landmark factory not covered by the previous ones
2021-01-26 21:31:06thomassetsummary: goals (see further details in msg9768): 1. The LandmarkGraph should be constant after creation, particularly it should not track the achieved status of landmarks in the currently evaluated state (issue988). 2. The LandmarkFactory should be cleaned up: it provides many methods as well as access to the exploration object which does not belong there (issue990). 3. We want a common LandmarkNode class from which the different types of landmarks (atomic, conjunctive, disjunctive, disjunctive action) inherit. --------- 4. Check if special treatment for cycles and landmarks that can be achieved simultaneously is necessary. 5. Look at used data structures and determine if there are better options. 6. Avoid storing information at weird placs. 7. Check for obsolete code parts. (Goals 4-7 are more abstract and might require more discussion) related issues: cleanup and redesign: - issue160: automatically detect whether preferred operators should be computed - issue334: separate landmark generation and heuristic - issue384: use variables instead of predicate names for disjunctive landmarks - issue686: handle task transformations in path-dependent heuristics (currently there is a guard against accidental misuse, see issue845) - issue988: make the landmark graph constant after creation (goal 1) - issue992: make the landmark code consistent with coding conventions new features: - issue124: distinguish between first and all achievers when computing the lmcount heuristic - issue202: explore use of reasonable orders in admissible heuristics - issue257: allow overlapping landmarks in the same landmark graph bugs: - issue247: lm heuristic crashes / wrongly reports dead ends - issue383: reasonable orders not always generated - issue442: lm_rhw detects wrong orderings - issue467: assertion failure with unsolvable tasks - issue984: segfault in h^m landmark factory - issue937: breaking cycles chokes on unsolvable tasks (related to issue467) important onfigurations for experiments: 1. Lamafirst (satisficing) 2. Seqoptbjolp (optimal) 3. Lama (non-admissible version) 4. one configuration for every landmark factory not covered by the previous ones -> goals (see further details in msg9768): 1. The LandmarkGraph should be constant after creation, particularly it should not track the achieved status of landmarks in the currently evaluated state (issue988). 2. The LandmarkFactory should be cleaned up: it provides many methods as well as access to the exploration object which does not belong there (issue990). 3. We want a common LandmarkNode class from which the different types of landmarks (atomic, conjunctive, disjunctive, disjunctive action) inherit. --------- 4. Check if special treatment for cycles and landmarks that can be achieved simultaneously is necessary. 5. Look at used data structures and determine if there are better options. 6. Avoid storing information at weird placs. 7. Check for obsolete code parts. (Goals 4-7 are more abstract and might require more discussion) related issues: cleanup and redesign: - issue160: automatically detect whether preferred operators should be computed - issue334: separate landmark generation and heuristic - issue384: use variables instead of predicate names for disjunctive landmarks - issue686: handle task transformations in path-dependent heuristics (currently there is a guard against accidental misuse, see issue845) - issue988: make the landmark graph constant after creation (goal 1) - issue992: make the landmark code consistent with coding conventions - issue993: collect information on a landmark graph inside a landmark factory and create the landmark graph as a constant object new features: - issue124: distinguish between first and all achievers when computing the lmcount heuristic - issue202: explore use of reasonable orders in admissible heuristics - issue257: allow overlapping landmarks in the same landmark graph - issue994: allow cyclic landmark graphs bugs: - issue247: lm heuristic crashes / wrongly reports dead ends - issue383: reasonable orders not always generated - issue442: lm_rhw detects wrong orderings - issue467: assertion failure with unsolvable tasks - issue984: segfault in h^m landmark factory - issue937: breaking cycles chokes on unsolvable tasks (related to issue467) important onfigurations for experiments: 1. Lamafirst (satisficing) 2. Seqoptbjolp (optimal) 3. Lama (non-admissible version) 4. one configuration for every landmark factory not covered by the previous ones
2021-01-26 21:16:12thomassetmessages: + msg9817
2021-01-26 21:03:24thomassetsummary: goals (see further details in msg9768): 1. The LandmarkGraph should be constant after creation, particularly it should not track the achieved status of landmarks in the currently evaluated state (issue988). 2. The LandmarkFactory should be cleaned up: it provides many methods as well as access to the exploration object which does not belong there (issue990). 3. We want a common LandmarkNode class from which the different types of landmarks (atomic, conjunctive, disjunctive, disjunctive action) inherit. --------- 4. Check if special treatment for cycles and landmarks that can be achieved simultaneously is necessary. 5. Look at used data structures and determine if there are better options. 6. Avoid storing information at weird placs. 7. Check for obsolete code parts. (Goals 4-7 are more abstract and might require more discussion) related issues: cleanup and redesign: - issue160: automatically detect whether preferred operators should be computed - issue334: separate landmark generation and heuristic - issue384: use variables instead of predicate names for disjunctive landmarks - issue686: handle task transformations in path-dependent heuristics (currently there is a guard against accidental misuse, see issue845) - issue988: make the landmark graph constant after creation (goal 1) new features: - issue124: distinguish between first and all achievers when computing the lmcount heuristic - issue202: explore use of reasonable orders in admissible heuristics - issue257: allow overlapping landmarks in the same landmark graph bugs: - issue247: lm heuristic crashes / wrongly reports dead ends - issue383: reasonable orders not always generated - issue442: lm_rhw detects wrong orderings - issue467: assertion failure with unsolvable tasks - issue984: segfault in h^m landmark factory - issue937: breaking cycles chokes on unsolvable tasks (related to issue467) important onfigurations for experiments: 1. Lamafirst (satisficing) 2. Seqoptbjolp (optimal) 3. Lama (non-admissible version) 4. one configuration for every landmark factory not covered by the previous ones -> goals (see further details in msg9768): 1. The LandmarkGraph should be constant after creation, particularly it should not track the achieved status of landmarks in the currently evaluated state (issue988). 2. The LandmarkFactory should be cleaned up: it provides many methods as well as access to the exploration object which does not belong there (issue990). 3. We want a common LandmarkNode class from which the different types of landmarks (atomic, conjunctive, disjunctive, disjunctive action) inherit. --------- 4. Check if special treatment for cycles and landmarks that can be achieved simultaneously is necessary. 5. Look at used data structures and determine if there are better options. 6. Avoid storing information at weird placs. 7. Check for obsolete code parts. (Goals 4-7 are more abstract and might require more discussion) related issues: cleanup and redesign: - issue160: automatically detect whether preferred operators should be computed - issue334: separate landmark generation and heuristic - issue384: use variables instead of predicate names for disjunctive landmarks - issue686: handle task transformations in path-dependent heuristics (currently there is a guard against accidental misuse, see issue845) - issue988: make the landmark graph constant after creation (goal 1) - issue992: make the landmark code consistent with coding conventions new features: - issue124: distinguish between first and all achievers when computing the lmcount heuristic - issue202: explore use of reasonable orders in admissible heuristics - issue257: allow overlapping landmarks in the same landmark graph bugs: - issue247: lm heuristic crashes / wrongly reports dead ends - issue383: reasonable orders not always generated - issue442: lm_rhw detects wrong orderings - issue467: assertion failure with unsolvable tasks - issue984: segfault in h^m landmark factory - issue937: breaking cycles chokes on unsolvable tasks (related to issue467) important onfigurations for experiments: 1. Lamafirst (satisficing) 2. Seqoptbjolp (optimal) 3. Lama (non-admissible version) 4. one configuration for every landmark factory not covered by the previous ones
2021-01-22 12:06:57thomassetsummary: goals (see further details in msg9768): 1. The LandmarkGraph should be constant after creation, particularly it should not track the achieved status of landmarks in the currently evaluated state (issue988). 2. The LandmarkFactory should be cleaned up: it provides many methods as well as access to the exploration object which does not belong there. 3. We want a common LandmarkNode class from which the different types of landmarks (atomic, conjunctive, disjunctive, disjunctive action) inherit. --------- 4. Check if special treatment for cycles and landmarks that can be achieved simultaneously is necessary. 5. Look at used data structures and determine if there are better options. 6. Avoid storing information at weird placs. 7. Check for obsolete code parts. (Goals 4-7 are more abstract and might require more discussion) related issues: cleanup and redesign: - issue160: automatically detect whether preferred operators should be computed - issue334: separate landmark generation and heuristic - issue384: use variables instead of predicate names for disjunctive landmarks - issue686: handle task transformations in path-dependent heuristics (currently there is a guard against accidental misuse, see issue845) - issue988: make the landmark graph constant after creation (goal 1) new features: - issue124: distinguish between first and all achievers when computing the lmcount heuristic - issue202: explore use of reasonable orders in admissible heuristics - issue257: allow overlapping landmarks in the same landmark graph bugs: - issue247: lm heuristic crashes / wrongly reports dead ends - issue383: reasonable orders not always generated - issue442: lm_rhw detects wrong orderings - issue467: assertion failure with unsolvable tasks - issue984: segfault in h^m landmark factory - issue937: breaking cycles chokes on unsolvable tasks (related to issue467) important onfigurations for experiments: 1. Lamafirst (satisficing) 2. Seqoptbjolp (optimal) 3. Lama (non-admissible version) 4. one configuration for every landmark factory not covered by the previous ones -> goals (see further details in msg9768): 1. The LandmarkGraph should be constant after creation, particularly it should not track the achieved status of landmarks in the currently evaluated state (issue988). 2. The LandmarkFactory should be cleaned up: it provides many methods as well as access to the exploration object which does not belong there (issue990). 3. We want a common LandmarkNode class from which the different types of landmarks (atomic, conjunctive, disjunctive, disjunctive action) inherit. --------- 4. Check if special treatment for cycles and landmarks that can be achieved simultaneously is necessary. 5. Look at used data structures and determine if there are better options. 6. Avoid storing information at weird placs. 7. Check for obsolete code parts. (Goals 4-7 are more abstract and might require more discussion) related issues: cleanup and redesign: - issue160: automatically detect whether preferred operators should be computed - issue334: separate landmark generation and heuristic - issue384: use variables instead of predicate names for disjunctive landmarks - issue686: handle task transformations in path-dependent heuristics (currently there is a guard against accidental misuse, see issue845) - issue988: make the landmark graph constant after creation (goal 1) new features: - issue124: distinguish between first and all achievers when computing the lmcount heuristic - issue202: explore use of reasonable orders in admissible heuristics - issue257: allow overlapping landmarks in the same landmark graph bugs: - issue247: lm heuristic crashes / wrongly reports dead ends - issue383: reasonable orders not always generated - issue442: lm_rhw detects wrong orderings - issue467: assertion failure with unsolvable tasks - issue984: segfault in h^m landmark factory - issue937: breaking cycles chokes on unsolvable tasks (related to issue467) important onfigurations for experiments: 1. Lamafirst (satisficing) 2. Seqoptbjolp (optimal) 3. Lama (non-admissible version) 4. one configuration for every landmark factory not covered by the previous ones
2021-01-21 09:48:36salomesetsummary: goals (see further details in msg9768): 1. The LandmarkGraph should be constant after creation, particularly it should not track the achieved status of landmarks in the currently evaluated state (issue988). 2. The LandmarkFactory should be cleaned up: it provides many methods as well as access to the exploration object which does not belong there. 3. We want a common LandmarkNode class from which the different types of landmarks (atomic, conjunctive, disjunctive, disjunctive action) inherit. --------- 4. Check if special treatment for cycles and landmarks that can be achieved simultaneously is necessary. 5. Look at used data structures and determine if there are better options. 6. Avoid storing information at weird placs. 7. Check for obsolete code parts. (Goals 4-7 are more abstract and might require more discussion) related issues: cleanup and redesign: - issue160: automatically detect whether preferred operators should be computed - issue334: separate landmark generation and heuristic - issue384: use variables instead of predicate names for disjunctive landmarks - issue686: handle task transformations in path-dependent heuristics (currently there is a guard against accidental misuse, see issue845) - issue988: make the landmark graph constant after creation (goal 1) new features: - issue124: distinguish between first and all achievers when computing the lmcount heuristic - issue202: explore use of reasonable orders in admissible heuristics - issue257: allow overlapping landmarks in the same landmark graph bugs: - issue247: lm heuristic crashes / wrongly reports dead ends - issue383: reasonable orders not always generated - issue442: lm_rhw detects wrong orderings - issue467: assertion failure with unsolvable tasks - issue984: segfault in h^m landmark factory - issue937: breaking cycles chokes on unsolvable tasks (related to issue467) important onfigurations for experiments: 1. Lamafirst (satisficing) 2. Seqoptbjolp (optimal) 3. Lama (non-admissible version) 4. one configuration for every landmark factory not covered by the previous ones
2021-01-20 12:30:24clemenssetmessages: + msg9770
2021-01-20 10:24:07thomassetmessages: + msg9768
2021-01-20 09:58:03silvansetnosy: + silvan
2021-01-19 17:59:36clemenssetmessages: + msg9767
2021-01-19 17:46:16clemenssetmessages: + msg9766
2021-01-19 17:04:01clemenscreate