We did a fair number of replacement of "heuristic" and similar strings ("heur", "h_value" etc.) throughout the whole codebase.
Everything compiles fine and we run some local tests. The main risk here was e.g. to replace "heur" with "evaluator" in some class
where "evaluator" was already being used (I was surprised to see that doesn't produce even a warning...),
but we were careful with that:
https://bitbucket.org/gfrances/downward-issue815/pull-requests/1/issue815/diff
Not sure what the best way to review this is though, as there might be occurrences of "heuristic" which we might have missed, and of course
the PR diff won't help there. Some occurrences that we did not change but are relevant are:
* "HeuristicCache" class, heuristic_cache.cc file, etc., which work so far only with heuristics, and we agreed should be left as they are now.
* Parser options such as "-h" -- changing this would break compatibility. We could create aliases, but that is beyond the scope of this issue.
* Planner output such as:
cout << "Initial heuristic value for " << description << ": ";
cout << "New best heuristic value for " << description << ": "
which could break parsing scripts, etc., and besides is not that clear that we'd want that changed in the first place.
In any case it'd be good to review this soon, as many files are affected and merge conflicts are likely to appear...
And just for the reference, here is a count of the (line-) occurrences of the string "heur" in each subdirectory of the "search" dir:
.../src/search$ for i in $(find . -type d); do echo $i $(grep -Iirn heur $i | wc -l); done | column -t
. 1034
./options 20
./heuristics 295
./open_lists 6
./pdbs 124
./landmarks 145
./utils 1
./tasks 0
./evaluators 9
./search_engines 30
./lp 0
./pruning 0
./ext 0
./algorithms 0
./potentials 80
./merge_and_shrink 52
./cegar 74
./operator_counting 36
./task_utils 3
|