Talk:DrussGT/Version History

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)

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)

1.6.7

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)

About the NPEs, I just saw a bunch against cx.micro.Spark 0.6. 12 in 35 rounds if that helps. Interesting idea for the anti-mirror stuff by the way. How big a factor is it if your surfing data changes after firing at such a point? --Rednaxela 07:23, 18 January 2010 (UTC)

Thanks - think I've killed them all now. If anybody spots any more please let me know! So far it's a very rudimentary version - if I had enough coding time and processing power I would

• predict forward until the next enemy wave should be fired
• predict all my movements forward until my wave (fired now) hits my mirrored surfing position
• use the offset of that for aiming
• then keep track of the scan and when adding scans use what movement I actually make, and not what I'm predicted to make (which is only truly 100% accurate up to the end of this wave anyways).

But first I want to see if there's any merit to the idea. So I haven't done any of the extra predicting forward, or keeping track of scans to make the data absolutely correct, or anything. All I have right now is using the furthest wave's safest reachable point (by following the best point on the closer waves) and then taking it's offset and multiplying it by the GF direction. If it doesn't hurt my score (in this state) I'll consider it a terrific success =) --Skilgannon 17:14, 18 January 2010 (UTC)

If you add 3 bots to the rumble, you should at least leave your client running to help with the calculating ;) --Miked0801 15:47, 27 January 2010 (UTC)

Yeah sorry about that... my client died from what looks like a corrupted HDD and I didn't have time to fix it then. I think I've fixed it by re-installing the JRE but I'm going to need to keep an eye on the HDD from now on... --Skilgannon 09:18, 29 January 2010 (UTC)

By the way, it's impressive how that improved DrussGT's performance against PolishedRuby. What's interesting though, is for some reason Toorkild gets a better score though... much better. Even more so than Axe's bots with anti-mirror movement. You may want to look into what happens in Toorkild vs PolishedRuby to find more opportunity perhaps. :) --Rednaxela 17:55, 29 January 2010 (UTC)

1.6.10 bughunting

Hey guys, so far (from my own machine) I have picked up NPEs at jk.mega.DrussGT.getBestPoint(DrussGT.java:1194) and at jk.mega.DrussGT.doSurfing(DrussGT.java:1616). If you spot any others please tell me =) --Skilgannon 09:44, 4 February 2010 (UTC)

Sorry for the late response. Hit the getBestPoint once here, against strider.Festis 1.2.1:

java.lang.NullPointerException
        at jk.mega.DrussGT.getBestPoint(DrussGT.java:1194)
        at jk.mega.DrussGT.doSurfing(DrussGT.java:1615)
        at jk.mega.DrussGT.onScannedRobot(DrussGT.java:207)
        at robocode.peer.robot.EventManager.onScannedRobot(Unknown Source)
        at robocode.peer.robot.EventManager.dispatchEvent(Unknown Source)
        at robocode.peer.robot.EventManager.processEvents(Unknown Source)
        at robocode.peer.RobotPeer.execute(Unknown Source)
        at robocode.peer.proxies.BasicRobotProxy.execute(Unknown Source)
        at robocode.AdvancedRobot.execute(Unknown Source)
        at jk.mega.DrussGT.run(DrussGT.java:143)
        at robocode.peer.RobotPeer.run(Unknown Source)
        at java.lang.Thread.run(Thread.java:619)

--Voidious 20:48, 5 February 2010 (UTC)

From 1.6.12 against toorkild 0.2.4b

=========================
Round 35 of 35
=========================
My hitrate: 0.13681592039800994
DC gun score: 174
PM gun score: 169
AS gun score: 170
gun: DC
Enemy damage: 963.2852093419626
My damage:    1421.6659683513403
Accumulated, weighted enemy hitrate % : 8.65954079741584
Flattener enabled: false
SYSTEM: Bonus for killing jk.micro.Toorkild 0.2.4b: 12
SYSTEM: jk.mega.DrussGT 1.6.12 wins the round.
Enemy damage: 984.3913840978221
My damage:    1481.6623683513399
Accumulated, weighted enemy hitrate % : 8.653287918748319
Thou rank tickle-brained bladder!
ERROR: DETECTED BULLET ON NONEXISTANT WAVE!

