Robot code that does not behave as intended, but when fixed results in
inferior performance. Share your examples!
Quote from the Shadow page: Thanks, but I had to revert almost everything to 3.66 level. I found a huge bug in my recent attempt at "dynamic dimension weighting" that wasn't working as expected. Turns out that correcting that bug costs me at least 30 ranking points... talk about PerformanceEnhancingBugs?! -- ABC
Two examples from Dookious (both before the full rewrite):
- Until 0.945, Dooki's WaveSurfing surfed waves until they passed his rear edge, but my Wave detection was off by 1 tick (though they lined up visually in graphical debugging). A bug in a new bot-width calculation (in 0.93) ended up calculating the bot width as almost 0 a lot of the time, which, I think, roughly compensated for the waves being off by 1 tick, and the rating went up. In the end, I fixed the off-by-1, fixed the bot-width calculation, and made the movement surf a wave until it was passed the center instead of the rear edge.
- Dookious 1.16 broke the 2100 barrier. At the time, I thought it was primarily because of the precise GF1/-1 calculations, which I do still think was a factor (as TC2K6 score went up a full point). During the full rewrite, I realized that a certain special case in my movement actually decreased performance; I then realized that special case was broken in the old code somewhere along the way; after checking, my suspicions were confirmed that the precise GF1 calculation is what had broken that. I'm pretty sure that was also a factor in the 8 point jump past 2100.
-- Voidious