The user should always be attempting to make these add to 100% themselves
So there is an algorithm to attempt to normalize percentages that don't add up to 100%, however there are some things that it can't deal with adequately.
Here's how the math works out for a few examples
Code: Select all
1+1+33+33+33 = 101
Normalise 1's = 1/101 = 0.009 (Rounded up to 1%)
Normalise 33's = 33/101 = 0.326 (Rounded up to 33%)
Adding to 101%
Code: Select all
1+1+50+50+50 = 152
Normalise 1's = 1/152 = 0.006 (rounded up to 1%)
Normalise 50's = 50/152 = 0.328 (rounded up to 33%)
Adding to 101%
What if you made them 2 and 2 instead of 1.
Code: Select all
2+2+33+33+33 = 103
Normalise 2's = 2/103 = 0.019 (rounded up to 2%)
Normalise 33's = 33/103 = 0.320 (rounded down to 32%)
Adds to 100%
What if you made them 1 and 2 instead of 1.
Code: Select all
1+2+33+33+33 = 102
Normalise 1 = 1/102 = 0.009 (rounded up to 1%)
Normalise 2 = 2/102 = 0.019 (rounded up to 2%)
Normalise 33's = 33/102 = 0.323 (rounded down to 32%)
Adds to 99%
So there are use cases where it doesn't work out properly. The solution to this is where the value doesn't add to 100% properly, we add or subtract from the biggest (or if multiple, pick one randomly) class until it adds properly.
Pretty easy solution to implement, i'd like to get PBix's opinion first though to understand the consequences of it not adding to 100 properly. I'm sure he'll stumble across this thread soon enough.
Thanks for reporting the issue!