WritingFastCode/WallDistance

Since the battle field height and width do not change, save them to class variables in the beginning of the battle to avoid unnecessary calls to getBattleFieldHeight?() and getBattleFieldWidth?(). Although the code in those methods is small, the overhead of a method invocation is high relative to using class variables.

This is the fastest code I've found:

//Add these variables to your class
double battleFieldHeight, battleFieldWidth, centerX, centerY;

//Run this at the beginning of the round:
battleFieldWidth = getBattleFieldWidth();
battleFieldHeight = getBattleFieldHeight();
centerX = battleFieldWidth / 2.0;
centerY = battleFieldHeight / 2.0;

//Use this method for every call
public double getWallDistance(double x, double y){
   if(x > centerX){
      if(y > centerY) return Math.min(battleFieldHeight - y, battleFieldWidth - x);
      return Math.min(y, battleFieldWidth - x);
   }
   if(y > centerY) return Math.min(battleFieldHeight - y, x);
   return Math.min(y, x);
}

My previous method was:

public double getWallDistance(double x, double y){
   return Math.min(Math.min(x, getBattleFieldWidth()  - x),
                   Math.min(y, getBattleFieldHeight() - y));
}

The top method is faster because it uses 1 method invocation instead of 3. Method invocations take much more time then comparing two numbers, so going from 3 invocations to 1 invocation and 2 comparisons is much faster.

I rewrote it when I noticed that getWallDistance() was responsible for over 16% of my bot's CPU time. (!)

--David Alves

---

Chat

How many times per turn were you calling it? -- Wolfman

16% of CPU time doesn't necessarily mean that during each tick 16% of the time is spent on getWallDistance() calls. For example, some patternmatching bots do not run their patternmatchers unless the GunHeat nears zero (no use in doing any predictions if you can't fire anyway). Checking for walldistances, on the other hand, may be useful to do every tick. This might increase the relative time spent in getWallDistance(). (Or David's bot is really, really simple ;-p.) Anyway, I am just guessing... --Dummy

When do you need to know distance to closest wall? -- CuriousGeorge

@Wolfman: Depending on the state of the battlefield, anywhere from 50 to 700+ (theoretical worst-case scenario) times per turn. @CuriousGeorge: In my WallSmoothing code. By the way, if you're interested in speeding up CC, it spends about 50% of its CPU time on WallSmoothing. I've found that you can do much less accurate WallSmoothing without it affecting your bot's score. Just use a larger angle in your while(!battlefield.contains(...)) code. --David Alves

Yes, WallSmoothing is the major thing CC keeps doing. Larger angle.. You mean larger increments? -- PEZ

I'm Curious... why do you need to call getWallDistance more than once each turn? I mean.. it's not likely that your bot has moved during the same turn. --Dummy

When WaveSurfing you need to check each futue tick in respect to the currently surfed wave. -- PEZ

Ah, I see...Well, if it's speed you want, you could build a lookup table for each position. Uses a lot of memory, but it should be a lot faster ;-) --Dummy

CC .48 should spend significally less time in WallSmoothing now. At least in near wall situations. It didn't affect its score, just as David suggested. -- Thanks David!! PEZ