The default page text fits this robot's name quite nicely.
Gun statistics: see /GunResearch
|Bot Name||Author||Type||HOF||SPL||GRG||Sub 1||WAY (Sub 2)||GR3||RKM||Sub 3||ASC||CC||CHK||Sub 4||Total||Comments|
|Horizon 1.0beta4||AaronR||WS/DC||97.47||86.26||84.54||89.42||67.64||65.04||80.31||72.68||22.03||37.11||31.84||30.33||65.02||1 season|
Up 16 places with 0.9.6, what's new? -- Skilgannon
I took your advice and made the bot do all of its clustering and sorting of scans at the time the relevant wave is fired. It seemed to help the surfing a lot, it shot up the WSC2K6 scores close to 85. In addition, adding a default hit logged at GF 0 got the bullet damage scores vs. Bot A as low as 28 over 500 rounds. - AaronR
How much has it helped vs. bot B and C? I'm guessing it would have made a huge difference, because LT/CT only use data at the time of fire. Just wondering, are you using a rollingAverage for your surfing? -- Skilgannon
Since you are still a little bit below BasicGFSurfer, I'm thinking that you still have some bugs to sort out ;-). Looks like these are the bots with the biggest differences:Skilgannon
You're getting mashed by any and every sort of pattern-matcher. How about adding a time-since-something segment in your surfing? -- Skilgannon
Sorry I've been gone for a while, my workload has been nasty lately. I was just running some tests with the development version of Horizon when I noticed that the bot was skipping a ridiculous number of turns. So I fiddled with things for a while and eventually managed to figure out that I actually have two molasses-like sections of code:
It seems that I didn't notice this in my performance before because I never bother to run Robocode before starting my rumble client (for which I keep a separate Robocode installation), meaning that the default super-high CPU constant is used. So now I have to optimize my code, which is something I *really* hate doing.
For your precise prediction, Krabb (I think it was Krabb) pointed out a clever optimization, assuming you're surfing more than one wave at a time. The idea is to get your full danger for all waves if you continue going in your present direction. Then when you're checking the "reverse directions" danger, you can break early if the danger is greater than your "continue" danger, even if you haven't checked all waves yet. --David Alves
Aha! It turns out that my precise prediction had nothing to do with the problem. Rather, the slow code was exclusively in my clustering implementation. Guess what the problem was: I was using java.util.LinkedList to store my log history. I replaced the collection class with a custom circular array structure, which eliminated the problem altogether. So basically, Java collections are slow and inefficient - but we knew that already. -- AaronR
I don't think there's more than a few percent difference between their LinkedList class and one you could write yourself. ABC brought that issue up once before, but it turned out he had been using list.get(int i) inside a for loop, so what should have taken theta(N) time took theta(n^2) instead... --David Alves
1.0beta9 seems to have made HUGE gains compared to 1.0beta8. Only 27 battles have passed, but I'm still gonna call it: I think it will be your ticket to The2000Club. Well done in either case! --David Alves
Alright, I'm an idiot. I released the MC2K7 test version of Horizon as the official version, meaning it had Raiko's gun. Ironically, it ranked about the same as RaikoMX... So for the second time in a row, I have been embarrassed by my gun only to find out that it means I have a very good movement. -- AaronR
Although, wow, that is a lot lower. Are you sure your gun is bug-free? Can it hit Walls consistently and whatnot? A 120 point difference due only to gun sounds very wrong to me. --David Alves
I gotta second what David said. With that big a difference, I'd even wonder if you might have a bug that is making you just shoot with HeadOnTargeting... ? Sounds like you have a very strong movement, in any case, and I think that's usually harder than getting a good (or good enough) gun. -- Voidious
I watched some battles and it's definitely not firing with HeadOnTargeting, it hits walls well enough. Could there be a bug in the Angle -> GF -> Angle conversion process? For example if the target is moving clockwise around your bot, and it moves .5 radians in front of the GF0 line, maybe you store that as GF .7 or something, but when converting back to angles you convert the .7 GF to an angle of .8 radians and end up shooting too far ahead / behind... --David Alves
That's possible, but not likely, since most of the original source for the gun was from the largely bug-free GFTargetingBot. Also, much of the code is shared between the movement and gun, including some (but not all) of the GF conversions. I'll look into it, though - I may have broken something while I was fiddling. Maybe improving my debugging graphics will help me find the problem. -- AaronR
Just out of curiosity, how many scans are you searching through? And also, how much are you weighting each attribute? -- Skilgannon
My log depth is 7200, and my cluster size is 5. My weights are: distance = 2, velocity = 1, acceleration = 3.5, lateral velocity = 2, time since acceleration = 2.5, wall distance forward = 5. I know those weights seem odd, but the tests I've been running seem to indicate that that is the approximate order of importance of those attributes against low to midrange random movements (which of course make up most of the rumble). Against high-end random movements and surfers, it is much less important to weight wall distance high.
I think I have may have found the problem. I just created a test bot called WallsReverser?. It acts exactly like Walls for the first five rounds, then behaves like a mirror image of Walls (that is, circles in the opposite direction) after that. GFTargetingBot does what a correctly implemented GuessFactorTargeting gun should do with this bot: hit it just as well on the sixth round as on the fifth. It didn't care what direction the bot was orbiting in. However, when I put Horizon against WallsReverser?, it fired as if it was targeting Walls - completely ignoring the fact that the bot was now moving in the opposite direction! It figured out the new pattern fairly quickly, but that doesn't solve the problem. Worse yet, I have no idea what is causing this, since the GF-to-angle calculation is multiplied by the lateral direction like it should be.
I would check that you are actually setting the direction to what the enemy's lateral velocity's is. Another thing to check is that you multiply both when you store the angle and when you use the angle to fire from. Shadow uses a MUCH larger log size (about 15K), and a much larger cluster size (50), so if it doesn't slow you down too much you might want to give that a try as well. IMO you should use lateral velocity or velocity, but not both. Maybe switch one to advancing velocity, and weight it lower. And just to check, you are normalizing your data for each attribute to values between 0 and 1, not -1 and 1, right? Absolute values of your lateral velocity are necessary, otherwise your gun won't see reverse the same way it sees forward. -- Skilgannon
Sounds like you're either multiplying by orbit direction too many or too few times, in either your Angle -> GF or your GF -> Angle code.
When saving a scan:
GF = orbitDirectionAtFireTime? * Utils.angularDifferenceBetween?(gf0Angle, shooterAtFireTime?.absoluteAngleTo?(p) / Utils.maxEscapeAngle?(power)
Another possibility is that when you store a wave you're using the target's current orbit direction instead of their orbit direction at the time you fired. Incidentally angularDifferenceBetween?(fromAngle, toAngle) is just Utils.normalRelativeAngle(toAngle - fromAngle), but I like the name better. Before I put it into a method I was always forgetting which part should be on which side of the minus sign. =) --David Alves
(Edit conflict) Here are my responses to Skilgannon:
I would check that you are actually setting the direction to what the enemy's lateral velocity's is.
Shadow uses a MUCH larger log size (about 15K), and a much larger cluster size (50)
IMO you should use lateral velocity or velocity, but not both.
You are normalizing your data for each attribute to values between 0 and 1, not -1 and 1, right?
Absolute values of your lateral velocity are necessary
And to David Alves:
Just a couple sidenotes: Raiko and GFTargetingBot should be very similar in performance, as they are both based on Tityus. Also, a log depth of 7500 seems fine, though other DC guns do use many more; a cluster size of 5 seems a little small, but not 100-points-below-Raiko small. =) Sounds like you have found the big bug, though, so best of luck in your quest for 2K! As for using absolute value of velocity / lateral velocity: I absolutely think you should do this. Why should -7 or 7 make a difference? Odds are the bot that's moving doesn't see them as different, and it will majorly inhibit your learning speed. -- Voidious
I'd like to thank Simonton for finding the massive bug in my gun. The bug was caused by - surprise, surprise - movement tweaks! When I modified part of my shared Wave class to more accurately detect wave intercepts for the surfing, I inadvertently destroyed the accuracy of the gun's logging algorithm. With that fixed, my rumble scores should improve considerably. -- AaronR
Looks like you'll have yourself a ticket into The2000Club once you reach 1000 battles... get those clients running, people! =) --David Alves
In addition to fixing that bug, I also introduced several other tweaks in the 1.0betaF4 release. I'll have the full version history for the 1.0betaF series ready as soon as I can remember all of the changes I made. -- AaronR
Wow, almost 20 points to 2056, nice work! So much for it being buggy... =) -- Voidious
Nice work! I might just have to borrow your MEA calculation stuff - see if it also gives me a 20 point boost =) -- Skilgannon