Skip to content
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

Merged
merged 238 commits into from
Jul 5, 2024

Conversation

SimonDold
Copy link
Contributor

No description provided.

SimonDold and others added 18 commits November 22, 2023 16:44
# 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
src/search/evaluator.cc Outdated Show resolved Hide resolved
src/search/heuristic.h Outdated Show resolved Hide resolved
src/search/utils/logging.cc Outdated Show resolved Hide resolved
src/search/heuristics/max_heuristic.h Outdated Show resolved Hide resolved
Copy link
Contributor

@salome-eriksson salome-eriksson left a 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.

misc/tests/test-parameters.py Show resolved Hide resolved
misc/tests/test-parameters.py Show resolved Hide resolved
misc/tests/test-parameters.py Outdated Show resolved Hide resolved
misc/tests/test-parameters.py Outdated Show resolved Hide resolved
src/search/utils/logging.h Show resolved Hide resolved
int seed = options.get<int>("random_seed");
tuple<int> get_rng_arguments_from_options(
const plugins::Options &opts) {
return make_tuple(
Copy link
Contributor

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.

Copy link
Contributor Author

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
Copy link
Contributor

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 ;).

Copy link
Contributor Author

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?

SimonDold and others added 4 commits June 28, 2024 18:44
reduce empty lines.
Not using ',' anymore
improve pattern
Copy link
Member

@FlorianPommerening FlorianPommerening left a 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.

misc/tests/test-parameters.py Outdated Show resolved Hide resolved
misc/tests/test-parameters.py Outdated Show resolved Hide resolved
misc/tests/test-parameters.py Outdated Show resolved Hide resolved
misc/tests/test-parameters.py Outdated Show resolved Hide resolved
misc/tests/test-parameters.py Outdated Show resolved Hide resolved
shared_ptr<utils::RandomNumberGenerator> rng =
utils::parse_rng_from_options(opts);
utils::get_rng(random_seed);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no newline

Copy link
Contributor Author

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

Comment on lines +43 to +45
subtasks, max_states, max_transitions,
max_time, pick, use_general_costs,
random_seed, transform, log)) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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

Copy link
Contributor Author

@SimonDold SimonDold Jul 2, 2024

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.

Comment on lines +182 to +183
return tuple_cat(make_tuple(opts.get<FactOrder>("order")),
utils::get_rng_arguments_from_options(opts));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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>());
}

src/search/cartesian_abstractions/utils.cc Outdated Show resolved Hide resolved
Copy link
Contributor

@salome-eriksson salome-eriksson left a 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.

int seed = options.get<int>("random_seed");
tuple<int> get_rng_arguments_from_options(
const plugins::Options &opts) {
return make_tuple(
Copy link
Contributor

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;
Copy link
Contributor

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?

Copy link
Contributor Author

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.

src/search/evaluator.h Show resolved Hide resolved
src/search/evaluator.h Outdated Show resolved Hide resolved
src/search/heuristic.cc Show resolved Hide resolved
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,
Copy link
Contributor

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),
Copy link
Contributor

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);
Copy link
Contributor

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?

Copy link
Contributor Author

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.

src/search/search_algorithms/search_common.cc Show resolved Hide resolved
src/search/search_algorithms/search_common.cc Show resolved Hide resolved
@FlorianPommerening
Copy link
Member

FlorianPommerening commented Jul 2, 2024

the order of arguments in the constructor does not match the order of fields in the class definition.

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.

@maltehelmert
Copy link
Contributor

the order of arguments in the constructor does not match the order of fields in the class definition.

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:

X::X() : foo(f()), bar(g()) {}

would first call g() in order to initialize bar and then call f() in order to initalize foo if bar comes before foo in the class definition.

@SimonDold SimonDold merged commit 54e8669 into aibasel:main Jul 5, 2024
11 of 12 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants