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
alg:ChooseX consider changing handling of 0 weight entries #179
Comments
I think we can call it a bug if an element with input weight 0 is ever chosen-- we can write some simple tests and add some kind of filtering logic. |
I can't replicate this based on the description; @Implausiblyfun Mind writing a failing test? I wrote this, which passed
|
Looking again, I think the bug was the calling code using |
Sorry about that should have followed up earlier. I had encountered this on Dashking and I think I mis-described the issue. |
Oak should consider either creating a new set of functions for either choosing or stwheap itself to deal with 0 weights.
Problem: When attempting to perform UniqueChooseX from a weighted list and any entry is 0 weight it should never be selected. Today when converting from base weights to cumulative weights we end up with the state where the 0 value entry will be selected whenever the entry after it would be selected. This is annoying when tuning games if you do not want to remove 0 entries.
Decision point 1: Is this a bug and therefore ok to change without a major version change? Or do we need a new set or subset of methods.
Current thought is to have stwheap ignore/immediately pop 0 valuers and or in cumulative values function.
This may also be good time to revist the alg choosing and get better verifications and testing.
The text was updated successfully, but these errors were encountered: