View source for Talk:DrussGT
Just going through the algorithm, and I realised that there's a bug in my precise prediction: I'm using the bullet-hit-time of the 'target' point, not the point that I actually reach. This is left over from the days when the only thing my precise prediction checked was whether I could reach the target point. Now, for regular, constant distance surfing this is fine. But the moment I start changing distance my predictions can get a couple ticks off... Basically the less lateral velocity component I have, the more inaccurate my prediction gets. Which is bad against, say, RamBots, and in corner situations. I may have to rethink this algorithm... I've already tested doing an iterative search but it gets way too slow, way too quickly. --Skilgannon 10:47, 27 January 2009 (UTC)
Hi, I just want to know. You had once tell me that DrussGT doesn't call Math.random() in real battle, but it does in development process. Is the random call in development process use to generated all those 100 buffers' slices? Thanks » Nat | Talk » 06:02, 21 February 2009 (UTC)
Again, I'll rework DrussGT and see how it will act if it had 393216 buffers. (The maximum buffer without duplicated buffer :)) » Nat | Talk » 06:05, 21 February 2009 (UTC)
- [View source↑]
- [History↑]
Contents
Thread title | Replies | Last modified |
---|---|---|
Precise Max Escape Angle bug | 0 | 03:14, 22 June 2019 |
Throws exception when MC flag is on | 0 | 05:34, 3 February 2018 |
timeSinceDirChange bug | 2 | 12:10, 31 October 2017 |
close race at #1 | 2 | 16:56, 18 July 2012 |
genetic tunings | 3 | 02:43, 4 December 2011 |
Head-to-head | 17 | 08:14, 19 October 2011 |
exception in 2.2.0 | 1 | 08:04, 22 September 2011 |
Once I noticed DrussGT is orbiting predicted location, I turned on the MC flag to better see the movement ;)
However, in onPaint,
if (!shieldEnabled)gun.onPaint(g);
gun is null when MC is on, while shieldEnabled is false, so it throws NPE.
changing this line to
if (!shieldEnabled && !MC)gun.onPaint(g);
will fix that ;)
Btw, what's the biggest impact on movement between orbiting predicted pos and last seen pos/wave pos do you think?
Hey, I was trying to plug Druss' gun into Knight (to do some experiments using my MEA/preciseIntersection/features calculations to see if they break your gun) and I noticed something interesting in the code.
I looked throughout the wiki and found nothing about it being a known bug (and probably performance enchancing?), so I'll put it here anyway.
In the onScannedRobot() method, you override the "lastDirection" variable with the new direction value before updating "timeSinceDirChange". This causes this variable to be incremented at every scan, as you increment it if(lastDirection == direction). So, the normalized version 1/(1+2x) goes quickly towards zero during the round, which is probably almost the same as having a very low weight for this feature.
Not sure when you introduced this, but maybe it is worth fixing it in the future for a possible programmatic tuning round.
That certainly isn't intended behaviour, and might also explain why I was never able to get much benefit from this attribute. Thanks!
I find it pretty cool that Diamond and DrussGT are so close right now, it's sometimes coming down to the head-to-head score to determine who's ahead. =) (Though I don't find it as cool that it's always DrussGT...)
Yeah, I'm racking my brains for anything which might give me a little edge and have come to the conclusion that my regular, slow, plodding idea/implement/test/release schedule is still the best plan.
And I'm not sure what is giving me these surprisingly high scores against Diamond. Of course, what I gain there I lose in comparison against deo.FlowerBot. How on earth are you managing to dodge a pattern matcher so well?
I similarly kind of took my foot off the gas and decided to just continue my usual development routine. I figure it's going to take more than a minor lead to break away from DrussGT and actually claim the throne. Right now I'm obsessed with matching or beating 1.7.53 by tuning my hit percentage thresholds (flattener, decaying surf stats), because I refuse to rollback to a stupider way of normalizing hit rates. =)
Diamond scores about 44% vs DrussGT over a lot of battles. I haven't focused on it much lately, but I have in the past and just had no idea what to do to improve. Not sure about FlowerBot... I don't think I've ever watched a battle against him. =)
I'm curious about your genetic optimization stuff. This is using genetic algorithms to tune attribute weights with pre-gathered data using your WaveSim-like system? Or is there any GA stuff happening mid-battle? I've generally believed WaveSim wouldn't work against surfers, but at one point I convinced myself I might as well try. I gathered a bunch of data, only to find that HOT outperformed my guns against it, which convinced me it was probably useless. Have you run real battles to check that the improvements correlate, or are you just dropping them in the rumble?
Well, on Talk:DrussGT/Version_History#Anti-Diamond_tuning_.3D.29_404 already stated it was fixed pre-gathered data.
My suspicion is that while HOT performs better than actual guns in such tests, WaveSim-type tests could still be useful(but non-optimal) against surfers in restricted domains (i.e. changing the relative weights in segmentation). For instance... I suspect it may be less useful for changing relatively "dynamic" things like VG rolling weight paramters, than just how segmentation works.
I would say that if HOT is outperforming your guns in classifying/regressing the wave values it probably means that your gun isn't shooting towards GF0 often enough, making the surfers move towards GF0 too often. I haven't actually tested to see if HOT is outperforming my guns, but just changing the weights in my gun can improve my hitrate by ~8% (difference between worst (random) weights and best (final) weights).
I've thought maybe my process should involve recording WaveSim data, doing genetic tuning, recording new WaveSim data with the new tuning, and repeating until it converges. I think this would do quite a good job of having the same effect as genetic tuning directly against a surfer, but much faster.
Well, I'm not sure it means that... I'm not sure how you'd even code a gun to shoot at GF=0 more often (besides stupid ways =P). Regardless, it makes it pretty clear that what works in WaveSim is not what works in real battles, since HOT would perform dismally in real battles vs surfers.
The reason I thought WaveSim might still work against surfers is that even though your WaveSim targeting decisions are based off of a different movement profile than they would be in a real battle, the characteristics of the real vs simulated movement profiles may not be different enough to matter. You're still making each firing decision off the same data set. So maybe I will give it a shot. (Hopefully I didn't delete all that data...) I also love your idea about tuning/re-gathering data.
DrussGT 2.4.5 certainly far outperforms 2.4.4 against Diamond, so that's something. Then again, I've done so much anti-DrussGT tuning recently that it's possible just about any change you made would have improved your score against Diamond. =)
I've been focusing a lot on beating DrussGT and Shadow lately and just wanted to give you props on how incredibly strong DrussGT is. Nothing I do to movement or gun seems to have any positive effect, like there's just some magical element I am unaware of. I tested with my flattener or Anti-Surfer gun hard-coded on, and those too had almost no effect - the flattener helped slightly, giving me my best score of 46.6% over 55 battles, up from the usual 45-46 range. Definitely need to put my Thinking Cap on over here. =)
Haha, thanks. I'm putting in work on my side as well, I'm experimenting with using DC for movement. My best version loses around 0.4% on the MC2K7 vs 2.2.0, mostly against the top bots, so I haven't released anything yet as I don't want to lose my new PL crown =)
Oh, neat! DC surfing requires some serious thought after years of doing things in VCS ways. I'm still working some fairly basic things out, after all this time. It gets you to really analyze how/why aspects of your VCS setup worked. Actually, I think I had an important realization just last night...
0.4% doesn't sound like much. :-P But then I don't think MC2K7 is a particularly robust way to measure a drastic movement change, either.
Interesting, no matter what I tried I couldn't get it better than my 3rd try (the -0.4% one). I guess I'll have to stick with my VCS for now... it's just that DC would be much more suitable for an idea I had...
Sounds familiar. =) You sure you ran enough seasons? Sometimes I convince myself I ran enough and then waste lots of cycles trying to match what was actually just a lucky score...
100 seasons, which should be plenty... minor tuning changes score slightly less but in the same region. Maybe I'll try identical code and see what happens...
My intuition is that so long as the magnitude that dimensions are weighted with is similar, the most likely sources of loss/differences between VCS and KNN would be:
- Non-linear spacing of segments in the VCS. In order to achieve maximally similar results between methods, you need to preform transforms on the dimensions to approximate the result of any non-linear spacing of segments in the VCS.
- Insufficient number of KNN data points used when the data is dense (late in battle). How many data points should be used should probably be larger as the data becomes denser. The density of points returned should probably affect how many points are used.
Have you looked into these factors Skilgannon?
I'm going to try the non-linear thing just now - good call as I had forgotten about this despite spending quite a while tuning it in my gun.
I'm currently weighting based on distance to the location point as a function of the average distance of the closest 3 points - it works quite well but I wouldn't be surprised if there were improvements which could be made.
While I think those points are valid, I somewhat disagree with their importance.
- I've experimented with different scaling of attribute differences, but never to any major success, in gun or movement. I'm currently not doing this anywhere in Diamond.
- If the data is dense anywhere in the graph of your movement data, it probably means you're getting hit a lot by a learning gun, at which point a much bigger issue is modeling data decay intelligently. Experience has shown that in VCS, stat buffers of varying depths with a generally low rolling average works well. There's no direct way to translate that to a DC setup.
Personally, I'd say that intelligently modeling data decay in DC surf stats is probably the biggest hurdle in converting from VCS. It's actually one of the main things I'm still tinkering with. I'm pretty happy with the setup I've arrived at in Diamond, but I think there's still a lot of room for improvement. I'd be happy to go into more detail about that if anyone's interested.
Here are my thoughts on those aspects.
The approach to data decay I took in RougeDC was to have an "index" dimension which continually counted up. This is kind of mean/nasty to the kd-tree performance, but as far as KNN search I think it's a very natural way to model decay.
Regarding varied depths, I'm pretty sure the depth of VCS segmentation is extremely analogous to the number of KNN points used and how they are weighted. The way to match that aspect of VCS systems is to mix the result of varied numbers of points in varied weightings. Since processing the same points multiple times is redundant it simplifies to the following: The way to get the same effect as varied depth VCS, is to work on how your weighting of KNN points rolls off, and use plenty of KNN points so it rolls off properly before the limit on number of points is reached.
I don't know if you were referring to this Voidious, but with regards to having many stat buffers as some like DrussGT do, my experience is you get the same effect by performing antialiasing and interpolation. This implies to me that the primary cause of "many stat buffers" being effective for traditional VCS is that it acts as a sort of accidental stochastic antialiasing. A KNN approach implicitly needs no antialiasing/interpolation, so that aspect of VCS setups does not need to be arranged.
(We might just move this thread to Talk:Wave Surfing at some point...)
Well, I agree that much of the value of multiple VCS buffers is covered inherently by a DC system: smoothing of the data and scaling to different amounts of data (eg, no need for a quick-learning unsegmented buffer in DC). So while my best VCS gun has a few stat buffers (and your best does anti-aliasing / interpolation), my best DC gun has only one tree. But while I wouldn't expect to have 100 trees in a DC movement, I do have more than one and I think there's value in it.
As far as data decay in a DC system, I think the progression from simplistic to sophisticated goes something like this:
- Weighting by age. This is not without merit, but is pretty crude. An old piece of data may still be the most recent for that situation.
- Capping number of data points, deleting old ones. Also pretty crude, but effective if it's very important to emphasize recent data. I still do this in parts of Diamond.
- Within the set of nearest points, sort chronologically and weight by rank. This is about as close as you can get to how rolling average works in a VCS segment. I weight data by 1 / (base ^ sort position). So with a base of 2, they're weighted 1, .5, .25, ... . A base of 2.4 is about equivalent to a rolling average of 0.7.
- Use multiple, exponentially increasing values of k (say 1/4/15/50), with each set of data weighted by chronological order. This emulates having stat buffers of increasing segmentation depths, each with a rolling average. The deepest set of segmentation is akin to taking a low k nearest neighbors search, while an unsegmented buffer would use the max value of k.
Lastly, this is just a hunch, but I think another value of combining many different views of your data is that you achieve a safe pseudo-randomness. That is, simply surfing one set of data will make you move more predictably than the sum of a diverse set of viewpoints - at least with a True Surfing algorithm. But surfing that sum of viewpoints is still going to err on the side of dodging bullets accurately, in contrast to a truly random movement.
I need to figure out a way to phase out old scans - however all my experience with using time weightings in DC have been utter failures. I just tried another right now (a counter that counts every tick of the match) and it didn't help either, although maybe I need to weight it lower than I have right now.
I'm thinking maybe using a limited number of points in the tree, and removing the closest when the limit is reached. Then when I need neighbours for creating a buffer I weight the hits by the time they were logged. This should approximate the way VCS does things.
I don't like the idea of 'doing it the way VCS does it', even if it works, because we don't exactly know why VCS works so well that way either.
Perhaps, for a simple quick method take a sqrt(tree_size) cluster and just use the most recent point. Who knows...
I totally agree that emulating VCS is not the ultimate goal, but it does seem like a good starting point. For instance, I think weighting similar situations by chronological rank instead of raw age is a good insight that I wouldn't have noticed if not for considering how things work in VCS.
Oh, I did try phasing out nearest point instead of oldest point for a while. I thought that was such a great idea (I recall it came out of a discussion between us), so I tried hard to tweak it into submission, but I never got any improved performance out of it.
I'm not sure about that, I think raw age might be better for trying to emulate enemy guns. They log hits all the time, not just when a bullet hits, so if there is a bit gap between two bullet hits the last hit may be getting weighted proportionally much higher than it should be. This is something I think VCS does wrong, which can be addressed in DC, if only I could get the scores back up to where they were =)
But it's also the case that a piece of data that's 100x older but 10x closer to the current situation (wrt the rest of the attributes) may be a better estimate of where the enemy is firing in that situation. The ratio of those values is going to depend on how granular the enemy's gun is. So I think considering the situations sorted by time at a bunch of different granularities is a pretty good bet, and I think it's similar to what our VCS systems do with great success.
You have got me thinking again about super-lightweight flatteners against weaker learning guns though. =) It does bother me that they're learning all the time and I'm not!
Btw, I'm up to 49.3% vs DrussGT 2.2.2 now with Diamond 1.6.15 (over 1000 battles). I got up to like 49.7%, but only with some changes that killed my scores too much vs Shadow and Tomcat. I decided to stop spinning my wheels for now and move on to more general improvements. =)
You do not have permission to edit this page, for the following reasons:
You can view and copy the source of this page.
Return to Thread:Talk:DrussGT/Head-to-head/reply (17).
Been running a lot of tests vs DrussGT 2.2.0 lately and I just noticed an exception I've hit twice along the way (in the data dir). Probably over a few thousand battles or so.
java.lang.IndexOutOfBoundsException: Index: 1, Size: 1 at java.util.ArrayList.RangeCheck(ArrayList.java:547) at java.util.ArrayList.get(ArrayList.java:322) at jk.mega.dGun.DrussGunDC.onScannedRobot(DrussGunDC.java:254) at jk.mega.DrussGT.onScannedRobot(DrussGT.java:266) at robocode.ScannedRobotEvent.dispatch(ScannedRobotEvent.java:297) at robocode.Event$HiddenEventHelper.dispatch(Event.java:244) at net.sf.robocode.security.HiddenAccess.dispatch(HiddenAccess.java:194) at net.sf.robocode.host.events.EventManager.dispatch(EventManager.java:487) at net.sf.robocode.host.events.EventManager.processEvents(EventManager.java:460) at net.sf.robocode.host.proxies.BasicRobotProxy.executeImpl(BasicRobotProxy.java:413) at net.sf.robocode.host.proxies.BasicRobotProxy.execute(BasicRobotProxy.java:123) at robocode.AdvancedRobot.execute(AdvancedRobot.java:565) at jk.mega.DrussGT.run(DrussGT.java:156) at net.sf.robocode.host.proxies.HostingRobotProxy.run(HostingRobotProxy.java:220) at java.lang.Thread.run(Thread.java:680)