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

Refactor Futility Margin Formula #5077

Closed
wants to merge 3 commits into from

Conversation

FauziAkram
Copy link
Contributor

@FauziAkram FauziAkram commented Feb 26, 2024

In the current implementation, the formula involves several consecutive multiplications and divisors. Making it challenging to understand the order of operations.

Refactor Futility Margin Formula, to make it easier to understand.
Since using ternary operator, the logic, and order of operations become more apparent.
Removed the parentheses and moved the improving multiply before the divide for easier-to-read operator precedence (Thanks to @mstembera for this solution idea).

Non Functional

bench: 1303971
@Disservin
Copy link
Member

Idk, I find using the current implementation cleaner.
Also generates slightly different code for gcc https://godbolt.org/z/cYabGn7K3

@FauziAkram
Copy link
Contributor Author

What if instead of ternary, we add at least a few parentheses, such as:
return ((futilityMult * d) - (((3 * futilityMult) / 2) * improving));

@cj5716
Copy link
Contributor

cj5716 commented Feb 26, 2024

I honestly don't feel any need for changes to our existing formula, however I believe the outside brackets are redundant in our current formula

bench: 1303971
@mstembera
Copy link
Contributor

What do people think about ?

return futilityMult * d - 3 * futilityMult * improving / 2;

@FauziAkram
Copy link
Contributor Author

@mstembera So basically just completely removing the parentheses?
If this is what the majority think is better, I can modify the PR to that, even though the initial intention was different.

@mstembera
Copy link
Contributor

Right no parentheses and an easier to read operator precedence by moving the improving multiply before the divide. Just a suggestion though.

@FauziAkram
Copy link
Contributor Author

FauziAkram commented Feb 27, 2024

@mstembera Oh yes! I didn't see the improving placement change. This is perfect also for the mentioned issue! I didn't think of this solution.
I will modify it now, thanks.

bench: 1303971
@Disservin
Copy link
Member

Disservin commented Mar 1, 2024

I find this discussion pretty pointless tbh...

This calculation is just pure multiplication, subtraction and division.
There's nothing crazy going on and the entire scope of the related code is 2 lines... I don't see any value in changing this, given that this will likely be tweaked soon anyway again... and it would open the opportunity for multiple pr's of this kind which just move operators and parentheses around...

@Disservin Disservin closed this Mar 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants