Difference between revisions of "Archived talk:CassiusClay 20090424"
m (moved CassiusClay/Archived Talk 20090424 to Archived talk:CassiusClay 20090424: move to talkarchive)
Latest revision as of 05:50, 8 October 2009
Hi Pez, i like the poetic version name of CC ;) when can we expect POSITIVE_INFINITY :O But my real question is: why do you compare CC with Quest? Is it to compare with a stable reference bot? --Loki
Yeah, the total score fluctuates quite a bit. But the diff against Quest generally remains through these fluctations. I am more using a build number than anything else. =) Maybe I should patch my Makefile to update such a number ... -- PEZ
When are we going to see the next version of CassiusClay? Those dev TC scores you posted are downright scary! -- Voidious
Hehe, thanks! Double thanks since it was you getting me to do a really fast rolling version of my gun. I have one more thing I want to test before I release something like "CassiusClay 2 alpha" onto the rumble. And those latest TC scores was much luck I think. The VG array makes the gun performance pretty volatile. But, yes, it gets TC2K6 scores above 89 all the time. I still think it might make CC lose rating in RR@H though. Most bots aren't surfers and Bee had the number to those most bots before this VG thingy. We'll see. -- PEZ
At the very least it should make CC rank higher in the PL. -- ABC
Yeah. I really think it might do that. Haven't done any 35-round testing though and I guess the VG guessing penalty is worse with short matches. But still, some more wins should come. At least were it is close with the current version. Shadow is safe on the thown though. CC can't still even worry it in head-to-head battle. -- PEZ
That's good to know, my anti-(anti-wavesurfer-gun)-movement still works. ;) -- ABC
I am reminded of the Clausius-Clayperon Equation. (Latent Heat of Vaporization Lv is a function of T). -- Pfvicm
You never know with the RoboRumble... but after ~275 pairings, CC looks on pace for a 7-10 point rating jump with this version (2pi.02). Hope to see it above 2070 when I get up - and if so, nice job. =) -- Voidious
A bit tentative, yes, but still I have 2064 now and broke out of the race condition with Shadow. =) As I have so little time for robocoding I am at the moment just experimenting with the weightings of the movement flattener and stuff like that. It seems some points live there at least. Not sure yet since 2061 might be == 2064 in RR@H considering my VG is as arbitrary as it is -- PEZ
Care to shed some light on what you've been playing with in the 2pi.* versions? I know I could extract them and run the diffs myself, but I'd rather hear it from you =) -- Voidious
It's tiny tweaks really. Mostly in movement. Weighting of flattener, rolling depths, weighting of secondary waves. Stuff like that. -- PEZ
Well, whatever it was, you're that much closer to 2070 now =) -- Voidious
Actually this on (2pi.08) tested something else. I tweaked the magic constants in my dive-in protection. (Check Butterfly.java and the smoothingDanger() method in the Move class.) It makes me quite curious on how you guys deal with it. -- PEZ
Well here's how I deal with it: Phoenix will smooth up to a certain angle with no "danger" penalty at all. Beyond that angle it will not smooth, no matter what. Nice and simple. =) --David Alves
Yes, that's quite like how I do it too. Though I have it that I quantify the danger, always very high. It's to help end the deadlock when both forward and reverse are flagged as dangerous. -- PEZ
When a deadlock occurs the angle is increased to the point that there is no more deadlock. Deadlocks are extremely rare though. If you look in phoenix's console it reports "times stuck in corner", that's the total number of turns it has been in a "deadlock" in all rounds so far. --David Alves
Yes, it's rare, but they do happen, especially against rammers. I'm not sure I understand what you're saying though. You said that beyond a certain angle you won't smooth. But if that is the case in both direction you keep smoothing, or? -- PEZ
I definitely do things differently than you two. My only special case is at very low distances (like < 100) against non-simple targeters, where I WallSmooth away instead of towards the enemy. My general dive protection is just part of my overall distance control. For each of the forward / stop / reverse positions, I also record the predicted distance to [closest] wave source and predicted distance to enemy's current location. Then I multiply the danger for each movement option by (current-distance-to-wave-source / min(predicted distance to bot, predicted distance to wave source)) ^ some power. So it favors keeping a distance, and acts as pretty strong dive protection. Komarious does similarly, although in a much more bare bones way. -- Voidious
One small thing that can help avoiding getting stuck in corners is to use RoundRectangle2D instead of Rectangle2D for your movement. -- GrubbmGait
V, I had a solution similar to that a while, but I never got it to behave. It always ended up with my bot bouncing off walls and refusing to smooth at all. I guess I must try again and this time normalize my danger value to make sense out of it. -- PEZ
@PEZ: Here's how it works. Let's say the cutoff angle defaults to 30 degrees. Phoenix will smooth in either direction up to 30 degrees without it affecting the danger values at all. If either direction requires more than 30 degrees of smoothing, than Phoenix will disqualify that direction. If both directions are disqualified, Phoenix increments the "timesStuckInCorner" counter, prints a message to the console, ("WARNING: Corner escape mode enabled, projected future positions may not be accurate") and repeats the whole process with a higher threshold angle, say 60 degrees... a threshold high enough so that it's impossible for Phoenix to disqualify both directions. I must say again though, it's extremely rare. In a 500 round WaveSurfingChallenge, it happens in perhaps two rounds maximum, and often doesn't happen at all.
@GrubbmGait Yeah, YinYang does that, it's a great trick. =) --David Alves
Yes, but that's quite much like what I do really. The WaveSurfingChallenge probably doesn't reveal many of the deadlocks though, since the opponent is stationary. -- PEZ
Ain't it funny how you can toil away, version after version, never finding an improvement; then, after a hiatus, you come back and get a nice jump on your first try? =) By the way, care to elaborate on "Swarm"? I diff'd it against 2pi.08, but I still wasn't sure what the "main" changes were. -- Voidious
- Oh, duh, now I see BeeSwarm.java. Looks like the major change is 6 instead of 2 buffers in each of the guns, eh? Cool beans. -- Voidious
Thanks Chase-san. I can see that the graphs for pi.08 and swarm.a are very different. But I don't have a clue how to interpret the differences. Anyone who wants to LRP-speculate on the new CC, please do.
Voidious, I'm very surprised CC didn't drop like a stone from the changes I made. The changes are much deeper than they look at first glance. The core idea is my answer to the question "what stings harder than a Bee?" - "A swarm of bees". I got inspiration reading a very good book:
The book says to stop hunt for the expert and instead tap into the collective wisdom of the group. Even if the group consists of mainly non-experts they will outperform the expert as long as some conditionals are met.
- So, introducing CrowdTargeting, I threw out the VirtualGuns, split my two guns in four and then added 8 more, much simpler in segmentation. Then I ask all 12 bees (guns) for their individual guess and pick an average guess from there. Unweighted. Simple bees have as much to say here as the expert bees.
My quick tests showed that I can tweak the swarms performance by carefully selecting what to include in the swarm. One of the conditionals that Surowiecki sets up is diversity. And here my swarm doesn't have too much of that. They all draw their conclusions from the same data, all individual segments are the same and such. Next step will be to introduce more diversity and also more bees into the swarm. The Crowd Wisdom theory says that larger groups arrive at better answers.
I will soon ask for some help in the design here. Anyone who looks at BeeSwarm.java will see that it's extremely crude and unmanageable already at 12 bees. I want a swarm of at least 50 bees! But my attempts to design myself out of the mess all fail. I Rushed this CC out to just get some kind of answer if I am on something good. Which I seem to be! Yay!
Oh, very cool. I didn't realize "Replacor" and "Accumulator" weren't even separate guns any more! I'm sure you have some more points in tuning this, as well. This reminds me a bit of my many movement buffers, which seems to be quite a few more than most other surfers. I had 17 plus the extra 3 in the non-firing flattener; in 1.541, I added 3 more to the main set and made the weightings much simpler (still not unweighted), for a gain of a few more points. It seems having that many stat buffers in the movement works very well for Dookious. This might finally give me a fresh idea to experiment with in targeting. =)
I think Dookious and Phoenix are still the only ones using precise max escape angles; that's another change that's probably worth a few points while you're tinkering with your gun. Really nice work! I'll have to run a TC2K6 soon if you don't.
Ah, yes, Kev was right, with that many buffers and less weighting complexity you are probably tapping in to the wisdom of the crowd there. I've always been curious as to why my strategy of averaging my fast and slow learning buffers has always been more successful than trying to figure out when to switch from faster to slower buffers. Even a crowd of two seems to gain some. I still can't run many Robocode battles on my machine without a blue screen. I would of course be very grateful if you run the TC for me. Looking at CC's performance in the rumble it seems that I'm still too weak against surfers. To counter that I might move away from the puristic crowd wisdom implementation to one that's more a mix of VirtualGuns and CrowdTargeting. We'll see. -- PEZ
Somehow, a "swarm of butterflies" just doesn't sound as cool... =) -- Voidious
I think that the intention in this case is to enchant the opponent and while it gasps at the 'cloud of butterflies', let the bees do their work. Maybe it is better to compare with a cloud of sparrows: A few decide to change direction, and the whole bunch follows, generating a non-predictable movement. The idea itself does make sense, although I think that a few dedicated and complementing experts still would do better. The hard part is to find such experts ;-p -- GrubbmGait
Even finding those experts they might have troubles consistently outperforming the crowd. I just tried removing the experts and replacing them with some really simple learners in my swarm of bees and I think I see an improvement. This or that gun might be better against this or that target, but in a fast learning environment you'll better trust the crowd. The right crowd is what I'll hunt for now. -- PEZ
Here's the results for TC2K6:
| Name | BFly | CC | Chk | Cig | Cya | DM | FM | Grb | RMB | Tig | Total | Comment | CassiusClay 2swarmMC | 99.84 | 65.50 | 93.37 | 80.42 | 80.86 | 95.47 | 91.36 | 90.37 | 92.13 | 91.97 | 88.13 | 3 seasons
Surprisingly low Cigaret score, and certainly lower than your best Bee scores all around. Once again, proof that challenge scores don't tell the whole story...
@GrubbmGait: You're talking about the AI technique called flocking, never really brought me anywhere... maybe if you make each movement technique a seperate 'boid' then output movement according to the flocking rules.... -- Nfwu
Thanks, V! Isn't that score almost entirely ruined by the low Cigaret score? Cigaret's movement isn't exactly typical for the rumble. Something to think about when selecting the reference bots for next version of the challenge maybe. -- PEZ
@ PEZ : How about using MultipleChoice instead of just averaging the angles? Wouldn't this give better 'crowd opinion accuracy'? -- Skilgannon