Rerun optimization until valid solution or timeout #53
Conversation
| auto const& var = robot.variables[j_idx]; | ||
| population_[i].genes[j_idx] = rsl::uniform_real(var.clip_min, var.clip_max); | ||
| } | ||
| population_[i].genes = robot.get_random_valid_configuration(); |
There was a problem hiding this comment.
@tylerjw C++ question: Does switching this implementation from modifying elements of a pre-existing vector to returning a brand new one and overwriting the variable affect performance significantly?
Wondering if it makes more sense for this new function to accept a mutable vector by reference instead.
There was a problem hiding this comment.
This is one of the reasons that C++ std algorithms take iterators to existing containers. I don't care either way. I think this is easier to read, and I'd always bias towards easier-to-read code unless you have a benchmark showing that the performance difference matters for your use-case.
There was a problem hiding this comment.
Yeah, I think this is fine especially because it only happens when initializing a new population member and not all the time.
| auto const& var = robot.variables[j_idx]; | ||
| population_[i].genes[j_idx] = rsl::uniform_real(var.clip_min, var.clip_max); | ||
| } | ||
| population_[i].genes = robot.get_random_valid_configuration(); |
There was a problem hiding this comment.
This is one of the reasons that C++ std algorithms take iterators to existing containers. I don't care either way. I think this is easier to read, and I'd always bias towards easier-to-read code unless you have a benchmark showing that the performance difference matters for your use-case.
This PR continues rerunning optimization within the timeout budget if the validity callback failed, using a random valid initial seed on each restart.
It also creates a
Robot::get_random_valid_configuration()member function that is used for this new logic plus in the memetic optimizer. Yay reuse!Closes #49.