In the debug window it said error so I thought you might want to know... --Miked0801 07:23, 17 February 2010 (UTC)

1.6.15

Congrats on the perfect PL record with this version. =) Credit to your changes, or just lucky? --Voidious 15:38, 9 March 2010 (UTC)

A bit of both I think. More a lack of bad luck, possibly. The only changes were made to the main gun, the anti-surfer needs a bit of work now I think =) Interestingly enough, the APS actually went down a little. Time is currently the limiting factor... --Skilgannon 20:04, 9 March 2010 (UTC)

Congrats on your achievement. I just looked at your gun code and there are some parts of it I'm not sure whether I just couldn't understand, or if there is actually a problem there. For instance, why do you have accel slices as -.5, .5 when accel only takes the values 0, 1, 2? Also, in the getOffset method, if the index height is 1 over the scan distance and you only use the index with largest height, why don't you just search for 1 nearest neighbor (supposely the one with smallest distance, and therefore biggest height)? --Navajo 22:27, 9 March 2010 (UTC)

Thanks =) Wow, yes, that -0.5 0.5 thing is definitely a mistake, thanks for catching that. It might even be why my anti-surfer attempts have seemed to be hitting a brick wall. As for the 1/distance issue, this is on purpose. For instance, if I had 1 scan that was a distance of 2, but 3 scans that were a distance of 3, and the 1 scan showed one angle is the best but the other 3 all agree on a different angle, it will fire at the 3 instead (which is probably a better place to fire). Notice that I have an option whether it uses this inverse weighting or not. I found that against some bots using the inverse helped (generally weaker bots with more predictable movement) but against others it was better to weight all the scans the same (generally the wave-surfing bots). Anyways, thanks for catching my bug with the acceleration in the anti-surfer gun, I think I'll be working on that now =) --Skilgannon 12:25, 10 March 2010 (UTC)

1.8.1

Hey interesting. I use quite a few in my movement (though I might as well use linked lists at that size). A couple thoughts I have about the multiple buffers/trees thing:

• I wonder if our attitude that multiple trees might be good is a misguided attempt to translate things from the VCS world to the DC world. And maybe if we freed our minds we'd think of something better.
• Lots of buffers works well in movement, but I'm not convinced it's really because of any "crowd wisdom". I've long suspected it's just a matter of constructing your danger values such that the safest spot is mostly the same, while the rest of the spots are randomized enough to make your movement unpredictable. If this is the case, it makes me think it won't do much for you in a gun.

The proof is in the pudding, though, so I'm very curious to see how this goes. =)

--Voidious 22:16, 14 April 2010 (UTC)

Indeed interest. Actually, that first point Voidious makes, is something I've hard on my mind for a while before. See, I've found that a single VCS buffer which is anti-aliased and interpolated reduces aliasing error as much as possible. It performed similarly to a while bunch of traditional VCS buffers. For this reason, I've come to the conclusion that the advantage of lots of VCS buffers is not due to "crowd wisdom", but due to the simple fact that lots of differently segmented buffers will average out the aliasing error to a degree, fixing the problem. Because k-nearest neighbors, anti-aliased VCS, and VCS "crowd" all show the same league of performance, I suspect that simply crowding trees may not help so much in the same way that lots of VCS buffers helps, at least not to the same extent. I think a "crowd" of trees could have some gains perhaps, however unlike the case of VCS, it isn't mending any aliasing error which I think is the biggest issue with a single VCS buffer. --Rednaxela 00:05, 15 April 2010 (UTC)

I've tried this on Gibbs several times and as Voidious said, it works well on movement, but I still haven't seem significant improvements using this to aim. I did however achieved good results combining trees with the same dimension but different size limits, mixing different cluster sizes, kernels and scan weighting. --Navajo 00:23, 15 April 2010 (UTC)

My thoughts are exactly the same, adding lots of buffers really does make the equivalent of a properly aliased, interpolated buffer, and since trees are already perfectly aliased (or rather, the data is never put into discrete bins) this shouldn't actually help. However, the reason I'm giving it a try is because all other attempts at dynamic weighting for guns seem to have failed, and I think this setup is perfect for some sort of Boosting. The fact that it lost around 0.5APS really doesn't surprise me, as I currently do not have any sane default weights, ie. all dimensions are weighted equally. I'll probably end up setting up all the possible combinations of buffers, running local tests, and then selecting the top 20 for anti random movement and the top 10 for antisurfer, or something like that. --Skilgannon 05:23, 15 April 2010 (UTC)

