Performance Enhancing Bug

Jump to navigation Jump to search
Revision as of 8 May 2013 at 22:24.
The highlighted comment was created in this revision.

Performance Enhancing Bug

I started working on a mini-sized GF gun which I plan to have both an anti-RM and anti-WS component. First, I used Raiko's gun as a base, and then I added Bin Smoothing from Vyper. The problem was, I forgot to change the array type from int to double, so the bins couldn't hold decimal values and got rounded down. One would think that this would have a harmful effect, but it actually had a significantly positive effect on my robot's score against surfers. I thought that maybe the smoothing was too heavy, so I tried lower smooth factors, and I even tried getting rid of the smoothing altogether, but I still couldn't replicate the score increase.

Any ideas why this happened? Could it be something about the decay rate instead of the smoothing? Has anyone else ever noticed this?

    Sheldor (talk)19:10, 8 May 2013

    That's very interesting. Since lower smoothing factors didn't replicate the score increase, I believe key difference is most likely the shape of the smoothing rather than the extent of the smoothing. I can think of two changes in the shape of the smoothing that may be caused by integer rounding and may be significant:

    1. Depending on what kind of smoothing you used, the integer rounding may have caused several bins at the center of the hit to be incremented by the same value. It's possible eliminating the bias towards the center of the 'hit' may be of benefit in targeting surfers perhaps. To confirm/refute this hypothesis, you can keep 'double' but modify your smoothing code to keep a 'flat' region around the center of the smoothing.
    2. The integer rounding would reduce the influence far from the 'hit' to zero. It is possible that small influences from excessively distant 'hits' may have a detremental effect, possibly making your targeting more predictable. To confirm/refute this hypothesis, you can keep 'double' but modify your smoothing code have a sharp cutoff for the maximum distance from the 'hit' that it gets smoothed into.
      Rednaxela (talk)20:17, 8 May 2013

      For the sake of easy reference, below is all immediately relevant code. The weight is 4 if this is a wave fired the same tick that an actual bullet was fired, and 1 otherwise. Notice that the actual smoothing is done by raising the difference between the current GF and the visited GF to the power of 0.3. I tried factors of 0.1 and just 0 (effectively the same as not smoothing at all), with little success.

      int gf = GF_ONE;
      try
      {
      	do
      	{
      		waveGuessFactors[gf] *= 0.995;
      		waveGuessFactors[gf] += (weight * Math.pow(0.3, Math.abs(gf - (int)(GF_ZERO + Math.round(Utils.normalRelativeAngle(Math.atan2(enemyLocation.x - firePosition.x, enemyLocation.y - firePosition.y) - absoluteBearing) / bearingDirection)))));
      		gf--;
      	}
      	while (true);
      }
      catch (Exception ex)
      {
      }


      I highly doubt your first hypothesis, because every other GF than the one that was actually visited would be increased by 0. Unless of course, the wave has a weighting of 4, but even before I added weighting, the int arrays performed better.

      Your second hypothesis has the same problem. Any GF other than the visited GF would get rounded down to 0, under normal circumstances.

        Sheldor (talk)23:24, 8 May 2013