-
Notifications
You must be signed in to change notification settings - Fork 86
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
Multiple winners in autopilot #2996
Conversation
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 don't think this PR is very useful by itself (it will get stale before it can be made useful by actually using the new parameter).
If you think it's shouldn't be merged unless it's used, then I will implement #2995 inside this PR. |
Regarding the current PR, I don't see any blockers from the enabled parallel auction preparation/solving side. |
} | ||
} | ||
} | ||
|
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.
Moved into a separate function because now it's called in two places (runloop and shadow)
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.
It's not really clear why we reversed the solution ordering. Unless that is required for some reason I would prefer if we do not touch it unnecessarily.
Few reasons why I changed this:
Being a risky change is not a good reason IMO to not touch some part of the code. Can you name reasons why we shouldn't touch it? |
@@ -514,11 +525,14 @@ impl RunLoop { | |||
|
|||
// Shuffle so that sorting randomly splits ties. | |||
solutions.shuffle(&mut rand::thread_rng()); | |||
solutions.sort_unstable_by_key(|participant| participant.solution.score().get().0); | |||
solutions.sort_unstable_by_key(|participant| { |
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.
Seems like shuffling and sorting by score would also fit into the shared function to pick a winner.
That way the entire core decision making is shared correctly across shadow and regular autopilot.
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.
It pains a bit to approve this without the autopilot refactor but at this point it makes more sense to merge this first even with the complex code duplication.
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.
Lg. The logic behind reversing the solutions back and forth looks a bit confusing, but I couldn't currently come up with a suggestion on how to avoid that.
True. However, ranking logic in the autopilot |
Description
Fixes #2994
Fixes #2995
Fixes #2998
max_winners_per_auction
to enable/disable multiple winners feature.max_winners_per_auction
.The only remaining part to implement is competition saving but this is captured with #3021