User talk:Starrynte/DCLSHResearch

Ugh...right when I think I get the gun working, I realize that I haven't done anything at all since I was fighting the battle with the wrong bot :( --Starrynte 02:56, 22 September 2009 (UTC)

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)

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)

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)