I'm still fairly ignorant of boosting, but I'm curious. Why "dumb down" your trees into weaker classifiers before trying to recombine them into a strong classifier? For instance, why not include your 11 dimension tree as part of your set? And are you using some type of boosting algorithm, or just doing KNN on all 4 trees and using the combined set as your cluster? (Which I'm not sure is "boosting", but maybe it is.) --Voidious 13:52, 15 April 2010 (UTC)

Boosting (as I understand it) is basically an algorithm which combines a whole bunch of 'weak' classifiers into one strong classifier by weighting them in some way. It doesn't matter how weak the learners are, if they have a hit rate > 50% then as long as there are enough of them, each saying something different, you can make an arbitrarily strong classifier. I'm actually currently setting up the framework so that I can have all ~2000 combinations of 11 attributes (from 1 dimension right through to 11) and run a testbed against them for a few seasons. Then I'll see which ones have the highest hit ratios and manually select those to include in the rumble release. --Skilgannon 14:51, 16 April 2010 (UTC)

My thought is, perhaps rather than just select the ones with the highest hit ratios, perhaps consider something such as "hit ratio to required cpu time" ratio maybe? After all, the strongest ones may use more dimensions and thus be the slowest, so maybe it would make sense to bias against slow ones to an extent. --Rednaxela 15:18, 16 April 2010 (UTC)

On second thought, simply dividing by cpu time doesn't make sense. One wants something more like "marginal gain of adding this classifier, versus it's required cpu time", and doing it that way would make it depend on the order the classifiers... The only way to ensure an optimal group, is to test ALL possible combinations that fall within a certain CPU limit, and to evaluate that effectively one needs to either have one's weighting or weighting algorithm already decided. --Rednaxela 15:24, 16 April 2010 (UTC)

Yeah, just picking the strongest and using them is not necessarily the best combination. If two have 99% mutual information, you're not gaining much by adding the second one, and you're doubling the weight of that 99% in your whole. Oh, and if any of them have a hit rate of > 50%, you'll be *really* kicking butt. ;) --Voidious 15:30, 16 April 2010 (UTC)

Actually a hit rate > 50% is required only when using boosting on an ensemble of 2 class classifiers. For multi-class boosting all you need for each classifier is a success rate better than random guessing. --Navajo 17:20, 16 April 2010 (UTC)

I know, I was just poking fun. =) --Voidious 18:42, 16 April 2010 (UTC)

1.8.7

Two comments:

• Heh... I was gonna ask about the BulletHitBullet thing, but I came to understand it while writing my comment. =) Interesting insight there.
• The gun turn thing is something I've played with. Right now, I calculate the angle I'd aim with if I were aiming this tick (firing next tick), and check if the gun is already within a bot width of that. Frankly, it's technically wrong. Sadly, trying to fix this showed the same or worse performance, so I ignored it and moved on... Maybe I'll try again, as that was a while ago.

Looks like you've gained yourself a small buffer at #1 (Diamond 1.5.17 and DrussGT 1.8.0 were like dead even), which might be all you need since I'm becoming a StarCraft 2 addict. =) But I'm actually quite satisfied with Diamond right now, despite the strong possibility of losing the Melee crown while failing to take the 1v1 crown...

--Voidious 00:38, 17 May 2010 (UTC)

Yeah, I have some serious doubts as to how correct all our GF stuff actually is. I think I've solved my 1-off 'performance enhancing bug' in the gun, it was actually right previously, as the bullets are moved before the robot. So technically, in the painting, the bullet should be on the trailing line of the wave, not the leading. Take a look at the DrussGT painting if you're confused. 1.8.8 released, which reverts putting the bullet on the leading line, but still keeps the VG changes (including putting the VG on the right tick). If this works I'm going to have a try at precise min/max GFs again. --Skilgannon 09:25, 17 May 2010 (UTC)

From what I remember, DrussGT does its gun in onScannedRobot, isn't it? If so, isn't the Paint did after onScannedRobotEvent() ? --Nat Pavasant 13:37, 17 May 2010 (UTC)

