Created on 2015-12-09.12:31:26 by malte, last changed by malte.
1. Clean up EHC open list factory and make EHC use breadth-first search rather than uniform-cost search. (See msg9706.)
2. Address fishy code in search engine plugins. (See msg9706.)
3. Add missing synopsis for wiki or commit to having no synopsis for several wiki pages. (See msg9706.)
4. Move code in src/search/search_engines/search_common.h to a more appropriate place. (See msg9706.)
|
msg9707 (view) |
Author: malte |
Date: 2020-08-04.12:33:28 |
|
Updating the summary.
|
msg9706 (view) |
Author: malte |
Date: 2020-08-04.12:30:26 |
|
Expanding the cryptic summary into the actual TODOs it represented:
1. create_ehc_open_list_factory in src/search/search_engines/enforced_hill_climbing_search.cc:
/*
TODO: this g-evaluator should probably be set up to always
ignore costs since EHC is supposed to implement a breadth-first
search, not a uniform-cost search. So this seems to be a bug.
*/
/*
TODO: Reduce code duplication with search_common.cc,
function create_standard_scalar_open_list_factory.
It would probably make sense to add a factory function or
constructor that encapsulates this work to the standard
scalar open list code.
*/
/*
TODO: Reduce code duplication with search_common.cc,
function create_astar_open_list_factory_and_f_eval.
It would probably make sense to add a factory function or
constructor that encapsulates this work to the tie-breaking
open list code.
*/
2. src/search/search_engines/plugin_lazy.cc,
src/search/search_engines/plugin_lazy_greedy.cc,
src/search/search_engines/plugin_lazy_wastar.cc:
/*
TODO: The following two lines look fishy. If they serve a
purpose, shouldn't the constructor take care of this?
*/
// TODO: The following two lines look fishy. See similar comment in _parse.
// TODO: The following two lines look fishy. See similar comment in _parse.
(The last two of these are outdated. Instead of referring to "_parse", they
should refer to plugin_lazy.cc.)
3. src/search/open_lists/open_list_factory.cc:
// TODO: Replace empty string by synopsis for the wiki page.
The same comment also appears in:
src/search/abstract_task.cc
src/search/operator_counting/constraint_generator.cc
src/search/search_engine.cc
4. src/search/search_engines/search_common.h:
TODO: Think about where this code should ideally live. One possible
ordering principle: avoid unnecessary plug-in dependencies.
|
msg9705 (view) |
Author: malte |
Date: 2020-08-04.12:16:40 |
|
Removing the item from the summary that has been done.
|
msg8944 (view) |
Author: malte |
Date: 2019-07-16.00:22:05 |
|
Testing email notifications after server maintenance.
|
msg8543 (view) |
Author: jendrik |
Date: 2019-02-26.22:29:12 |
|
I created issue895 for the renaming and added it to the summary.
|
msg8521 (view) |
Author: malte |
Date: 2019-02-15.13:15:47 |
|
> I could make the change, if you like.
Sure, that would be nice! Beyond the class name, we should also touch up the
wiki documentation for the class.
This should probably be a separate issue from this one because this one is a
meta-issue that still has other things in it. (If there only one thing
remaining, I think it would be fine to just use this issue number for the branch.)
|
msg8520 (view) |
Author: florian |
Date: 2019-02-15.10:18:53 |
|
> Florian, does this work for you, too?
I'm fine with the name.
|
msg8519 (view) |
Author: jendrik |
Date: 2019-02-15.09:23:11 |
|
I could make the change, if you like.
|
msg8518 (view) |
Author: malte |
Date: 2019-02-13.16:03:02 |
|
Florian, does this work for you, too? Then I would make this change.
|
msg8517 (view) |
Author: jendrik |
Date: 2019-02-13.13:47:27 |
|
I like the name "BestFirstOpenList".
|
msg8515 (view) |
Author: malte |
Date: 2019-02-13.13:36:54 |
|
Hi all, there was activity on this issue while the mail server moved. If you
don't want to miss progress on this issue, please check in the tracker if there
was anything you missed.
|
msg8509 (view) |
Author: malte |
Date: 2019-02-08.15:10:10 |
|
So we are left with two TODOs, looking at the ugliness left behind by changeset
05069b5d0c35, and renaming StandardScalarOpenList.
The first one needs a closer look, but the second one seems to be simple enough.
I suggest "BestFirstOpenList" as the new name for "StandardScalarOpenList". What
the priority queue does is implement what we call best-first search in our AI
lecture (and what Russell & Norvig call best-first search): select the best
element according to a single evaluation function. There are further details
(how to break ties; performance characteristics), but I don't think we need to
make them part of the class name. What do you think?
|
msg8508 (view) |
Author: malte |
Date: 2019-02-08.15:04:53 |
|
I think this meta issue can use some spring cleaning. Going through some of the
current TODO items in the summary:
> * TODO Reduce code duplication in open list factories
>
> - There is a large amount of boilerplate in the open list factories;
> not just in the code, but also in the class definition.
>
> - Perhaps we can define a templated base class that contains the
> common stuff?
I suppose some duplication could be reduced by applying the CRTP, I don't think
it's too bad. I removed this entry, but as always feel free to reopen the
discussion if you disagree.
> * TODO Introduce namespaces for open list factories (issue715)
> * TODO Introduce cmake plugins for open list factories (issue715)
These are done. Also removed.
> * TODO Reconsider which code lives where, also w.r.t. search engines
>
> - For most classes, in principle nothing needs to be in the header
> file, since even the factories are in most cases only used by the
> plug-in. But there are some external users of certain open list
> factories, which currently mostly go via search_common.cc. The way
> this code is split up should be reconsidered, perhaps with the goal
> of minimizing the number of plug-in dependencies. For example, we
> should not need to pay for the dependencies of A* if we don't want
> to compile in A*. One appealing way to change this is to move
> convenience plug-ins like A* out of eager_search.cc, but this should
> probably only be done once the search engines have been moved to
> their own directory to avoid proliferation of files in the main
> directory.
The most important part of this -- moving the "syntactic sugar" search engine
plug-ins like A* into separate files, and making their previously messy
generation of open lists much cleaner -- has been done. I don't see a real
action item here any more, so I've removed this one, too.
It is still possible to move more codes from headers to source files, and we can
still do more work to reduce plugin dependencies, but the open list code is
actually quite well-behaved in this respect now.
So I've also removed this.
|
msg6206 (view) |
Author: jendrik |
Date: 2017-04-24.15:51:07 |
|
cross-reference issue715
|
msg4919 (view) |
Author: malte |
Date: 2015-12-09.12:35:34 |
|
Add a TODO about renaming StandardScalarOpenList.
|
msg4917 (view) |
Author: malte |
Date: 2015-12-09.12:31:25 |
|
This issue collects various refactoring TODOs for the open lists.
The initial list is taken from issue481:
* TODO Reduce code duplication in open list factories
- There is a large amount of boilerplate in the open list factories;
not just in the code, but also in the class definition.
- Perhaps we can define a templated base class that contains the
common stuff?
* TODO Introduce namespaces for open list factories
* TODO Introduce cmake plugins for open list factories
* TODO Reconsider which code lives where, also w.r.t. search engines
- For most classes, in principle nothing needs to be in the header
file, since even the factories are in most cases only used by the
plug-in. But there are some external users of certain open list
factories, which currently mostly go via search_common.cc. The way
this code is split up should be reconsidered, perhaps with the goal
of minimizing the number of plug-in dependencies. For example, we
should not need to pay for the dependencies of A* if we don't want
to compile in A*. One appealing way to change this is to move
convenience plug-ins like A* out of eager_search.cc, but this should
probably only be done once the search engines have been moved to
their own directory to avoid proliferation of files in the main
directory.
* TODO search for TODOs in diff and convert them to issues
hg diff -c 05069b5d0c35 | less
then search for TODO
|
|
Date |
User |
Action |
Args |
2020-08-04 12:33:28 | malte | set | messages:
+ msg9707 summary: 1. Clean up EHC open list factory and make EHC use breadth-first search rather than uniform-cost search. (See msg9706.)
2. Address fishy code in search engine plugins. (See msg9706.)
3. Add missing synopsis for wiki or commit to having no synopsis for several wiki pages. (See msg9706.)
4. Move code in src/search/search_engines/search_common.h to a more appropriate place. (See msg9706.) |
2020-08-04 12:30:26 | malte | set | messages:
+ msg9706 summary: * TODO Check the following changeset diff:
hg diff -c 05069b5d0c35 | less
then search for TODO -> (no value) |
2020-08-04 12:16:41 | malte | set | messages:
+ msg9705 summary: * TODO Check the following changeset diff:
hg diff -c 05069b5d0c35 | less
then search for TODO
* TODO Rename StandardScalarOpenList (issue895) -> * TODO Check the following changeset diff:
hg diff -c 05069b5d0c35 | less
then search for TODO |
2019-07-16 00:22:05 | malte | set | messages:
+ msg8944 |
2019-02-26 22:29:12 | jendrik | set | messages:
+ msg8543 summary: * TODO Check the following changeset diff:
hg diff -c 05069b5d0c35 | less
then search for TODO
* TODO Rename StandardScalarOpenList
"Standard" doesn't say much, and we've moved away from saying "Scalar"
everywhere. Perhaps something like TreeBucketOpenList matches the
implementation. To make this painless for users, we can keep the plugin name
("single"), which is rather generic. -> * TODO Check the following changeset diff:
hg diff -c 05069b5d0c35 | less
then search for TODO
* TODO Rename StandardScalarOpenList (issue895) |
2019-02-15 13:15:47 | malte | set | messages:
+ msg8521 |
2019-02-15 10:18:53 | florian | set | messages:
+ msg8520 |
2019-02-15 09:23:11 | jendrik | set | messages:
+ msg8519 |
2019-02-13 16:03:02 | malte | set | messages:
+ msg8518 |
2019-02-13 13:47:27 | jendrik | set | messages:
+ msg8517 |
2019-02-13 13:36:54 | malte | set | messages:
+ msg8515 |
2019-02-08 15:10:10 | malte | set | messages:
+ msg8509 |
2019-02-08 15:04:53 | malte | set | messages:
+ msg8508 summary: * TODO Reduce code duplication in open list factories
- There is a large amount of boilerplate in the open list factories;
not just in the code, but also in the class definition.
- Perhaps we can define a templated base class that contains the
common stuff?
* TODO Introduce namespaces for open list factories (issue715)
* TODO Introduce cmake plugins for open list factories (issue715)
* TODO Reconsider which code lives where, also w.r.t. search engines
- For most classes, in principle nothing needs to be in the header
file, since even the factories are in most cases only used by the
plug-in. But there are some external users of certain open list
factories, which currently mostly go via search_common.cc. The way
this code is split up should be reconsidered, perhaps with the goal
of minimizing the number of plug-in dependencies. For example, we
should not need to pay for the dependencies of A* if we don't want
to compile in A*. One appealing way to change this is to move
convenience plug-ins like A* out of eager_search.cc, but this should
probably only be done once the search engines have been moved to
their own directory to avoid proliferation of files in the main
directory.
* TODO Check the following changeset diff:
hg diff -c 05069b5d0c35 | less
then search for TODO
* TODO Rename StandardScalarOpenList
"Standard" doesn't say much, and we've moved away from saying "Scalar"
everywhere. Perhaps something like TreeBucketOpenList matches the
implementation. To make this painless for users, we can keep the plugin name
("single"), which is rather generic. -> * TODO Check the following changeset diff:
hg diff -c 05069b5d0c35 | less
then search for TODO
* TODO Rename StandardScalarOpenList
"Standard" doesn't say much, and we've moved away from saying "Scalar"
everywhere. Perhaps something like TreeBucketOpenList matches the
implementation. To make this painless for users, we can keep the plugin name
("single"), which is rather generic. |
2017-04-24 15:51:07 | jendrik | set | messages:
+ msg6206 summary: * TODO Reduce code duplication in open list factories
- There is a large amount of boilerplate in the open list factories;
not just in the code, but also in the class definition.
- Perhaps we can define a templated base class that contains the
common stuff?
* TODO Introduce namespaces for open list factories
* TODO Introduce cmake plugins for open list factories
* TODO Reconsider which code lives where, also w.r.t. search engines
- For most classes, in principle nothing needs to be in the header
file, since even the factories are in most cases only used by the
plug-in. But there are some external users of certain open list
factories, which currently mostly go via search_common.cc. The way
this code is split up should be reconsidered, perhaps with the goal
of minimizing the number of plug-in dependencies. For example, we
should not need to pay for the dependencies of A* if we don't want
to compile in A*. One appealing way to change this is to move
convenience plug-ins like A* out of eager_search.cc, but this should
probably only be done once the search engines have been moved to
their own directory to avoid proliferation of files in the main
directory.
* TODO Check the following changeset diff:
hg diff -c 05069b5d0c35 | less
then search for TODO
* TODO Rename StandardScalarOpenList
"Standard" doesn't say much, and we've moved away from saying "Scalar"
everywhere. Perhaps something like TreeBucketOpenList matches the
implementation. To make this painless for users, we can keep the plugin name
("single"), which is rather generic. -> * TODO Reduce code duplication in open list factories
- There is a large amount of boilerplate in the open list factories;
not just in the code, but also in the class definition.
- Perhaps we can define a templated base class that contains the
common stuff?
* TODO Introduce namespaces for open list factories (issue715)
* TODO Introduce cmake plugins for open list factories (issue715)
* TODO Reconsider which code lives where, also w.r.t. search engines
- For most classes, in principle nothing needs to be in the header
file, since even the factories are in most cases only used by the
plug-in. But there are some external users of certain open list
factories, which currently mostly go via search_common.cc. The way
this code is split up should be reconsidered, perhaps with the goal
of minimizing the number of plug-in dependencies. For example, we
should not need to pay for the dependencies of A* if we don't want
to compile in A*. One appealing way to change this is to move
convenience plug-ins like A* out of eager_search.cc, but this should
probably only be done once the search engines have been moved to
their own directory to avoid proliferation of files in the main
directory.
* TODO Check the following changeset diff:
hg diff -c 05069b5d0c35 | less
then search for TODO
* TODO Rename StandardScalarOpenList
"Standard" doesn't say much, and we've moved away from saying "Scalar"
everywhere. Perhaps something like TreeBucketOpenList matches the
implementation. To make this painless for users, we can keep the plugin name
("single"), which is rather generic. |
2015-12-09 13:20:46 | malte | set | summary: * TODO Reduce code duplication in open list factories
- There is a large amount of boilerplate in the open list factories;
not just in the code, but also in the class definition.
- Perhaps we can define a templated base class that contains the
common stuff?
* TODO Introduce namespaces for open list factories
* TODO Introduce cmake plugins for open list factories
* TODO Reconsider which code lives where, also w.r.t. search engines
- For most classes, in principle nothing needs to be in the header
file, since even the factories are in most cases only used by the
plug-in. But there are some external users of certain open list
factories, which currently mostly go via search_common.cc. The way
this code is split up should be reconsidered, perhaps with the goal
of minimizing the number of plug-in dependencies. For example, we
should not need to pay for the dependencies of A* if we don't want
to compile in A*. One appealing way to change this is to move
convenience plug-ins like A* out of eager_search.cc, but this should
probably only be done once the search engines have been moved to
their own directory to avoid proliferation of files in the main
directory.
* TODO search for TODOs in diff and convert them to issues
hg diff -c 05069b5d0c35 | less
then search for TODO -> * TODO Reduce code duplication in open list factories
- There is a large amount of boilerplate in the open list factories;
not just in the code, but also in the class definition.
- Perhaps we can define a templated base class that contains the
common stuff?
* TODO Introduce namespaces for open list factories
* TODO Introduce cmake plugins for open list factories
* TODO Reconsider which code lives where, also w.r.t. search engines
- For most classes, in principle nothing needs to be in the header
file, since even the factories are in most cases only used by the
plug-in. But there are some external users of certain open list
factories, which currently mostly go via search_common.cc. The way
this code is split up should be reconsidered, perhaps with the goal
of minimizing the number of plug-in dependencies. For example, we
should not need to pay for the dependencies of A* if we don't want
to compile in A*. One appealing way to change this is to move
convenience plug-ins like A* out of eager_search.cc, but this should
probably only be done once the search engines have been moved to
their own directory to avoid proliferation of files in the main
directory.
* TODO Check the following changeset diff:
hg diff -c 05069b5d0c35 | less
then search for TODO
* TODO Rename StandardScalarOpenList
"Standard" doesn't say much, and we've moved away from saying "Scalar"
everywhere. Perhaps something like TreeBucketOpenList matches the
implementation. To make this painless for users, we can keep the plugin name
("single"), which is rather generic. |
2015-12-09 12:35:34 | malte | set | messages:
+ msg4919 |
2015-12-09 12:33:53 | florian | set | nosy:
+ florian |
2015-12-09 12:32:18 | jendrik | set | nosy:
+ jendrik |
2015-12-09 12:31:26 | malte | create | |
|