We're closing these two issues (issue639 and issue641) because it does not look like we're going to integrate the implementations. The original patches were a bit too intrusive for us to integrate.

However, cleaning up the g-evaluator is on the radar and should help with the depth-based evaluator in issue641.

Regarding additional tie-breaking options for open lists, we feel that at the moment the use case is served well enough by implementing custom open lists. (This is also a question of prioritizing our efforts, so this may be more a question of priorities than whether this is a desirable feature. Priorities can of course be rediscussed in the future.)

Debugging complete, now all tests passed w/o errors.
https://circleci.com/gh/guicho271828/FastDownward/31

I am now investigating how I can test the runtime. (benchmarks/ directory seems
the best place, but I have to understand how to use it.)

Dear Dr.Helmert,

>> that this should be implemented
>> convince the core developers that this is a desirable feature: the aspects
that need to be balanced are code complexity, maintenance cost, fit with the
overall architecture, and run-time cost in the cases where the feature is used
and where it isn't used.

It is generally difficult to predict the code complexity before actually
implementing it, therefore I have already implemented the feature myself
(similar for the runtime). In fact, I managed to share some part of the code by
adding this feature = new code is simpler than the original (only a bit).

However, this is independent from the problem of merging it or not. I only
personally need this feature to write a new paper, and I do not try so hard to
have it merged.

>> Dear Masataro, please don't change the priority back from "wish" to "feature".
I understand. Sorry for messing up! I am only gradually but surely getting
accustomed to the convention here.

I am now testing my own builds on CircleCI independently from fast downward
buildbot. https://circleci.com/gh/guicho271828/FastDownward

Dear Masataro, please don't change the priority back from "wish" to "feature". I
intentionally changed it to "wish". We use "feature" when there is consensus
among the core developers that this should be implemented, and "wish" when it
isn't clear yet if the feature is desirable.

In this case, I think you would first have to convince the core developers that
this is a desirable feature: the aspects that need to be balanced are code
complexity, maintenance cost, fit with the overall architecture, and run-time
cost in the cases where the feature is used and where it isn't used.

Generally, we prefer compositional approaches, such as the one you mention in
issue641, because they usually have lower maintenance cost and simpler
components. But let's wait what the others say about this.

Regarding your comments in msg5191, I agree with all points (as far as I
understand the details). Things like removing "g" and "real_g" are already
planned, but so far, we didn't get around to it. My suggestion is that it would
be best to perform this cleanup first, and other related changes later, because
the cleanest implementation will hopefully be clearer after we've done the
cleanup steps.

Since I couldn't create issue639 branch on the remote side, I made an unofficial
copy of fast downward at github (https://github.com/guicho271828/FastDownward) .
The code is in branches/issue639 branch (naming is due to the export using
git-remote-hg)

I'm trying to push something to issue639, but it does not seem to exist.

BTW, re: refactoring, all code related to HeuristicCache might have to be
removed, and instead implemented in Evaluator (or its wrapper, something like
MemoizingEvaluator) with PerStateInformation. "g" and "real-g" in SearchNodeInfo
should also be removed. If performance matters for frequent local lookup of the
same state, then a layered cache mechanism might help (e.g. keep a few local
copies of the value for the most recent node in a small array that fits in CPU
cache)

Thank you, I will use the change note feature hereafter.

I already started working on this topic. The code that I used for AAAI16 is
based on an older version of FD and contains original refactoring done by me
(including the refactoring of heuristic cache issue). I need additional work in
it. The code is in [here](https://github.com/guicho271828/fast-downward-search)
but is not directly able to be merged nor in a good state.

Related: #610 , #270

Hi Masataro, welcome to the tracker!

Regarding the workflow, one small comment: please use the "Change Note" field
for discussion, not the "Optional summary". The latter is more used like a TODO
list by the core developers that implement a feature. I have to apologize that
the user interface is confusing and doesn't make this clear.

Usually, you should be automatically added to the "nosy list" (list of people
who get notified of changes to the issue) when you comment. I don't know why
this didn't happen in your case; I've added you manually.

I'm clearing the "optional summary" and copying Masataro's orginal message here:

================================================================================

enum option FIFO, LIFO, RANDOM to all open lists, which is applied only when two
or more nodes have the same priority (i.e. the last resort).

I'm new to mercurial and its workflow (I mostly work on git + github), hope I
won't disturb the repository.