Yes, but the screen is painted, then the bullets' location are updated, then the collisions are checked, then the robots' locations are updated. So the wave should precede the bullet by one velocity at the time of painting, because it is updated before the enemy moves. --Skilgannon 15:13, 17 May 2010 (UTC)

Yes, but... onScannedRobot(), then onPaint(), then process until execute(), then timer tick, then screen painted, then update bullet/robot... I have experiment with this a while ago, with both debug paint and debug print. If you update wave in onScannedRobot, it should line up with bullet exactly. If you do that in run(), it should be trailing the wave, isn't it? --Nat Pavasant 03:04, 18 May 2010 (UTC)

Yes, that's correct for at the time of painting. However, the important thing to note is that the bullets are moved again before collisions are checked, and before the robots are moved. As such, although at the time of painting the waves should be at the same place as the bullet, what is actually important is that at the time of collision the wave should be at the same point as the bullet. Since we can't update the position of the wave while the robocode internals are working, we need up update it before. If you look at the latest DrussGT painting it should be clear: the rear wave is where the bullet is at the time of painting, and the forward wave is where the bullet will be when the collisions are checked. We then do our precise intersection based on these 2 waves. --Skilgannon 08:13, 18 May 2010 (UTC)

Just writing that down... thx -Jlm0924 21:35, 17 May 2010 (UTC)

I might agree, but what do you mean by "all our GF stuff"? I think our guns are pretty darn accurate, tho I never rule out another leap. I have serious doubts our surfing stats are working exactly how we think they are against any type of learning gun. Hard to describe exactly... But I've tried a ton of stuff with surf stats that I really feel should help yet fails miserably. --Voidious 13:21, 17 May 2010 (UTC)

I guess I just have a general grudge against statistics, which is the general context that GFs are used in =) Anything which can't give me a definite answer has an extra layer of error in interpreting exactly what the data means. I don't think there is anything which anybody can agree on when it comes to surfing stats - I mean, Shadow doesn't even age his data. I find that ridiculous. I've been thinking of converting DrussGT to using arrays of raw GFs rather than arrays of bins, and from there possibly even convert to DC. But even if I manage the conversion without any bugs, it will be a daunting task trying to get everything tuned like it was =) I've been doing some experimentation with using a gaussian kernel density for the gun, but it seems to make my gun useless against surfers while not really helping the anti-RM side of things. I may release a version anyways, just for kicks. Currently DrussGT uses a 'uniform' kernel, just testing raw overlap of GF ranges.--Skilgannon 15:13, 17 May 2010 (UTC)

Personally, I think GFs are a pretty ingenious way of analyzing enemy movement. =) Can you give an example of what would give you a "definite answer" and no "extra layer of error"?

As for surf stats, yeah, they're all over the place. I'm definitely at a point where "Wave Surfing" is an insufficient description of a movement. But for example, the general perception is that we are learning the dangerous firing angles and avoiding them. This is undoubtedly true, but I'm not sure that more accurate projection of dangerous firing angles is what separates a good surfer from a great one. If the enemy gun is still learning, it's also critical to tune how/when you visit the non-dangerous (from your surf stats' perspective) firing angles. Yet nobody does this explicitly besides flatteners against really high hit rates. And perhaps you should never have a firing angle seem too safe, since you might dive too close to get to it. If I add a super lightweight flattener, to flatten among the safe angles while still dodging the dangerous ones, it does nothing for me. I just know I am missing something.

--Voidious 20:49, 17 May 2010 (UTC)

Continued at Talk:Wave_Surfing#The_Next_Level....

1.8.14

Hmm... bulletpower... this reminds me, I really should take the "optimal bulletpower calculator" from midboss, remove the speed optimizations that forced (very large) approximation, and use it to create a fixed table of ideal bulletpower values (given certain assumptions)... I wonder how the calculated table would compare to the results of tweaks like this. Sorry if this seems offtopic, but was just reminded of my dream of making bulletpower selection less a matter of guesswork ;) --Rednaxela 19:36, 17 June 2010 (UTC)

1.9.0

I think 1.8.16 is your best version, and I see that the only difference between 1.8.16 and 1.9.0b is changes to the PM gun. It's a 0.22 APS difference. Do you really get that many points from your PM gun, or is this just luck/variance? Or do you think you broke something else in 1.9.0? --Voidious 14:59, 24 January 2011 (UTC)

