Talk:DrussGT/Version History
Contents
1.3.1 results
Interesting... it appears with 1.3.1 that switching the time segments to the style I've been using, has killed the score significantly, putting it behind Dookious. Maybe I should try DrussGT style time segments some time... --Rednaxela 09:10, 11 December 2008 (UTC)
I was playing with the code quite a bit... maybe it messed something else up. I'll do a revert and just keep the gun changes. In the TCRM it scored a satisfying 90.59 over 100 seasons...--Skilgannon 19:47, 11 December 2008 (UTC)
Hang on... I just looked at the details and it seems I'm getting lots of 0 scores, however only coming from Alcatraz. Also, it seems strange that in some of those battles I get 50% survival, but zero score?! Maybe this would be a good time to try out the revert features offered by the new database backed rumble =) --Skilgannon 04:55, 12 December 2008 (UTC)
Heh, I kind of think this server should still be rejecting 0 scores like the old one did... at least except when it matches the expected score reasonably :) --Rednaxela 08:14, 12 December 2008 (UTC)
Hey, hope 1.3.2 will stay at king! And hope you new AntiSurfer gun will kill Shadow! » Nat | Talk » 00:25, 12 March 2009 (UTC)
Have you realize that 1.3.1b and 1.3.2 took exactly 3 months to development! (and 9 minutes, actually) » Nat | Talk » 13:33, 24 March 2009 (UTC)
1.3.8 results
Just wanted to offer a "wow!" at the 1.3.8 rating. Awesome that you are still finding improvements. Are you trying to just crush any hope anyone has of ever catching up? =) (Just kidding, I reckon I'll make a run eventually, just having fun on something else for now.) --Voidious 15:00, 11 May 2009 (UTC)
Yeah, I decided to apply the very effective DC movement strategy of weighting scans by their inverse distance (eg. Shadow, Wintermute, CunobelinDC) to the gun as well. Seems it worked quite nicely =) And what's more, it's something that any DC gun can VERY quickly implement. --Skilgannon 08:44, 12 May 2009 (UTC)
Ah, cool. And hey, Lukious did that too! =) Actually, he used a 2D kernel density, with one of the factors being distance between the scans, but I think he also weighted by distance to search scan. I'm definitely making a mental note about this for my future DC endeavors. =) --Voidious 13:28, 12 May 2009 (UTC)
You are right it was very easy to implement. I have some versions of that idea now in test =). --zyx 14:33, 12 May 2009 (UTC)
Haha, actually, I don't think I've ever done a DC gun WITHOUT that feature... maybe I'm odd though :) --Rednaxela 15:37, 12 May 2009 (UTC)
It's interesting how well this worked, I had always assumed that the reason it worked so well for movement was because of the very limited data. I thought in a gun getting as much data as possible would be preferable, as there was a good chance some of the factors would just be noise against a large portion of the bots, and while a weighting method based on scan distance could certainly be effective, I thought one that tended towards infinity like the inverse distance one would be too 'harsh'. Seems I was wrong =) --Skilgannon 18:11, 12 May 2009 (UTC)
1.3.10
Re: kd-tree speed, how many dimensions do you have now? In testing my own kd-trees, IIRC it took something like half the match before the kd-tree was as fast as brute force with ~6 dimensions. Maybe my memory's off, but it took a while, and more dimensions takes longer. If you have a lot more, I wouldn't be surprised if it's slower than brute force over 35 rounds. My Diamond/Code#KdBucketTree.java has a runDiagnostics2 method that might be helpful to you in diagnosing the relative speeds of kd-tree vs brute force. The runDiagnostics2 is the more up-to-date method, you can just adjust the number of scans and number of dimensions (the array of random numbers) you put into the tree (though it could be coded more clearly), and you could just delete the comparison to my vanilla kd-tree. Good luck. =) --Voidious 13:47, 10 August 2009 (UTC)
Cool. I'll take a look at that. I'm running 11 dimensions, so... =) Maybe have a wrapper that uses brute force for the first N scans, and from then on uses the tree? Also your test uses perfectly distributed random numbers, so in real life the tree is penalised even further. --Skilgannon 14:01, 10 August 2009 (UTC)
- Oh yeah, and bigger cluster size favors brute force, too... Kd-tree might blow away brute force for one nearest neighbor, but 50 nearest is a lot different. --Voidious 14:14, 10 August 2009 (UTC)
Hmm... I'm tempted to make a N-Nearest-Neighbour Challenge to compare various KD-tree implementations as well as brute force, at different numbers of dimensions and so-called 'cluster sizes'... :) --Rednaxela 14:38, 10 August 2009 (UTC)
- Go for it! I think k-Nearest Neighbour Challenge or KNN Challenge (I can accept the British / Canadian spelling :-P) would be a closer fit to the usual naming of this problem, like wikipedia:k-nearest neighbor algorithm. For 25,000 data points, cluster size 50, 10+ dimensions, my money's on my brute force algorithm. =) --Voidious 15:01, 10 August 2009 (UTC)
- I was just re-reading the wikipedia:k-nearest neighbor algorithm page and I followed the link to wikipedia:Statistical classification, where I noticed something called wikipedia:Boosting, which looks to be about the same idea as Crowd Targeting. My attempts at trying to dynamically weight DrussGT's movement buffers in the past have been, generally, failures, but maybe the algorithms they provide as examples will be a bit more successful =) --Skilgannon 15:50, 10 August 2009 (UTC)
- Hmm very interesting... It does appear to be like Crowd Targeting as it's often interpreted. I may be mistaken, but those methods don't appear to handle the case where something should be given negative weighting though, which is a key aspect in SaphireEdge's "crowd" model. --Rednaxela 16:20, 10 August 2009 (UTC)
- Yes, in a gun case I can see how you might need to weight a certain gun negatively if, for instance, it is being actively dodged by a surfer. In a movement case, however, where we are just talking about weighting different sets of VCS buffers more or less depending on how much they correspond with enemy targeting. I think it could be proved that by simply segmenting data it is impossible to make your targeting worse, only better, so only positive (and possibly 0) weights are necessary. Interestingly, I think this also makes having multiple segmented data buffers a form of Probably approximately correct learning. I need to find out more about boosting =) --Skilgannon 14:21, 30 August 2009 (UTC)
- We talked about "boosting" in the Machine Learning class I took in college. The only thing I remember about it is that the team with the best classification score on the final project used it. =) --Voidious 17:02, 10 August 2009 (UTC)
- Hmm very interesting... It does appear to be like Crowd Targeting as it's often interpreted. I may be mistaken, but those methods don't appear to handle the case where something should be given negative weighting though, which is a key aspect in SaphireEdge's "crowd" model. --Rednaxela 16:20, 10 August 2009 (UTC)
- I was just re-reading the wikipedia:k-nearest neighbor algorithm page and I followed the link to wikipedia:Statistical classification, where I noticed something called wikipedia:Boosting, which looks to be about the same idea as Crowd Targeting. My attempts at trying to dynamically weight DrussGT's movement buffers in the past have been, generally, failures, but maybe the algorithms they provide as examples will be a bit more successful =) --Skilgannon 15:50, 10 August 2009 (UTC)
1.5.0
No changes for this version except move the movement code to DrussMoveGT? And where is 1.4? » Nat | Talk » 14:43, 6 September 2009 (UTC)
- 1.4 was down near 1.3.10, but I ditched that line due to it being a complete flop. 1.5.0, yes, it was just moving it out to a separate class, and also move all the gun references out of the movement code into a new class file. I also ditched 1.5.0 due to a tiny little bug that I was unable to find, but which cost me about 0.2APS --Skilgannon 06:12, 18 January 2010 (UTC)
- On your latest update to help mirror bots - I had noticed your weakness here and wondered how you were going to address this. What's your idea on this? --Miked0801 20:43, 17 January 2010 (UTC)
- Also, to let you know, I got a few NULL Ptr exceptions when running your bot vs. deith.Czolgzilla 0.11 - 3 in 35 rounds. There may be something amiss in your code.
Wow - I thought I killed all those NPEs - thanks for the heads up! The basic idea with this update is taking advantage of something goto-surfing gives me over true surfing - I know where my final destination is before actually reaching it. What I do is take the midpoint between me and the other bot and imagine it stays constant. Then I imagine that the other bot is mirroring my future predicted best location (I take the furthest forward prediction available from the movement) and check what the offset I would need to shoot at would be to hit my mirrored location. That offset is the value I use to cluster on. The idea I'm hoping for is that all bots tend to rotate around an imaginary point as they surf (or random move), and they also tend to be at the opposite side of the circle than I'm on in order to keep a decent distance, so their movements may tend to be slightly mirror-ish, and if I can tell my gun the point on the circle I'm going to be, it has a definite advantage trying to figure out which part of the circle they'll rotate to. Hope this makes sense =) --Skilgannon 06:12, 18 January 2010 (UTC)
