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

Change: Distribute left over cargo to stations according to the highest remainder #8398

Conversation

SamuXarick
Copy link
Contributor

Instead of distributing the cargo among the best rated stations, distribute it according to the highest remainder.

@LordAro
Copy link
Member

LordAro commented Dec 19, 2020

Please explain why this change should be made

@SamuXarick
Copy link
Contributor Author

SamuXarick commented Dec 20, 2020

Please explain why this change should be made

My idea here was to change the logic on what to do about the missing cargo that can originate from "a / b" division.

The original code rewards an extra cargo unit to stations that have the highest rating for that cargo type, but this approach disregards what I'm calling of "remainder". The highest rated station could, for example, be receiving 361/2=180 units with a rating of 200, and the second highest could be receiving 482/3=160 with a rating of 190. The remainder is, however, not tracked.

My code adds the ability to track the remainder of the a / b division. But since this value can't be simply a % b due to the multitude of values that b could have in different instances, I had to come up with a solution to make different remainders equiparable. That's when (a % b) / b came up. This would result in a value in the range [0,1[, which resembles the fractional part of a decimal number. However, due to how interger division works, the result is always 0. Scaling (a % b) / b by 100 would result in getting a fractional part of two decimals, but this didn't look like it had the precision it needed, so I went up scaling it up further to a maximum of a 16-bit value, hence the 65535 * (a % b) / b.

With equiparable remainders, going back to the 2 stations mentioned above, we have:

Rating Units moved (a % b) / b with 2 decimals Normalized remainder
200 361 / 2 = 180 0,50 32767
190 482 / 3 = 160 0,66 43690

Now, even though the 2nd station has less rating (190) than the 1st (200), and less cargo moved (160+0,66 = 160,66) than the first station (180+0,50 = 180,5), 0,66 is closer to 1 than 0,50. And that's the basis of the logic of how the extra unit of cargo is added.

@SamuXarick
Copy link
Contributor Author

SamuXarick commented Dec 25, 2020

Worst case station scenario file for testing:
single house.zip
Wronningbury Transport, 1992-12-27
1 house covered by 124 stations

@SamuXarick SamuXarick force-pushed the distribute-rounding-cargo-bits-alternative branch from 95d314f to 35f4a85 Compare December 25, 2020 19:37
@SamuXarick SamuXarick force-pushed the distribute-rounding-cargo-bits-alternative branch 3 times, most recently from 2ade8c3 to 6747912 Compare January 11, 2021 20:07
@SamuXarick SamuXarick force-pushed the distribute-rounding-cargo-bits-alternative branch from 6747912 to abc258a Compare June 6, 2021 14:46
@SamuXarick SamuXarick force-pushed the distribute-rounding-cargo-bits-alternative branch from abc258a to de7d37a Compare August 3, 2021 16:42
@ldpl
Copy link
Contributor

ldpl commented Nov 26, 2021

Matt Parker just made a video on station cargo distribution: https://www.youtube.com/watch?v=GVhFBujPlVo
TLDR Distributing by remainders is not "fair" either, it still favors higher ratings just in a more roundabout and random way.

…st remainder

Instead of distributing the cargo among the best rated stations, distribute it according to the highest remainder.
@SamuXarick SamuXarick force-pushed the distribute-rounding-cargo-bits-alternative branch from de7d37a to 904aa5e Compare June 12, 2022 11:10
@2TallTyler
Copy link
Member

I don't see a need for this change. It's not fixing a bug, just changing how something works. The change only makes a tiny difference and only in edge cases. With no real interest in two years, I'm going to close this PR. As always, if someone disagrees, feel free to reopen. 🙂

@2TallTyler 2TallTyler closed this Nov 7, 2022
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.

None yet

4 participants