My new PM gun is a bit slower, so I'm guessing the points difference is due to skipped turns. Looking at a details of the diff, it seems that apart from a few outliers like Cigaret, Powerhouse and Engineer, it's just a bit of a gradual drift. I was also surprised, and I looked for what I might have broken, so I reverted to 1.8.16 and just made the changes I was trying for 1.9.0b. Didn't really make any difference in score. Maybe I'll re-release 1.8.16 to see if there is any difference this time around... --Skilgannon 11:46, 25 January 2011 (UTC)

1.9.1

Wow, +0.5 APS at 500+ pairings - is that gonna hold? Almost exciting enough for me to halt my WaveSim work to run a client here. I've been waiting for you to drop a big update and put #1 just out of reach again... =) --Voidious 21:20, 4 March 2011 (UTC)

It's ended up at about +0.35APS which is statistically significant but not enormous. This was actually just meant to be a tweak before I do precise GFs in my gun... while I'm here though I might try one more idea i had for weighting, though I predict it will make things worse. I haven't had internet at my new apartment so can't contribute to rumble cycles, so sorry if its taking a while =-p --Skilgannon 10:52, 5 March 2011 (UTC)

I didn't understand what Imperfect Perfection is. I couldn't find it anywhere. What is it?

This was a reference to old rumble servers, which would throw away 100% scores in case one of the bots had crashed. So the idea was that if you had 100% at the end of a battle you should allow the opponent one small bullet hit so that you actually get a valid score. See the old wiki page.

Which one is better Edit:found out that 3.1.3DC uses GoTo surfing

Both 3.13 and 3.13DC use GoTo surfing. 3.13DC uses DC, while 3.13 uses some form of VCS. (Correct me if I am wrong)

Correct :-) In the movement, to be more specific.

And considering I write a changelog, I don't see how this question is anything other than lazy at its worst.

I was always wondering why the best bot used VCS, DC seems much more elegant. Does it improve performance in your tests?

For some reason I've never managed to get the DC to perform as well as the VCS, so it still used VCS. I remember Jdev commenting that a range search worked better for him than a KNN search in movement, so I'll be trying that next.

Have you tried doing something similar to your many randomized attribute buffers with kD-Trees? You could make 100 trees, each with a random subset of the predictors, then combine the results. You could even start weighting some tree's results higher if they perform better.

DC is more versatile than VCS. There is more room for improvement, but also more room to screw up. And WaveSim doesn't work with movement.

It is harder to unlock all the potential from DC in movement.

Cool, been trying to find a good reason to do this myself. =)

The predicted distance to enemy is a good use for it, but besides that, every thing I prototype that might make use of this ends up failing pretty hard, and/or being really slow by killing my second wave surf danger cutoff optimization. Which isn't a deal breaker if it gave serious APS gains, but is pretty close to it, and makes it much more painful to test. I recently made another serious pass at "factor in danger of firing situations presented to the enemy" that fell into this category.

My thoughts were that my future wave surfing might actually be failing because I didn't have this feature yet. I'm going to try using the predicted enemy locations for the fire location of the future waves, since that is the one big inaccuracy that is still left in the future wave system I'm hoping that it will actually help this time...

Hmm, what do you enter to use RumbleStats? The way I use it, I do get the MediaWiki template format like you had there. I put in this in double braces: subst:rumblestats:roborumble|voidious.Diamond 1.2.3

I do that as well, with an added |GTStats at the end. I always just do a copy-paste from Template:GTStats. I do another subst: the next time I make changes to leave the rendered text only. For some reason it showed up correctly in the page when I submitted it, but when I reloaded a bit later it showed the scores as 0. Perhaps VoidBot reached it's rumble quota?

Oh, I see. Yeah, RumbleStats (which has its own API key actually) is also subject to a rate limit, though I think I've found it to be higher than the rates Darkcanuck originally described.

"Fix my x.x5 exploit" - You mean where you round bullet powers to x.x5? I actually tried this recently in tests and didn't see any improvement. I figure bots where this exploit is working are being crushed enough that I'm staying at high energy and using my default all the time. And even if they are occasionally seeing hit waves when I change bullet power, it may not be enough to affect scores.

