Difference between revisions of "Performance Enhancing Bug"

From Robowiki
Jump to navigation Jump to search
(quick write-up for this term)
 
 
(3 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 
{{stub}}
 
{{stub}}
 +
 +
<blockquote style="background: #ddd; border-left: 5px solid #060; padding-left: 0.8em; padding-top: 2px; padding-bottom: 2px; font-style: italic">
 +
'''Quote from {{OldWiki|Shadow}} page'''<br />
 +
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
 +
</blockquote>
  
 
A particularly nasty type of bug that can be very difficult to deal with. The buggy code is not working as intended, but once the bug is "fixed", performance (usually [[RoboRumble]] rating) actually decreases.
 
A particularly nasty type of bug that can be very difficult to deal with. The buggy code is not working as intended, but once the bug is "fixed", performance (usually [[RoboRumble]] rating) actually decreases.
Line 5: Line 10:
 
There are a few possible ways to deal with this bug:
 
There are a few possible ways to deal with this bug:
  
* '''Leave it in.''' This is the best performing solution in the short-term. However, it may become an obstacle to future improvements. The behavior caused by the bug may be erratic and unpredictable, making it difficult or impossible to tune other behaviors around.
+
* '''Leave it in.''' This is the best performing solution in the short-term. However, it may become an obstacle to future improvements. The behavior caused by the bug may be erratic and unpredictable, making it difficult or impossible to tune other behaviors around the buggy behavior.
* '''Fix the bug anyway.''' You may prefer to just accept the lower performance of your bot if it mean it is "bug-free".
+
* '''Fix the bug anyway.''' You may prefer to just accept the lower performance of your bot if it means it is "bug-free".
* '''Analyze the bug, fix it, and re-tune.''' The best possible scenario is that you are able to analyze what effect the bug is having, figure out why that causes increase performance, and re-implement a similar behavior in a bug-fixed version. This can be difficult and sometimes is not possible at all, but it is the win-win solution one should try to achieve.
+
* '''Analyze the bug, fix it, and re-tune.''' The best possible scenario is that you are able to analyze what effect the bug is having, figure out why that causes increased performance, and implement a similar behavior in a bug-fixed version. This can be difficult and sometimes is not possible at all, but it is the win-win solution to strive for.
 +
 
 +
== Examples ==
 +
* For [[Pattern Matching|pattern matcher]] [[:Category:NanoBots|NanoBots]], the <code>setAdjustGunForRobotTurn(true)</code> that is usually added to make targeting more accurate is a nice example of this bug. Without that, the robot will get more score. Usually for this bug, Robocoders will "Leave it in" since NanoBots can't fit more complex code that would emulate this effect.
 +
* Recently (late May, 2009), [[Diamond]] 1.111 showed a .4% APS improvement over 1.11 by restoring a bug involving a random direction change timer. This example use a "Analyze the bug, fix it, and re-tune" solution.
  
 
[[Category:Terminology]]
 
[[Category:Terminology]]

Latest revision as of 13:49, 27 May 2009

This article is a stub. You can help RoboWiki by expanding it.

Quote from 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

A particularly nasty type of bug that can be very difficult to deal with. The buggy code is not working as intended, but once the bug is "fixed", performance (usually RoboRumble rating) actually decreases.

There are a few possible ways to deal with this bug:

  • Leave it in. This is the best performing solution in the short-term. However, it may become an obstacle to future improvements. The behavior caused by the bug may be erratic and unpredictable, making it difficult or impossible to tune other behaviors around the buggy behavior.
  • Fix the bug anyway. You may prefer to just accept the lower performance of your bot if it means it is "bug-free".
  • Analyze the bug, fix it, and re-tune. The best possible scenario is that you are able to analyze what effect the bug is having, figure out why that causes increased performance, and implement a similar behavior in a bug-fixed version. This can be difficult and sometimes is not possible at all, but it is the win-win solution to strive for.

Examples

  • For pattern matcher NanoBots, the setAdjustGunForRobotTurn(true) that is usually added to make targeting more accurate is a nice example of this bug. Without that, the robot will get more score. Usually for this bug, Robocoders will "Leave it in" since NanoBots can't fit more complex code that would emulate this effect.
  • Recently (late May, 2009), Diamond 1.111 showed a .4% APS improvement over 1.11 by restoring a bug involving a random direction change timer. This example use a "Analyze the bug, fix it, and re-tune" solution.