-
Notifications
You must be signed in to change notification settings - Fork 144
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[issue1082] Use Options objects only in Features #218
Conversation
# Conflicts: # src/search/cartesian_abstractions/utils.cc # src/search/evaluator.cc # src/search/evaluator.h # src/search/heuristic.cc # src/search/heuristic.h # src/search/heuristics/additive_heuristic.cc # src/search/heuristics/additive_heuristic.h # src/search/heuristics/blind_search_heuristic.cc # src/search/heuristics/blind_search_heuristic.h # src/search/heuristics/ff_heuristic.cc # src/search/heuristics/ff_heuristic.h # src/search/heuristics/max_heuristic.cc # src/search/heuristics/max_heuristic.h # src/search/heuristics/relaxation_heuristic.cc # src/search/heuristics/relaxation_heuristic.h
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is only a partial review looking at the non-mechanical changes. The second part will follow later.
src/search/utils/rng_options.cc
Outdated
int seed = options.get<int>("random_seed"); | ||
tuple<int> get_rng_arguments_from_options( | ||
const plugins::Options &opts) { | ||
return make_tuple( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This return statement would comfortably fit on one line, making it more readable in my opinion.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i agree
@@ -0,0 +1,31 @@ | |||
#ifndef UTILS_TUPLES_H |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if adding some comments on how this template magic works would be beneficial. I only understood the code when Florian walked me through it. On the other hand I'm not sure if we need a detailed explanation, or are just happy that it does work ;).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is hard to understand and I also only understood it when Florian explained it to me.
A permanent place to find an explanation of it would be nice but the comments might not be the right place for it, is it?
reduce empty lines.
Not using ',' anymore improve pattern
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Part 1 of my comments, I'll add the rest later.
shared_ptr<utils::RandomNumberGenerator> rng = | ||
utils::parse_rng_from_options(opts); | ||
utils::get_rng(random_seed); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
no newline
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does not fit the '72 characters if possible' style guide
"Line width is 72 characters if possible, 80 characters max." - https://www.fast-downward.org/ForDevelopers/Whitespace?highlight=%2872%29
subtasks, max_states, max_transitions, | ||
max_time, pick, use_general_costs, | ||
random_seed, transform, log)) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
subtasks, max_states, max_transitions, | |
max_time, pick, use_general_costs, | |
random_seed, transform, log)) { | |
subtasks, max_states, max_transitions, max_time, pick, | |
use_general_costs, random_seed, transform, log)) { |
indent with 4 spaces
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i agree
but tox -e fix-style disagrees.
return tuple_cat(make_tuple(opts.get<FactOrder>("order")), | ||
utils::get_rng_arguments_from_options(opts)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
return tuple_cat(make_tuple(opts.get<FactOrder>("order")), | |
utils::get_rng_arguments_from_options(opts)); | |
return utils::make_flat_tuple( | |
opts.get<FactOrder>("order"), | |
utils::get_rng_arguments_from_options(opts)); |
with an implementation of make_flat_tuple()
in tuple.h
:
template<class ... Ts>
auto make_flat_tuple(Ts&&... ts) {
return flatten_tuple(std::forward_as_tuple(ts...));
}
This also needs an overload of flatten_tuple
for l-value reverences, because forward_as_tuple
creates them. It should be doable with perfect forwarding to not duplicate the code here but I didn't manage.
template<class ... Ts>
auto flatten_tuple(std::tuple<Ts...> &t) {
constexpr std::size_t tuple_size =
std::tuple_size<std::tuple<Ts...>>::value;
return flatten_tuple_elements(
std::move(t), std::make_index_sequence<tuple_size>());
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Most of the comments are easy fixes.
Comments about style can also be ignored if you disagree.
One recurring comment is that the order of arguments in the constructor does not match the order of fields in the class definition. I personally find it more readable if they are the same (that is, if the arguments are used in the same order in the initialization list as in the constructor arguments, minus the ones that go to the parent of course). But I'm also ok with leaving it as it is.
src/search/utils/rng_options.cc
Outdated
int seed = options.get<int>("random_seed"); | ||
tuple<int> get_rng_arguments_from_options( | ||
const plugins::Options &opts) { | ||
return make_tuple( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, do we really need to return a tuple here?
const PickSplit pick_split; | ||
const bool use_general_costs; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why did we change the order here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To match the parameter order in the constructor of CostSaturation, there it was changed to match the constructor of AdditeiveCartesianHeuristic, there it was chosen in the way to match the wiki.
preferred_operator_evaluators(opts.get_list<shared_ptr<Evaluator>>("preferred")), | ||
preferred_usage(opts.get<PreferredUsage>("preferred_usage")), | ||
const shared_ptr<Evaluator> &h, PreferredUsage preferred_usage, | ||
const vector<shared_ptr<Evaluator>> &preferred, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Field order inconsistent with constructor order.
randomize_successors(randomize_successors), | ||
preferred_successors_first(preferred_successors_first), | ||
rng(utils::get_rng(random_seed)), | ||
preferred_operator_evaluators(preferred), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Field order inconsistent with constructor order (preferred_operator_evaluators
)
options_copy.set("open", search_common::create_greedy_open_list_factory(options_copy)); | ||
options_copy.set("reopen_closed", false); | ||
shared_ptr<Evaluator> evaluator = nullptr; | ||
options_copy.set("f_eval", evaluator); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Other times we kept using options_copy
. What is the difference here? Could we also get rid of it in other cases?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We kept it if it was not trivial how to remove it.
It would be possible to get rid of more opts_copies by moving the logic into the create_component function but I think keeping it somewhat encapsulated is nice.
Isn't this a compiler warning that we treat as an error? I guess not, since it compiles, but I thought this would be a requirement. |
I think it would be good to trigger an error in the Github Actions, but not I don't think it's necessarily worth investing time to try to make that happen if it doesn't currently. In case you don't know, unless I misremember, C++ semantics is that the initialization (including evaluation of the initializers) happens in the order in the class definition, not the order given in the constructor. So for example, something like this:
would first call |
No description provided.