Actually, I saw a tiny improvement with one bullet power formula, and a tiny decrease in another, so I think it was just an effect of slightly increasing bullet powers to get up to x.x5. Do you always round up like I did? I figured it would be dumb if I calculated the exact right amount of energy to kill my opponent, then rounded down. ;)

I actually found not all x.x5 powers work at exploiting the bug - some of them get the same results for the rounding on both sides of the comparison. So I made an array of the ones that exploit the bug and choose the closest value.

I also removed all of the values between 1.95 and 2.95, because if I was using 2.95 in the first place (ie. hitrate > 33%) it means it was advantageous to shoot with high power against them anyways.

But maybe I should have something like 'round up if this shot will kill them'. I hadn't even considered that, and yeah, rounding down would be kind of stupid, even if it wouldn't leave them with much energy.

Lol, that is so hardcore. I'm not sure I can bring myself to muddy up my bullet power selection with all of that, but that is pretty awesome. =)

I don't understand, why would you ever ignore a bulletHitBullet?

I wasn't sure about making a club, but I've been watching for it, and you're at 90.02 APS with 1866 battles and 922 pairings. Congrats. =)

And looks like you're the first to make it stick even after a few thousand battles. Congrats!

And you were only a few hours behind...

I think with that 'light flattener' it would make sense for it to have very deep rolling depths, similar to a 'typical' VCS gun, considering how often flatteners get new data.

This first version was k=min(50, num data points / 5) of the last 1000 data points, all weighted equally (no chronological weighting, still divide by inverse distance). I still have a fair bit of tweaking to do, so hoping to squeeze another .1 or so out of it. But with my luck my first guess will be impossible to optimize further. =) This was an improvement of like 0.3 in my 500-bot test bed, but of course that's quickly halved with all the 99% bots that I don't test against.

Of course, I was thinking 1000 was about 1 round of data, when it's actually ~20 because it's not using virtual waves. Doh! Guess I'll try dialing that down a lot. =)

Congrats indeed!

Regarding "why would you ever ignore a bulletHitBullet?", based on the version history it sounds like this was done as a hack to get better HawkOnFire score. It makes sense to me that this would work for that because sometimes HawkOnFire doesn't *exactly* aim at GF=0.0, but if you start trying to dodge a slightly-off-zero location, you're more likely to just barely get hit on the other side of slightly-off-zero.

Yup, Rednaxela hit it on the head. HOF shoots fairly off-center surprisingly often, so I relied on my pre-seeded GF0 to dodge. It only ignored BulletHitBullets if there weren't any hits yet (ie, dodging the GF0 was successful).

Holy wombat! You guys set the bar very high :). Congrats!

90+APS on 900+ competitors is, well, very impressive.

Thank you =) Although, I must say, the air is getting very thin up here...

Nice to see you're going for some pretty major changes in recent versions. =) Hoping to get away from the tweak train soon, myself.

Your changes sound vaguely along the lines of Talk:Wave_Surfing#The_Next_Level. My vision along those lines is more about predicting the firing situations presented to the enemy during the surfing options, then factoring the danger of those situations into the surf danger. For instance, if clockwise is moving towards the wall, the enemy's next bullet will have a precise MEA of 0.5 / distance 400 / normalized hit rate of 10, while counter-clockwise is a precise MEA of 0.9 / distance 550 / normalized hit rate of 8 for those firing attributes. At first glance, it seems like multiplying those right into the surf danger makes sense. But if you have multiple firing situations, the values should probably be added together before being multiplied in.

I tried implementing this a while back, with just the precise MEA / distance stuff, but I couldn't get any improvement out of it. It was also a HUGE pain trying to do this in such a way that preserves the "if we exceed max danger on the first wave, don't calculate the second wave" optimization, because you have to also account for the fact that different movement options will end sooner and have different numbers of firing situations to factor in.

Not to say that the approach I tried / might try again (which was based on your post) is mutually exclusive to what you're doing here...

Yeah, I've never had enormous gains from tweaks, so I think aggressive is the way =)

