User talk:AW/lupus

Any ideas welcome! (Of course. I am frustrated enough to make this page after all.) —Preceding unsigned comment added by AW (talk • contribs)

It might be helpful if you explained how your gun works. That way, we'll have a better idea of what's going wrong against Grubbmgrb--CrazyBassoonist 03:13, 4 March 2011 (UTC)

(edit conflict) Heya and welcome to Robowiki. Well, regarding your GrubbmGrb question, I'm not sure to be honest. It would be a bit easier to speculate if the version history of this Lupus was visible, or at least knowing what general category of targeting it is. --Rednaxela 03:16, 4 March 2011 (UTC)

Yeah, sorry about that. I am expirimenting with GF/VCS guns before moving on to k-nearest neighbors and/or neural network guns (which I think seem like the best potential targeting methods). I segment the guns based on, well almost everything.

gun one: velocity, reletive heading, distance, distance to wall, distance back to wall, acceleration, and ticks since direction change.

gun three: velocity, reletive heading, distance, distance to wall, distance back to wall, and acceleration.

gun five: no segmentation and only firing waves.

gun six: velocity, distance to wall, and acceleration.

gun seven: lateral velocity, ticks since acceleration change, and ticks since direction change.

gun six was made based on what state information I would use / seemed likely someone would use to a write a random movement bot.

gun seven exists to find what works best against GrubbmGrb .

gun eight will try antialiasing (assuming it works the way I think it does) with a ticks since accel change segment added onto gun one.

Thanks and God bless you, AW

Hmm, well, the results in the table mostly make sense for those combinations of segments I believe. The ones in gun 7 are what I would expect to be most key parts against oscillators and stop n' go like GrubbmGrb. It makes sense that gun 6 does well against Raiko, because Raiko tends to not hint at it's future behavior very much in acceleration or "time since", due to how it chooses to randomize. It also makes sense that gun 3 does well against Fortune, because Fortune changes between different kinds of movement, and gun 3 is a fairly "standard" segment combination that hits most things okay. Unsure about the DM and WLO scores. Personally, I'd suggest trying a hybrid of gun 7 and gun 6. Also, how many rounds per battle here? If the usual 35, then 3 seasons is awfully short, I'd suggest using more seasons to get a more precise idea of the trends. --Rednaxela 04:35, 4 March 2011 (UTC)

Try time-since-decel rather than time-since-accel-change. I've found it's more generally useful. Also, try having 2 or 3 different sets of buffers with different numbers of segments such that if your higher segmented gun doesn't have any hits then you look at the lower segmented one. Another thing is to increase your number of bins up to ~75 and then do some form of Bin Smoothing. Good luck! --Skilgannon 07:08, 4 March 2011 (UTC)

GrubbmGrb does not try to stay perfectly perpendicular, it moves in straight lines while keeping more or less its favorite distance. When using relative heading it therefor covers more segments, letting you learn slower. When using a heavy segmented gun, like one and three, and there is not enough data, you could use a lightly segmented or unsegmented gun for the first few rounds. It adapts fast while you gather info for your heavy gun. --GrubbmGait 09:27, 4 March 2011 (UTC)

Thanks for all of the help. (By the way it was 35 seasons) I tested only using a virtual gun if it has 50 waves in this particular segment and the results improved (intelligent 3), but I still think that the score against GrubbmGrb is too low. I will try precise intersection and improved bin smoothing next.--AW 01:32, 7 March 2011 (UTC)

It is also possible that it is a very good random movement ;-) Precise intersection will help, but if the base of the gun does not hit this particular movement very well, don't expect any wonders. Regarding bin smoothing, I've never understood the added value of this feature and to my opinion it will negate the effect that precise intersection will have. Don't focus too much on one opponent. If a 10% gain against one results in 2% loss against 10, it will perform worse in the rumble. --GrubbmGait 08:35, 7 March 2011 (UTC)

You might try just borrowing the segmentation from a bot like CassiusClay or Dookious and seeing how your gun does, for a clearer idea of what's wrong. Gun 5 is no segmentation and only firing waves, and performs the best? Given that, if it were me, I'd look for a major bug or issue holding you back, because that seems really weird. Like maybe your segmentation isn't working how you think it is, or you need to use multiple buffers - a low segmented one so you always have some data to work with, and a high segmented one so you can learn in more detail is a very nice setup. --Voidious 14:01, 7 March 2011 (UTC)

I found the bug, that is I found one bug and switched the segmentation of gun three to use lateral velocity instead of the enemy's relative heading and velocity giving gun three a score of about 81. Then I tried using the ratio of max to average in the gun segments and the number of waves in that segment to choose which gun to use (Brilliant 0.1). As you can see it helps, but I am wondering: I segment on acceleration--change in velocity--as opposed to what I shall call pseudo-acceleration--change in speed. What do other people use?--AW 01:41, 12 March 2011 (UTC)

Cool, nice work. =) In Dookious I used 3 segments, 0=decelerating, 1=same speed, 2=accelerating. A delta < 0.5 I considered same speed. Diamond doesn't segment, it just uses the raw decel/accel value, this tick minus last tick. But yes, I would use speed instead of velocity - going from -8 to -6 is really deceleration and should be the same as 5 to 3. --Voidious 02:47, 12 March 2011 (UTC)

Congrats on it working well now. Well, if you don't normalize velocity and acceleration in the same manner, then you'll end up with subdivisions in the data that don't actually mean anything. The key is that both Robocode and virtually all robots treat the "back" and "front" of the robot equally. The usual way of handling this symmetry to multiply both the acceleration and velocity, by the sign of the most recent non-zero velocity. This effectively takes the absolute value of velocity, and makes sure acceleration is from the same perspective. In general, when dealing with symmetries, everything normalized across the same symmetry (i.e. back vs front) should be normalized the same way. --Rednaxela 02:49, 12 March 2011 (UTC)