Author malte
Recipients erez, florian, gabi, jendrik, malte, silvia
Date 2015-11-10.12:54:10
I understand your concern regarding the search code. We want to avoid mixing
"core code" and "plug-in code". I think that the problem here is that the code
was never designed with "search engine" as an actual abstract interface in mind.

Our heuristics/evaluator interface was designed to make these components
replaceable, but the search code was originally monolithic, and the current
design of SearchEngine was created mainly to reuse code between lazy and eager
search, not to provide a well-thought out general abstraction for search algorithms.

As a consequence, the base class already contains what are essentially
implementation details of lazy and eager search. Some components, such as the
search space, probably shouldn't be there. (I can't see it being useful for
something like symbolic search, if we ever wanted to add that, or to give an
example in the current codebase: I can't see it being useful for iterated search.)

Stepping aside from the concrete discussion about the search code, the more I
think about this, the more uncomfortable I am with us having a discussion about
the directory and namespace structure for all parts of the planner at the same
time. I've now spent around two hours on this comment, editing and deleting
stuff, and thinking about how various parts of the search code work together.
Investing this effort would make sense if we were actually planning to work on
the search code at the moment, but I don't think we are. (But volunteers always
welcome! :-)) There are other parts of the proposed structure that I am also a
bit uncomfortable with, but I am somewhat afraid to mention them because of the
cost of the discussion.

I understand and share the desire to clean up the code by moving files into
subdirectories and creating namespaces, but I think this only makes sense if the
resulting directories are cohesive, i.e., have *strong* internal connections
(thematically and/or in terms of implementation) and *weak* connections to the
rest of the code. In cases like the heuristics or evaluators, this is a given,
and it is easy to move them to a separate place. In many other cases, however,
this cohesion first has to be created because we currently have quite tangled
dependencies. The search code I mentioned at the start is an example: I think
that the "abstract interface" (SearchEngine) currently depends on implementation
details (SearchSpace, SearchNode etc.) in ways that it should not, and
when/before introducing a "search" subdirectory, we should tackle this issue,
e.g. by introducing a new class between SearchEngine and LazySearch/EagerSearch.
(Just as an example -- I suggest we only discuss this in more depth at the point
where we want to work on it.)

To me, the underlying high-level problem is to identify cohesive logical
components in the planner code and then make the code layout (in terms of
directory/file name structure and namespaces) agree better with the partitioning
into logical components than it does currently.

The benefit of this, if done well, is that it can become easier to understand
the overall picture. For example, I would like to be able to say something like
"If you want to implement a new search algorithm, the part of the code that you
want to study in depth is A. Parts B and C are also somewhat relevant, but it's
enough to have a superficial understanding. You don't have to worry at all about
D and E."

I think a more productive way to do this is one component at a time. For
example, we could start with the easy cases. To me, the cases that look easiest
at the moment are the proposed directories "heuristics", "evaluators", "options"
and "lp". All other (new) directories I think need further discussion that I
would rather defer until the point where someone wants to work on this
component. In other words, I'm not happy with the proposed structure for these
others, but I also don't want to start a detailed discussion on them until we're
ready to work on them.

Focusing on the easy cases:

1) Do we want to have a separate directory "heuristics" and "evaluators" or a
single directory for both? I should mention that we are working towards getting
rid of the difference between the two concepts, so they will eventually be the
same thing. (Or at least that's my understanding of our latest discussion on
this topic.)

2) With two relatively small source files, is the LP code large enough for its
own subdirectory? Counting the lines of code for all four suggested new directories:

- evaluators: 470 LOC, 7 cc files
- heuristics: 2968 LOC, 13 cc files
- lp: 674 LOC, 2 cc files
- options: 2165 LOC, 3 cc files
Date User Action Args
2015-11-10 12:54:10maltesetmessageid: <>
2015-11-10 12:54:10maltesetrecipients: + malte, erez, gabi, silvia, jendrik, florian
2015-11-10 12:54:10maltelinkissue64 messages
2015-11-10 12:54:10maltecreate