Skip to content

Update Iterated battle #124

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

Merged
merged 6 commits into from
Sep 28, 2023
Merged

Conversation

ImogenBits
Copy link
Collaborator

This does two things, first it updates the Iterated battle code to be a bit easier to read while leaving the functionality practically the same. The only difference is that previously when the step size was reset after a generator failure was 4, not 1 as it is at the start of the battle. I think this is a bug so the new code doesn't retain that behaviour.

The second part is adding the feature requested in #70. A new setting max_generator_errors can be set to either an integer or "unlimited", if it is an integer the battle will skip any future fights and award the solving team with the current maximum score. Note that this might not be the cap as set in the config, if eg the generator first succeeds all the way to size 1000, where the solver fails, but then fails enough to cause a skip at sizes 900-950 the solver will only achieve a score of 1000, not the cap set in the config.

@Benezivas
Copy link
Collaborator

Thank you for addressing the open issue. I am a bit cautious about rewriting the iteration. Would you mind adding a few test cases and see if they pass for the new version? Things to test that come to mind are:

  • Is the cap updated when a solver fails
  • Is the iteration step size reset when a solver fails
  • Does the iteration end if the solver is successful one increment step before the current cap
  • Does the iteration end if the solver is unsuccessful one increment step before the current cap
  • Do two failures of the solver immediately in a row result in the end of the iteration
  • Is the result consistent if a solver fails at the very first step
  • Does the solver successfully reach the initial maximum cap if it is able to solve everything

I remember having a lot of trouble with these and related edge cases when I originally designed the iterated battle, so I want to make sure that we do not accidentally re-introduce any of the old errors.

On another note: Since we end the battle prematurely now in some cases, with a nonzero default option, it may be helpful for the users to learn why a battle that they observe suddenly ends with the maximum cap, instead of resulting in a silent break.

@ImogenBits
Copy link
Collaborator Author

added tests for all of your cases and some more, and a "note" field in the UI that tells you what the battle is doing, e.g. if it's been reset because of the generator failing too often.

@Benezivas
Copy link
Collaborator

Perfect, thank you.

@Benezivas Benezivas merged commit 335e992 into Algorithmic-Battle:4.0.0-rc Sep 28, 2023
@ImogenBits ImogenBits deleted the iterated branch September 28, 2023 08:29
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.

2 participants