In my precise prediction I now keep a record of my path, so when I get to the time that they are predicted to fire I can calculate what the wave surfing attributes are and fire a wave. The biggest issue at the moment is predicting what their movement will be so that I can give the wave a realistic center. Right now I'm just using linear prediction. Note, this is just for the first wave. There are some major issues in the structure I've introduced, it seems, but my goal is to be able to make intelligent decisions not just for how surfing this wave will affect the second wave, but also how to move before any waves are surfed/when there are no waves in the air so that I can dodge whatever they throw at me.

Definitely agree with focusing on big changes vs tweaks. But I also can't resist trying to tune things up constantly. Part of me just feels like the only way to really show the true value of a big change is on a bot with all the small stuff already optimized. =) For instance, when you first wrote a go-to surfer, it seemed cool that it could be competitive. Once you were #1 and miles beyond the rest of us, that's when it really started to seem like there was something to it. =)

And my recent surge has, from my perspective, been the product of something else entirely: code quality and bug fixes. It was just two months ago I started a big code overhaul with no features or performance gain in mind, just trying to clean up my code so it was something I could be more proud of. I just found lots of stuff to fix and improve along the way. And the improved code base made it much easier and more pleasant to do lots of the new things I've been playing with.

Welllll.... sometimes it seems changes are just too aggressive. I'm going to leave this idea to mull in the back of my mind for now, and concentrate on other things. I still don't understand why it didn't work as expected, or why I get a lower score predicting a fake wave when there are no waves in the air than even plain old orbiting.

The only thing that comes to mind is attack angle control. Do you use the same in no-wave cases as for surfing cases? I know I move towards my desired distance more aggressively when there are no waves in the air.

I did think of that, but never got around to it. Perhaps I should breath some more life back into the 2.6.x line. I have a few more experiments I want to try with the 1.7.x's first though. And... if I do get the 2.6.x doing better than 2.5.6, it should be easy to merge the changes across. Then onto 2.8.x for some data poisoning ideas!

500 rounds against DoctorBob does wonders at testing whether surfing mechanics are working correctly, and hunting down what is wrong. It runs really quickly and just looking at how much bullet damage DoctorBob gets is a great indicator of how accurate your surfing is. There is usually ~50 damage required for learning (for me at least), and the rest accumulates due to bad positioning and inaccurate prediction.

A quick breakdown of DoctorBob's bullet damage by version for 500 rounds:

2.4.14: 96

2.5.2: 155

2.5.4: 62

There's a bit of noise in there, for sure, but it's fairly easy to tell when something is working ;-)

Wow, it's interesting your survival score has remained so high with these buggy versions that kill your APS. I've been wondering recently if your high survival is sort of just because that's where the points come from when you start getting up that high. (Like maybe when you get over the hump of losing 0 instead of 1 rounds to a lot of bots.) Maybe that's still partly true, but it appears something particular about DrussGT gives him way better survival skills than Diamond.

Yeah, not sure why that is. Although Diamond is only 0.2% behind 2.4.14 so I don't think it is related to "where the points come from". It might have to do with my bullet power selection algorithm, it starts cutting back on the bullet power really early if my energy drops.

Then again, it might be due to the kind of bugs that were being experienced, and who they most affected. I just figured out what was wrong, the second wave prediction points were being initialized with a time relative to the first wave firing instead of the absolute time. Doh. So maybe the bots that the second wave helps most against weren't bots I was likely to lose and additional battle to?

You've probably already noticed, but did you break something in 2.4.9? [1] At first I suspected a bad client after what happened to Wallaby, but I think pa3k has been running his clients for a while with no issues.

0 bullet damage for both bots? That's a wacky result right there! :(

It's so cool that you do not rest with pushing further and higher.

Totally agree, even if it is also frustrating to some of us. =)

Seems to work too.

Yup, it was the result of a genetic tuning =) I'll try with using both Diamond and Tomcat next, possibly adding a time attribute in to improve the rolling.

I'm curious, are you using WaveSim for the genetic tuning, or full robocode battles? It would be a lot faster to use things like WaveSim, but on the other hand I consider WaveSim bad for testing against surfers.

I hacked up my own version of WaveSim which does just the bare basics. It took about 80 seasons with a population of 30 to converge to a final set of weights. I agree, using a fixed dataset to simulate an adapting target isn't really ideal, but the speedup is just phenomenal and as PEZ said, it seems to work :-)