Fix osu! standardised score estimation algorithm violating basic invariants #27513
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…riants As it turns out, the "lower" and "upper" estimates of the combo portion of the score being converted were misnomers. In selected cases (scores with high accuracy but combo being lower than max by more than a few objects) the janky score-based math could overestimate the count of remaining objects in a map. For instance, in one case the numbers worked out something like this: - Accuracy: practically 100% - Max combo on beatmap: 571x - Max combo for score: 551x The score-based estimation attempts to extract a "remaining object count" from score, by doing something along of sqrt(571^2 - 551^2). That comes out to _almost 150_. Which leads to the estimation overshooting the total max combo count on the beatmap by some hundred objects. To curtail this nonsense, enforce some basic invariants: - Neither estimate is allowed to exceed maximum achievable - Ensure that lower estimate is really lower and upper is really upper by just looking at the values and making sure that is so rather than just saying that it is.
|
I trust that the math here is sound enough based on your word, but could you confirm whether this is going to change every total score number when reverifying (or only the outliers)? That has a large impact on how long this will take to run, and how I approach running it. |
In theory this should meaningfully touch only the outliers. |
|
@smoogipoo did you want to check this one? else i will get it rolling out with minimal review coverage to keep forward momentum. |
smoogipoo
approved these changes
Mar 7, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Warning
If this PR is merged, all imported osu! scores will need to be re-verified.
Rationale
As it turns out, the "lower" and "upper" estimates of the combo portion of the score being converted were misnomers. In selected cases (scores with high accuracy but combo being lower than max by more than a few objects) the janky score-based math could overestimate the count of remaining objects in a map. For instance, in the case cited in the issue the numbers worked out something like this:
The score-based estimation attempts to extract a "remaining object count" from score, by doing something along the lines of$\sqrt{571^2 - 551^2}$ . That comes out to almost 150. Which leads to the estimation overshooting the total max combo count on the beatmap by some hundred objects.
To curtail this nonsense, enforce some basic invariants:
Testing
Spreadsheet: https://docs.google.com/spreadsheets/d/1DPtxdRZINENF2G1ymeZ6uF9EvFKy9KDHJx4rKXmn5FY/edit#gid=855782594
Selected 5 biggest gains by relative %
masterSelected 5 biggest gains by absolute score
masterSelected 5 biggest losses by relative %
masterSelected 5 biggest losses by absolute score
mastercc @Zyfarok