User talk:Starrynte/DCLSHResearch

Various Questions

Can't beat Walls?

OK. I temporarily set the CPU constant to 1 second, just to test this. It currently searches through ALL the points and picks the closest one. Yet it can't beat Walls yet. I believe it's one of the following problems:

• GF implemented incorrectly, though I don't think it is this
• DC implemented incorrectly, a possibility
• Cannot just use the closest point (must use multiple ones), this is also a possibility
• Other?

Thoughts? --Starrynte 04:16, 22 September 2009 (UTC)

If Wall fire and you don't move, you won't normally beat it with GF gun, at leat in my development. » Nat Pavasant » 06:54, 22 September 2009 (UTC)

• I never knew that! Thanks for the info! --Starrynte 04:02, 23 September 2009 (UTC)

"Stopping"?

Occasionally, the bot seems to freeze (the radar stops turning but there is still a scan arc, text output from onscannedrobot stops, gun stops, basically as though the robot was stop except for the radar arc). The other bot keeps moving, robocode reports no errors and no skipped turns and no "robot stopped". It always freezes at the start of the round. I have duplicated this a few times. Any reason why? --Starrynte 04:02, 23 September 2009 (UTC)

I've never encountered that. What version of Robocode are you using? And have you tried any others? If it's only in the 1.7.1.4 beta, I'm sure Fnl would appreciate it if you filed a bug report here. --Voidious 13:15, 23 September 2009 (UTC)

Could you please post the code? I don't think it is a bug, for that I was once getting this too. It seems that I've some bug in my radar that time. » Nat Pavasant » 15:17, 23 September 2009 (UTC)

Same thing has happened to me, and in robots so simple that it really shouldn't happen unless there's a bug in the basic radar code--CrazyBassoonist 20:55, 23 September 2009 (UTC)

Only radar code is setTurnRadarRightRadians(Double.POSITIVE_INFINITY) in run() and setTurnRadarRightRadians(Utils.normalRelativeAngle((absBearing=e.getBearingRadians()+getHeadingRadians())-getRadarHeadingRadians())*2d) in onScannedRobot --Starrynte 01:58, 24 September 2009 (UTC)

Do you have:

while(true) {
    turnRadarRightRadians(Double.POSITIVE_INFINITY);
}

-- or --

while(true) {
    if (getRadarTurnRemaining() == 0)
       setTurnRadarRightRadians(Double.POSITIVE_INFINITY);
    // ...
    execute();
}

Or do you just do:

setTurnRadarRightRadians(Double.POSITIVE_INFINITY);
while (true) {
    // ...
    execute();
}

? If you do the last one, than if you are not moving you might sometimes lost the radar lock, which result exactly the same as your. I'm not sure it is Robocode's bug or not. Nat Pavasant 11:16, 24 September 2009 (UTC)

• I have the last one. What doesn't make sense to me is that the scan arc is still there, the radar stopped turning but the arc isn't a line. --Starrynte 01:17, 25 September 2009 (UTC)
  • The scan arc is an illusion. It is not updated, nor does scanning happen (even in a line), if a robot doesn't move in the slightest. Ignore that scan arc artifact. As far as why it stops, it's my understanding that when a collision occurs, it not only clears the movement that's set, but also clears gun/radar turns. Thus you need to reset the gun/radar turn. Every properly working infinity lock I see is done with either the first of the methods Nat listed, or with the second minus the if statement which is unnecessary. It it stopping upon a collision occuring? :) --Rednaxela 02:47, 25 September 2009 (UTC)
  • For now I'm using the first one, the second one the if is necessary, otherwise it doesn't lock --Starrynte 02:53, 25 September 2009 (UTC)
    • Hm, I'm stuck thinking in MegaBot land, where radar processing happens outside of the onScannedRobotEvent event. The 'if' in the second one is not needed IF your radar/scan processing happens between it and execute, which isn't usually the case in small codesize bots. --Rednaxela 03:01, 25 September 2009 (UTC)
      • But in most megabots, radar processing also happens in onScannedRobot(). Normally the first method is use, the second one only use for robots that have some process in main loop too. Nat Pavasant 11:37, 25 September 2009 (UTC)
        • Most megabots eh? I'd say... most non-modular ones maybe. Doing actual processing ouside of the main loop to me seems like a recipe for making the code unclear and tangled up. --Rednaxela 12:34, 25 September 2009 (UTC)
          • But a lot of megabots use onScannedRobot as its main loop in one-on-one. And Dookious, as one of the modular megabots, have only the second method radar code in its main loop! I used to do things in main loop, but once I start to use debugging graphics, I switch to onScannedRobotEvent, or in case of my current development, a CustomEvent with priority of 6.

Dealing with Surfers

I've tried segmenting on gunheat, but it leads to worse performance against non-surfers. No space for a VG array. Any other suggestions? --Starrynte 04:27, 24 September 2009 (UTC)

• Is it unusual for results to vary a lot across seasons? Since for example against CC I get scores ranging from 47 to 65 and against WLO I get 52 to 78 --Starrynte 04:59, 24 September 2009 (UTC)
  • Very normal. In fact even larger variations are things I regularly see. It takes many many many seasons to really get stable results against surfers (100+ seasons I'd say) --Rednaxela 05:09, 24 September 2009 (UTC)

In a MicroBot? My advice would be to ignore the surfers. =) But in general, rapid decay or removal of data is probably the most important thing. This would be low Rolling Averages in a Visit Count Stats system. In Dynamic Clustering (or even the k-means in TripHammer), removing oldest scans works, or weighting scans based on age. --Voidious 13:25, 24 September 2009 (UTC)

• Seems to help. Now to experiment with weighting, which I'm not using yet... --Starrynte 02:43, 25 September 2009 (UTC)

Comparison to segmentation

Your description of translating a data point into a bin reminds me of segmentation and Visit Count Stats. I'm curious - could you give any more details on how this works, and/or how it's different than segmentation? --Voidious 13:15, 23 September 2009 (UTC)

It actually is similar to segmentation, only rather than having say stats[VELOCITY_SEGMENTS][DISTANCE_SEGMENTS][WALL_SEGMENTS][etc...], you'd have just stats[COMBINATION OF VELOCITY, DISTANCE, WALL, ETC]. The combination is the LSH process. --Starrynte 02:03, 24 September 2009 (UTC)

Maybe not a first?

You know... I think that maybe this isn't the first Locality Sensitive Hash targeting in Robocode. Doesn't Locke's description seem to sound like a form of locality sensitive hash targeting? It does say "Along with that Observation, a number of situational parameters are stored. The Log is ordered in such a way that similar Observations will become neighbours." and once looking at the code I noticed it stored things in a 1d list which it tried to order to preserve locality. --Rednaxela 04:29, 24 September 2009 (UTC)