This was an interesting one. It's fixed now and won't be an issue going forward. I'm deeming it infeasible to go back and re-rank/re-award past tournaments with the fix though. As usual, read on for the gory details if you're interested.
The tournament code uses PHP's usort function to do the custom sorting logic that ranks bots first by wins, then if necessary by average remaining HP, then if necessary (this should almost never happen) by bot id. This involves providing a standard comparison function that can compare two objects and say whether one should be ordered before, after, or the same as another object. Specifically, this comparison function should return an integer less than, equal to, or greater than zero depending on the ordering relationship between the two objects (many programming languages have libraries that use this convention).
Now here's where the gotcha/bug comes in. If you read the docs linked above closely, you'll notice it cautions against returning non-integer values from the comparison function. A common setup for these kinds of functions, when you have a tiered setup where you want to order by A, then by B if needed, then by C if needed, and so on, is to see if the "A" of each object is the same, and if not, to return the difference (swapping the order as needed to control whether higher means before or after). This works great for integer fields like "wins", but not so great for non-integer fields like "average HP remaining". It turns out the value in that case will get cast to an integer.
Here's where the bug really comes in (I guess I lied earlier). :) For pairs of bots that had an average remaining HP less than 1%, the absolute value of the difference came out to some value less than 1. Because of how most programming languages cast floating point numbers to integers, this always get changed to 0. Recall that the comparison function returning 0 means it's saying the objects are equal. So what this means is that for certain pairs of bots, the order is effectively undefined; it might come out correct, but it might not.
This affected the tournament result that Myriad pointed out. The effect is even more pronounced if you look at the middle of the pack in a large category like category 10. There are a number of bots with 27 wins that all had an average remaining HP percent of around 12-14%. Their ordering is effectively random.
Anyway, I hope at least one person found this unexpectedly long explanation informative and/or interesting. It's a bit surprising that a bug with such an obviously wrong result went unnoticed for this long, but it feels good to squash nonetheless. Thanks for reporting this, Myriad.
2
