Editing Pugilist/ChatLog20040501

Robo Home | Changes | Preferences | AllPages

==== Questions and comments as of May 1 2004 ====

What's new in 1.11? --[[David Alves]]

Mainly bugfixes. You can't believe how many bugs I have managed to produce when trying to realize a simple idea like WaveSurfing. I have thought I am on completely the wrong track quite a few times. But [[Jamougha]] has given me some hints and also [[Jim]] has helped me sanity check the concept. To keep codesize down, so that it fits together with the second best TC gun in a mini, I have used state where I otherwise would have used different lists and such. This is a dangerous path to walk of course since it can be hell to debug state dependent code.

Tonight I have found and corrected a major bug though and also applied an interesting bin-smoothing technique that [[Jamougha]] hinted me about. Both things seem to give me a much better movement. Pugilist now can consistently beat [[Raiko]] in long battles. I'm tuning it against Raiko right now actually. I figured the best gun in the Rumble should be the right choice when tweaking my movement. =) Strange tuning too... The movement is pure theory now, except for this funny magic-number I stumbled across by accident... I'll probably release Pugilist 1.2 later tonight. -- [[PEZ]]

A cool graph showing Pugilist's movement profile in the low velocity segment:

http:/robocode/uploads/pez/PugilistLowVelocity.png

That's the profile as measured from waves carrying real bullets. "Virtual" waves give this picture:

http:/robocode/uploads/pez/PugilistLowVelocityVirtual.png

Talk about possibilities in punishing bots firing waves every tick! =) -- [[PEZ]]

A little off subject, but is TGrapher for Tityus?  Would you consider writing a FloodGrapher 2 plugin for it? -- [[Kawigi]]

Well, a public grapher for Tityus would give people the perfect tool to tweak their movement to trick Tityus, wouldn't it? But I'll consider it. I have actually started to do it several times, but I always get stuck and start tweaking my bots instead. =) -- [[PEZ]]

[[Aleph]] has some problems against this bot. Is [[Pugilist]] owner of an [[Aristocles]]-gun? If so you should probably change it until you get to the top of the TargetingChallenge (The [[Raiko]]-gun isn't such a huge problem). =) -- [[rozu]]

Yeah, Aristocles gun. And I fixed the bug I had introduced somewhere in the process so it should be quite effective. Not against Aleph though I would have thought. -- [[PEZ]]

Just to show what I mean with big GF1 spike:

http:/robocode/uploads/pez/Pugilist1.3.1.png

If I can sort that out I should be able to collect a few more points I think. Anyone has the antidote for DevilFISH by the way? http://rumble.robowiki.net/servlet/RatingDetails?game=minirumble&name=pez.mini.Pugilist%201.3.1 aghh...

-- [[PEZ]]

I once had the same. In my case it was the result of inaccurate movement prediction. If you have a zero at the end of your stats array and your prediction tells that you can reach this GF you will probably chose it because a zero is allways nice. but in reality you will never reach the desired GF it's just too far away. the result would be a bad hit at GF1. because of this I implemented the exact version of predicting my movement. -- [[rozu]]

Thanks! This is what I suspected some. My bin smoothing should take care of some of it I had hoped though. I will have to think even harder on how to solve it. An exact prediction doesn't really fit in this mini so I must do something else. I'm open for suggestions. -- [[PEZ]]

smoothing is fine but in this case the difference between the spike and some of its neighbor might be to big.
Can you remember GlowBlowAPM? It isn't really a big thing. most of the features in FuturePosition are not necessary for this. RaikoMX should have some good approximations on future position I think. I wasn't able to correct this otherwise... -- [[rozu]]

Are you still multiplying by 1.2 like in Aristocles's gun? If so your GF1 is just plain unreachable no matter how accurately you predict. -- [[Kuuran]]

I think the cure to DevilFISH is fixing that GF1 thing. -- [[Kawigi]]

Rozu, RaikoMX future prediction is huge compared to what I can fit. I do hope I can fix this somewhat without something like that...

Kuuran, no, I'm using a calculated maxEscapeAngle without multiplying with 1.2 (and, no Aristocles doesn't do that multiplication thingy either) but the enemy waves do look kinda wide in PugilistGL so I'll check out if this could be the source of error.

Kawigi, yeah, probably. Although the profile shouldn't look the same against a linear targeter it probably does if P has a blind spot there... -- [[PEZ]]

Kuuran! You have given me new hope. I wasn't using a calculated max escape angle at all. I was using 1 all the time. Here's hoping. -- [[PEZ]]

No, that didn't help. And I think it shouldn't much since it's a reversible function. I'm working with coordinates all the time until I need to know the visit count. It probably is around the more difficult problem of predicting accurately enough... Ughh-- [[PEZ]]

You could try multiplying a small fudge factor into which bin you increment to solve not being able to hit that last bin. Should be within the failure rate acceptable for a mini. If there's some place to do a Math.ceil() that's a useful way to do the same.

(edit) Probably not neccesary, unless this is one of the bugs you recently squashed...

ew.bearingDirection = robotBearingDirection * maxEscapeAngle(ew.bulletVelocity) / (double)MIDDLE_FACTOR;
	if (getVelocity() != 0) {
	    robotBearingDirection = sign(getVelocity() * Math.sin(getHeadingRadians() - enemyAbsoluteBearing + Math.PI));
	}

Unless I follow your code incorrectly this returns an incorrect direction alot of the time. enemyAbsoluteBearing is his absolute bearing relative to your position, your heading minus that is just his bearing relative to your heading. What you need is your heading minus your absolute bearing to his position, so replace enemyAbsoluteBearing with some way of finding your absolute bearing to him. -- [[Kuuran]]

I'm not sure I quite understand this. That's an old piece of code. It looks a bit different in the current relase (check [[PugilistGL/Code]] for an up-to-date version). However, I think it does about the same thing and thus should have the same flaw (whatever it is). You're not just missing the "+ Math.PI" part, are you?

Anyway, if I remove my ridiculous attempts to compensate for the error in my future forward position estimate it looks like (in the GL output) the approximation is remarkably accurate. I tested by letting P move GF1 all the time and when the wave hits it seems like P is very close to it's guess of future forward position. This makes me wonder... Could it be my reverse position guess (which I know is less correct than the forward one) that causes this GF1 spike. I can't figure it out...

-- [[PEZ]]]

D'oh, didn't even see it when I was reading the code, sorry. Yeah, that's right. Sorry about that. -- [[Kuuran]]

Don't be sorry. I'm happy you take time to try help me! I have had more obvious bugs than that in this bot so never doubt pointing out even very unlikely things. =)

I am truly stuck here. I think I must try with a more precise prediction algo. Even if it doesn't fit I could then know better if this is the problem. Unless you people out there have some more things I could try. What I would need is some ideas on how to test. Since I have GL to aid debugging I can test about anything. But designing good tests is sometimes harder than you think... -- [[PEZ]]

It seems I might have been a bit too smart for my own good. If I remove the bin smoothing I get a very different profile. Still some overuse of positive factors but not like it is with bin smoothing active. It could be that I have a bug in the smoother, but it seems not when I look at the code. Which means I might try without smoothing now a while. -- [[PEZ]]

So, this is how it looks if I use fewer bins instead of bin smoothing:

http:/robocode/uploads/pez/Pugilist1.3.2.png

I guess it means I did something wrong in the smoother. Anyone knowledgable could check the method on the PugilistGL/Code page. Also the graph isn't as wide as it was with bin smoothing on. More important, this version doesn't seem to perform as good... Strange. -- [[PEZ]]

Seems to be you'd want to use the square of the distance between factors, not the square root. With the square root you're putting fully a half of the data from 4 bins away into a given bin. The reason for the GF1 spike is probably that every bin has bins on both side to get extra data from (ie you're getting 1/sqr(2) of the data from the bin immediately before and after any given bin) except for the start and end ones, which are only being pumped from one side, that'll naturally deflate them relative to the center data. -- [[Kuuran]]

If I use the square of the distance I get data from fewer bins away you mean. I.e. less smoothing. I have experimented with some different coefficients. The just released version (1.3.3) uses linear smoothing.

The part with starving the end GFs makes so much sense! But what should I do instead to compensate you think? -- [[PEZ]]

Add unreachable GFs to both sides. They will gradually be raised up by smoothing, so after a while GF1 / GF-1 won't be so appealing. That's the cheap-codesize way to do it. A slightly better way (though it would cost more bytes) might be to copy the values for GF1 / GF-1 into those unreachable bins. -- [[David Alves]]

Yeah, that makes sense. I only need do it beyond GF1 I think. GF-1 is pretty unvisited as it is anyway. -- [[PEZ]]

OK. I don't bin smooth when I populate the visit counts. Instead I do it when I read it. This was an idea [[Jamougha]] gave me so it is brilliant of course. Anyway to give GF1 a more fair chance I have changed from this:
<pre>
 double smoothedVisits(int index) {
	double smoothed = 0;
	int i = 0;
	do {
	 smoothed += (double)visits[i] / (Math.abs(index - i) + 1.0);
	 i++;
	} while (i < Pugilist.FACTORS);
	return smoothed / (distanceToTarget() / bulletVelocity);
 }
</pre>
To this:
<pre>
 double smoothedVisits(int index) {
	double smoothed = 0;
	int i = 0;
	do {
	 smoothed += (double)visits[Math.min(Pugilist.FACTORS - 1, i)] / (Math.abs(index - i) + 1.0);
	 i++;
	} while (i < Pugilist.FACTORS + 2);
	return smoothed / (distanceToTarget() / bulletVelocity);
 }
</pre>
Linear smoothing at the moment. I might change back to square roots if this works. It is late night here and I am way tired. Someone less dozy can tell me if I am doing the right thing?

-- [[PEZ]]

YALT smooths when reading stats too, for both offensive and AM guns. It figures out how many bins wide the bot is at a given distance, then smooths using that radius. I think it helps accuracy at close range. Reading that again... how does using bins you can't reach make GF1 less desirable if you only smooth when you read? They'll always be 0, no? --[[David Alves]]

It's not that I can't reach GF1. It's that it get's a lower visit count just because it is at the end. Then P will want to go there. Or something like that anyway. Wait, maybe to get the above fix to work I should use true max escape angles instead of the always too-wide one I'm using now... -- [[PEZ]]

PEZ, my client is having some problem with Pugilist:
<pre>
Could not download bot pez.mini.Pugilist_1.3.1.jar
Ignoring pez.mini.Pugilist_1.3.1.jar: .\pez.mini.Pugilist_1.3.1.jar (O sistema n
缹 pode encontrar o arquivo especificado)
Ignoring pez.mini.Pugilist_1.3.1.jar: .\pez.mini.Pugilist_1.3.1.jar (O sistema n
缹 pode encontrar o arquivo especificado)
</pre>
(the message in portuguese means something like "the system couldn愒 find the specified file")... -- [[Axe]]

Disregard that message. It's because I downgraded. Now the version on the participants list doesn't match the currently uploaded bot on the repository. ... All attempts to improve Pugilist 1.3.1 has failed. I hate Robocode at the moment. =) -- [[PEZ]]

Yep. I know how u feel... I'm stucked with Okami, and the tests with SilverSurfer didn't worked... I have some ideas for the weekend, but isn't anything brilliant, i think. Maybe if us WaveSurfers from the "2nd group" start a more intensive idea sharing... -- [[Axe]]

Maybe it's the first grade surfers that should start sharing more intensively. "KISS" and "you'd laugh if you saw what I do" doesn't really cut it. =) -- [[PEZ]]

I'm enjoying trying to figure it out, and enjoying the competition between us as we keeping knocking each other out of that 10th place slot. Right now I'm winning by .58! :-D --[[David Alves]]

I'm enjoying it too. And actually when I had written the above I got a laughably simple idea on a thing to try. Let's see if I laugh also after I have tested it. Right now my daughter is occupying the PC. Didn't check that latest game for Mac compatability... And now I'm addicted to RobocodeGLV014 so I'll have to wait. =) -- [[PEZ]]

No doubts. The competition is great! And is even greater when u do it without external help. I remember when Okami beaten Iiley's scores and PEZ's one-man-army... Great satisfaction... I went to my wife with a great smile in my face saying: "I have beaten PEZ.. I have beaten PEZ... I have beaten PEZ..." (Don't know how long this will last, but at least once "I have beaten PEZ..") :)) -- [[Axe]]

Cool. I didn't realized anyone cared about beating me. I feel like the one chasing all the time. -- [[PEZ]]

My laughably simple idea didn't work out by the way. I figured I should try without prediction. Just check the immediate forward and reverse positions, sum up the visits there and choose orbit direction from that info. A very true-to-the-metaphore surfing I thought. But  it seems it was too simple to work. If anyone knows why it doesn't work, please tell. -- [[PEZ]]

I think that this could work fine if you have a "smooth" profile. If I look at my own profile (made by Aleph or Apollon) they are locally really spiky so that there is a high chance to move into a (bad) local minima. You could try it again with the stats smoothed even more (if you do, tell me if it worked). -- [[rozu]]

I was being sloppy in my first attempts. Didn't take the inertia into account at all. Doing it with more care it starts to work quite well. Not as well as with my predictor, but that could be due to bugs and tuning issues. I'll try with more smoothing too. Thanks for that suggestion! -- [[PEZ]]

Jamougha's suggestion when doing this kind of surfing I believe was to check the forward bin and the current bin, instead of forward and backward. Not sure if that will make much difference, though. :) -- [[nano]]

Interesting. I tried with the 2 distance units ahead for reverse and 24 ahead for the forward position. That's assuming I'm moving full speed. Didn't really get it to work though. Trying with prediction again now. Found a bug in my self grapher that I thought would cure the GF1 spike when nailed. Appearantly not... This '''is''' truly complicated stuff any way I cut it. -- [[PEZ]]

I惴 feeling like a real surfer listening all that chat... Didn愒 understood a half of it. Probably because i惴 a newbie in that GF stuff, my cannon was always a PM, and i had to learn all that GF theory from zero to doing my WaveSurfing (probably a lot of problems that i惴 having come from that). Let me understand a thing: what is exactly the problem u r talking about? Choosing the best GF or reaching that GF? -- [[Axe]]

Maybe choosing the best GF that you can physically reach? -- [[Kawigi]]
* so choosing the GF. Correct? -- [[Axe]] (changed, sorry misunderstood.)

(edit conflict!)An example of how i am green in that: I used the max_vel/bull_vell formula (without the sin) to calculate the max. escape angle of my bot. All my movement is based on that (max escape) variable. Some days ago i扉e had graphed it with FloodGrapher. Okami愀 graph is reasonably flat (5.4), but it愀 curve stop a lot before GF 1.0. This was bothering me, and finally yesterday i扉e had found out the reason (at least i think): the bloody sin in the escape angle formula!! Stupid, ain愒? -- [[Axe]]

Strange effect. It probably depends on how you reverse the function. I can use 1, 0.85, (8 / bv) or asin(8 / bv) without it seemingly making any difference at all. -- [[PEZ]]
* Thwe problem is that my WaveSurfing is based in move amounts, and not in probabilities of reversion. If i use only 8/bv, and not asin(8/bv), i惻l never reach the real 1.0 GF... My movement will be ever restricted to something like -0.85 to 0.85, that against good guns is fatal... -- [[Axe]]

do you segment your enemy wave data? (i'm not very good at reading other people's code)--[[andrew]]

Yes. I segment it on low granularity. 3 distance indexes, 2 bullet power indexes, and 4 approaching wall indexes. Well the last one is hardly low granularity, but I think for the implementation in Pugilist it's important to know how much wall smoothing i am forced to doing. If it wasn't a mini I would start with no segmentation and then add segmentations as i collect data. Because data collection is slow sinc P only updates the stat bins when it is hit. -- [[PEZ]]

For now i惴 using only distance segmentation, 6 slices of 200 wideness. -- [[Axe]]

another question: at what distance away from you do you consider enemy waves to be waves that you could surf? right now i am using 2*(20-3*this.bulletPower), but i am having problems with it and want to know what other people are doing. --[[andrew]]

That sounds like it will cause problems. :-)  First, only surf waves which were launched on a turn when the enemy fired, if you're not already doing that.  Then you want to search through your list of enemy waves until you find the one which is closest to you, but hasn't yet passed you; compare the distance the wave has travelled with the distance from the wave's origin to yourself to get this.  I thank that will provide quite a big boost to your movement. -- [[Jamougha]]

Agree, thats exactly the way i惴 doing. It愀 like surfing, you have to concentrate in the wave that u are actually surfing, and not on the ones that are far. -- [[Axe]]

Current Pugilist (1.3.6) surfs all bullets in the air. At the moment unweighted. It just sums them all up. Since it's forward sensor is some 50+ pixels ahead of it all the time it stops surfing waves that have come closer than some limit. (Can't remember the exact limit at the moment.) -- [[PEZ]]

"It's YAYALT"? --[[David Alves]]

Yeah! =) Quite successful too surprisingly enough. I don't know if I dare plug in the flattener again... -- [[PEZ]]

flattener, what's that ? ;) -- [[rozu]]

=) I thought of you when I saw Pugilist still work with the flattener removed. Though it only gets 20% in the flattener challenge so I'm not quite up to [[Aleph]] standar yet. -- [[PEZ]]

is this flattener just somthing like Math.random()<.02 , which you would have in addition to the wave surfing? My attempt at wave surfing has left me with huge problems against any guess factor guns. Maybe i should add a flattener? --[[andrew]]

No, the flattener is using EnemyWaves to collect stats on P's own movement and then WaveSurfing on those stats. The adaptor uses EnemyWaves to collect stats on where P is being hit and then WaveSurfing on those stats. [[Aleph]] and [[Apollon]] both prove that you don't need the flattener part to get far with WaveSurfing. (Though I suspect it makes a bot more vulnerable to good pattern matchers than a combination of flattening and adaption does. That's just a gut feeling. It might not be true.) -- [[PEZ]]

The latest version of [[Aleph]] has such an array (as you said because of the fast learning guns like PM's) but it wouldn't fit into [[Apollon]]. -- [[rozu]]

OK. P has been badly trashed by [[Lacrimas]] up until now (in fact that's true for all my bots). P 1.4.4, with some luck, can at least tie Lacrimas over 100 rounds. Here's hoping. -- [[PEZ]]

P 1.4.5 is back over 1900, tell us about it! -- [[Alcatraz]]

do you weigh all of the enemy waves in the air while surfing?--[[andrew]]

Nothing much to report here. I don't do the WaveSurfing/ReverseForwardSensor thingy any longer. It's back to not-so-precise predicted destinations. Also found a bug of course. Not '''the''' bug yet, but maybe soon. =)

Yeah, I weight all the bullets in the air while surfing. Not all waves though, since I fire enemy waves every scan. These are used for quickly drawing the grah which 
the surfing then tries to flatten.

-- [[PEZ]]

Could you put the ratings next to version numbers so we can watch your climb to the top? :-) --[[David Alves]]

OK. It seems there isn't data for all version. But for the ones there was I have now updated the log with rating points. Some versions didn't get to fight 500 battles before I removed them though, but it's an indication anyway. N.B. The rating points are from general rumble. Just to contradict what I stated on TheBestBot page. Anyway, I think [[rozu]] closed my window of opportunity climbing to the mini-top with his [[Apollon]]. But if I get the bug out [[Raiko]] might have two slots distance from #1. =) I've been chasing the bug for so long now though. I'm not sure I will have the stamina to pursue it much longer. It's frustrating business... -- [[PEZ]]

Yep. I'm giving myself a few days out from robocoding too, all my efforts with SilverSurfer only seems to trash it. I think i need a couple of days not thinking 'bout it, so my subconscious can have time to digest the info (and hopefully give me the answer). Although, seems that i can't stay too far (i'm writing this, right?)... -- [[Axe]]

with 126 battles is prabably too soon to say this, but your latest Pugilist seems much better (~1930), found the problem? -- [[Axe]]

Way to early to say where it will end up. But ''the'' problem isn't located yet. P 1.4.6 is just 1.4.5 without flattener. Everything else is the same. -- [[PEZ]]

If this help your bot just will prove how weird things are :). Btw: that test with the mirrored gf hits didn't work. I'm gonna try another thing: Wall smoothing. Probably my bots are one of the few without it. When i graph it with TGB the wall segments are really bad. -- [[Axe]]

Why would that be weird? Avoid getting hit is the goal, right? Flatness is just one of several possible means. You don't wall smooth yet? Guess you have some points to collect there dude! -- [[PEZ]]

i don't understand all this flattener talk. if you only keep track of,and avoid, the guess factors you have been hit at, you will get a flat profile against guess factor guns. but against other types of targeting (linear and head on), you don't WANT a flat profile. --[[andrew]]

You're absolutely right. Flattener is a bad term for this. We're talking about AdaptiveMovement, not CurveFlattening. Perhaps adapter would be a better word? --[[David Alves]]

@Andrew: We are talking about the gfs after taking out the "bad gfs". Obviously you wont have a flat profile against HeadOn, but after running a lot of rounds of an GF-AM against a good GF gun and not getting a flat profile can probably tell you that something is wrong. @All: I think that a flattener isn愒 required, but it can be a way to avoid beeing catched in patterns, and i have a feeling that it can help us to avoid the hits after the GF gun discover that the last hitten gf isn愒 a good gf no more. -- [[Axe]]

Welcome back to the top 10, dude! -- [[Axe]]

[[Pugilist]] has both a flattener and an adapter. P 1.4.5 has them both in action. P 1.4.6 has the flattener disabled. -- [[PEZ]]

This really seems strange to me. But another fact: Okami doesn愒 have flattener, i only introduced this concept in SilverSurfer. Every thing is pointing against flattener. Btw: did u graphed your 1.4.6 and 1.4.5 against TGB? If u did can愒 u show us? I惴 a bit curious. All my tests says that better (ranked) versions have flatter graphs, want to know if you confirm it. -- [[Axe]]

The graphs for 1.4.5 look pretty much like the one above. Haven't graphed 1.4.6. Feel free to do it. =) I guess it won't be flat. Everything points against flatteners? Let's hope [[Jamougha]] doesn't remove it from RaikoMX then. =) -- [[PEZ]] 
* Yep. Seems that i惴 going crazy, don愒? First i defend the flattener idea, and some lines above i reject it completely. Probably is the RobocodeStressSindrome :) -- [[Axe]]

can someone just reiterate this for me? a flattener, or adapter, is changing where move based on your movement data collected from enemy waves. wave surfing is changing where you move based on which guess factors you have gotten hit at. is my idea of the two correct? --[[andrew]]

Adapter: Avoids guess factors where real bullets impacted the bot. Flattener: Avoids guess factors where EnemyWaves impacted the bot. -- [[Kuuran]]

Yeah. Look at the Pugilist source code. It fires EnemyWaves every scan (which is almost equivalent to every tick). When the waves hit P it registers a visit. Each time P is hit by a bullet it finds the corresponding wave and registers a hit. WaveSurfing is then used to avoid overvisiting certain GFs (flattening) and avoid visiting Gfs where it has bin hit (adapter). In PPPugilist this is two different stat arrays. But in Pugilist it's the same. Just that a hit counts as 1000 visits. "Switching off the flattener" looks like this in P:
<pre>
class EnemyWave {
...
 public void test() {
 if (passed(-18)) {
 // registerVisit(1);
 }
 ...
 }
...
}
</pre>
Which also means it is completely pointless to fire enemy waves every tick of course. But it makes it easy to enable the flattener again. =) -- [[PEZ]]
----
Interesting experiment. P 1.5.2 is the same as P 1.5 only with some different tuning of the sloppy wave surfing prediction. I tuned it against RaikoMX to the point where I get 46% over 500+ rounds. (And can with some luck beat it over 35 round battles). However, this translated to a 70+ drop in general rumble rating. It also increased the GF1-spike a lot. I guess RMX has something of a blind spot there. In any case, I can't recommend tuning your bots against RMX. =) Anyone can suggest a single bot that could be good to tune WaveSurfing against? -- [[PEZ]]

I would say any of the graphing bots, since the main objective of WaveSurfing is movement profile flattening. FloodGrapher is, of course, the best candidate. The majority of the current GF guns are based on Kawigi's code, I believe. If you choose to tune against other WaveSurfing bots (or other AM types), concentrate on the enemy's hit rate, not on the match scores. -- [[ABC]]

Why so? Wouldn't those be quite eqivalent given that my gun doesn't change? -- [[PEZ]]

In the long run yes (1000+ rounds), but short battles can be very misleading... -- [[ABC]]

I'm running quite long battles. 250 rounds. Maybe I should increase that... -- [[PEZ]]

I'm trying with [[Shadow]] now anyway. It's not as fun though since Shadow walks right over P like it didn't exist. =) -- [[PEZ]]

[[Shadow]] also steps on RaikoMX like it was an "average" bot :).  The top ranking positions are not as much representative of the relative strengths as they used to be. It's a whole new world, the reign of the dodger. :) -- [[ABC]]

Yeah, without some sort of anti-AM capability [[Shadow]] is a severely depressing bot to test against. :-)  I've done most of my testing vs [[FloodMini]] (I guess it sort of shows) [[Sedan]], [[Quest]], [[Barracuda]] and [[Wesco]], with [[BlestPain]] and [[Aleph]] as my controls.

I definitely wouldn't test against anything with a good anti-AM gun, e.g. my scores against SandboxDT got worse when I fixed my movement.  The bug was just enough to throw it off. -- [[Jamougha]]

Mostly [[Kawigi]]'s gun all of those. What did he do to deserve that? =) I have used FloodMini too once. For an earlier version of [[Tityus]] movement. And that ended up crap. Anyway, [[Shadow]] wasn't exactly a good choise either.  I think it might have to do with me tuning instead of fixing my movement... -- [[PEZ]]

----
Anyone want to predict where the latest tune of P (1.5.3) will end up? I guess it can stay at 1924 as the two (non-failure) predecessors. But it's details sheet look very "red" in the PBI column after 130 battles so it might have met most of it's problem bots... Which are legio it seems. -- [[PEZ]]

Hmmm. Well, it's stronger against many bots but seems to have grown even more vulnerable to PM guns. ... -- [[PEZ]]
----
I think that your latest version (1.5.4) might have a bug:
|mld.Infinity_2.1 |36.5 |1 |21-4-2004:18:21 |86.8 |-50.3 |
--[[Axe]]

Yes, it must be a bug. This is a 100 round battle I just ran:
<pre>
1st: pez.mini.Pugilist 1.5.4 14666	4900	980	7295	1451	39	0	98	 2
2nd: mld.Infinity 2.1 806	 100	 20	 667	 8	10	0	 2	98
</pre>
Hmmm, if someone notices Pugilist misbehaving, throwing exceptions or the like. Please let me know. Thanks [[Axe]] for alerting me to this.

-- [[PEZ]]
----

Seems that the less code version is working. My WaveSurfing "bug" was really a lot of minor bugs and bad "assumptions"... Probably the same with yours. Btw, are u using something to compensate your bot width when hitted? -- [[Axe]]

Yeah, some 13 points or so was gained by using less code (the other 4 points was from the bug-fix). Now I only need some 5 points or so to grab the #7 spot from [[Okami]]. No, I'm not compensating my bot width when hit. I think. I don't really understand what you mean with it acctually. Is it something I should consider? -- [[PEZ]]

This was one thing that worked really well for me. When hitted, i mark not just only the gf where i was hitten, but also the neibour gfs that are inside a circle (with the diameter of the bot width) with center in the hitted gf. That is, all gfs that reside inside a bot shape centered at the hitten gf (Btw, i use 50 for bot diameter). It worked for me, it愀 easy to do, so u should made a try... About Okami, i惴 affraid that the next version would be released soon with the SilverSurfer improvements (So i expect above 2K). -- [[Axe]]

I think I do something like that then. But I do the smoothing when I read the data instead. Think that it's roughly equivalent? If you incorporate SilverSurfer improvements in Okami, then maybe you'll remove SilverSurfer? If so it's still #7 for P if I manage to find 5 points somewhere. =) -- [[PEZ]]

I think that your bin-smooth is usefull to smooth only, and it doesn't take in count the bot width, do it?
The idea behind the "bot width compensation" is that (depending on your distance and segmentation) the neighbour gfs must be avoided. This is more true the closer you get to the enemy. I was taking a look at P code... U use 27 bin factors, while i use 95 (or so), so that "bot width compensation" might be more critical to me - since the arc slices are smaller for me. 
Taking a look at your results, calls me attention your result against DevilFish. He is a close-combat bot (as u well know), and P is getting only 70% (SS is making it above 90%), this might indicate a failure against close-range... I still think that u should try the compensation. -- [[Axe]]

I have also a question for u: I am thinking about trying a wall-segmentation in SS, but i'm not pretty sure about what to segment. I'm thinking about three segs: aproaching-wall, getting-away-from-wall and neither-approaching-or-getting-away. This seems good to u? I also have a doubt about the distance that i start considering it near a wall, 100 is a good parameter? Btw: I decided to update Okami latter (when i'll start a hudge development of a new type of cannon in SS). It's not fair to the others having two similar bots in the top positions. -- [[Axe]]

It's not fair having two too similar bots in any position I think. =) I can see how the bot width compensation gets important for you when you have that many bins. For me I don't think I can fit it in Pugilist. I have only 53 bytes left as it is...

Wall segmentation. I have never seen getting-away-from-wall give any edge. I think aproaching-wall is the most important. But there is the TargetingChallenge for us to experiment and have answers. Make six or so versions of your bot with different wall segmentations and see which one is best.

-- [[PEZ]]
* Wall segmentation: i was talking about segmentation in movement (I have no GF gun. Just one PM.)... So the TargetingChallenge won愒 help. -- [[Axe]]
** Well, I just removed the wall segmentation from P's surfing and it didn't seem to matter for its performance. Although that's hard to tell for sure since I changed both gun and movement in the same release. (Now PEZ must punish himself badly...).

I forgot that P is a mini... I used that amount of bins because i wanted a good resolution at great distances. But you still have a problem at close range, where 27 bins may be too much (at dist=300 and under fire pw=3.0 i have calculated slice=~23)... U can trying to reduce your segmentation (i think that Jam uses something like 17 bins only) or also try something more sofisticated: different qtty of bins depending on your distance segmentation (fewer if closer). That probably won愒 need that much code. -- [[Axe]]

If you want to end up using fewer bins at a closer range, define your maximum angle for guess factor based on range, probably as a 1/r function.  This would mean you own the same number of bins at any range range (er...  weird way of saying range segmentation of engagement distance...) but you would only use as many as fit within your guess factor angle.  You'd just end up with bins, as you got closer, that never get any hits.  -- [[Goofy]]

Thanks for your suggestions. I have done all of that, and then some, in my use of GFs for targeting (where it never have helped a bit). But I the smoothing I do is massive so I do not think I can gain all that much by adding these calculations to the mix. I guess I can try. But that would mean P grows out of its mini suit and... Well, I kind of like that P is the first surfing mini. =) -- [[PEZ]]

7th! Congrats and welcome to the no-bots-land (that hiatus between P and Apollon) :) -- [[Axe]]

Thanks! Yeah, I have wanted to push P into this land for a while now. I still have 33 bytes to spare so some experiments with surfing segmentation might be my next step now. -- [[PEZ]]

As you once said (at least i think that was you), and i comproved in my AM, segmentation is one of the fastest ways to improve your rating. I am curious, how where u segmenting your AM (especially the walls segs)? -- [[Axe]]

Well. As of version 1.5.6 I have removed wall segmentation. But before that I projected my lateral movement from the last tick 13 ticks forward and checked if it was within the field boundaries or not. That made for a segmentation like approaching-wall-or-not. It's the same way I wall segment in [[Aristocle]]'s and [[Tityus]]' guns. Right now  I segment on distance (5 indexes) and bullet power (5). -- [[PEZ]]

Congratulations on your 1950+ score! -- [[ABC]]

Thanks! I had set as goal to reach 1950+ before March's end, this is only 1 month belated. =) All this while I was tweaking my WaveSurfing... That's what happens when you get too satisfied with your perceived gun performance I guess. The good thing is that I might have the same 30+ points to collect with [[Tityus]] and [[Aristocles]] too. And P collected even more in mini. Sweeet! -- [[PEZ]]

Wow, 30 points from tweaking the gun? Amazing. Any idea where those points come from in the ranking table? -- [[ABC]]

And it was the smallest tweak you could ever imagine. No, I haven't checked the details yet. It's about comparing the Details / LRP graphs for P 1.5.6 and 1.5.6.3 I guess. -- [[PEZ]]

Congratulations, 1950+! Almost crossed the no-bots-land in one single jump. -- [[Axe]]

Thanks!

[[ABC]], It seems the gun tweak works against all opponents about equally much. (That's just a rough guess after having only glanced at the details sheets.) -- [[PEZ]]

Gah! I don't have the 30+ points to collect in [[Aristocles]] nor in [[Tityus]]. The last "gun tweak" in P obviously was just about removing a bad (and untested) tweak I must have introduced in P only. Now I must write "never tweak without testing" a thousand times on the black board... -- [[PEZ]]

I know it wont last. So I just had to snapshot this:

http:/robocode/uploads/pez/Pug1.6.2.png

-- [[PEZ]]

1960 points without segmentation for my EnemyWaves. This is quite counterintuitive I would say... -- [[PEZ]]

Do i understand correctly that P dodges ALL GF (without segmentation) that it has been hit at??? --[[deathcon]]

Yes and no. When it is hit it increments the count in the GF it was hit at. Thus it "remembers" ALL GFs, but it avoids the GF where it has been hit the most. Against a good GF gun this makes P avoid different GFs over the course of the battle. And, the current P (1.6.4) does segment the enemy GF hits. Though only in crude distance and bullet power segments. -- [[PEZ]]

Funny that again it was a small gun tweak that made me gain rating points (12+). All my surfing tweaks have only given +/- 5 points at the very most. Now finally P is the strongest mini in the general rumble! And 2K isn't too far away (though I have absolutely no clue where to find the 25+ points I need). With some luck I might brake the 2K barrier in mini with the current version (1990 points after 225 battles). -- [[PEZ]]

Higher and higher! I had a similar experience: after several weeks of frustration, things suddenly start working... I never thought about segmenting the bullets firepower, do you think it's worth (i mean: did it worked for u)? -- [[Axe]]

The idea is just to sort out the EndGame bullets from the rest, since GF guns often do this... I don't think it matters much. If you have followed along it seems like segementation doesn't matter at all for P. Your (SilverSurfer's) case might be different since you release it with pre saved data and thus don't get a learning penalty when you add segments.) -- [[PEZ]]

;-) Hey PEZ, i now see what you mean with 'wavesurfing'; you are surfing your own rating index with the different versions of Pugilist... hehe, just joking, i admire your energy in coding one top bot after another!! --[[Loki]]

He he. If I were, then I would be quite vulnerable to head-on targeting I guess. =) Thanks for the words of encouragement. I feel like I am constantly avodoiding the #2 spot. Well, VertiLeach kept it's #1 position for quite a while, but that's old merits! -- [[PEZ]]

1997 with 100 battles, looking good! :) -- [[ABC]]

What?? Well, now it's down on 1965 again. But I almost touched ground! It's a sign maybe. =) [[PEZ]]

Must be a sign. P's detail page looks very impressive, wins against RaikoMX, Aleph and Apollon, and very good scores against pattern matchers... -- [[ABC]]

Yeah! That's a crazy details sheet. Only losses are against [[Okami]] and SandboxDT so far. Nothing to be ashamed about. I think I have gotten it very balanced. The WaveSurfing probably has lots of room for improvement still, but the gun must be pretty strong to give those pattern matchers such a good fight. Though now I have 2 bytes to play with again and I probably can't do much but tune it now. Let's see if I can tune it beyond that 2K line... -- [[PEZ]]

Hmmm, now [[Tron]], SilverSurfer and [[Lacrimas]] where added to the list... Well, it still are strong bots. And Lacrimas is always a very hard bot to beat for my bots. -- [[PEZ]]

Iiley's bots are allways a problem to me too (and probably to a lot of people). -- [[Axe]]

Indeed. But at least now P eats [[Cigaret]] for lunch! -- [[PEZ]]
* turns it into a chocolate cigaret! :) Cigaret & CigaretBH are still a LOT of trouble to me. -- [[Axe]]

Btw: Okami, SilverSurfer & Tron have PM guns (think that Iiley's bots too, not 100% sure) and DT seems to have a special Anti-AM gun (again not 100% sure). So is expected that they give you more trouble. -- [[Axe]]

Lacrimas and BlestPain use GF guns, but Cigaret and CigaretBH (and most of the rest) use a pattern-matcher that uses waves to get a shot bearing instead of actually projecting movement. -- [[Kawigi]]
* Humm... After getting completed my WaveSurfing I was thinking to do a gun like that. And i was thinking that it would be an "original" idea... Completely mistreated... Now i can understand why these bots are so harmfull. Iiley is great! It愀 a pity that he isn愒 active in rc anymore... Thanks for the info, [[Kawigi]]! -- [[Axe]] 
** One thing you could experiment with that's still original in a Robocode context is either a highly-segmented guess-factor gun or a modified wave multiple-choice pattern matcher using the K-Nearest Neighbor idea, with K= some reasonable number, like 10 or 20 once you have data. -- [[Kawigi]]
With SilverSurfer and [[Tron]] P faces both PM guns and anti GF WaveSurfing. It's bound to be tough. =) -- [[PEZ]] 
* I hope so :) -- [[Axe]]

Summary:
Consciousness check: 5 * 4 =
This change is a minor edit. Send email notification that Pugilist/ChatLog20040501 has been changed.
(Visit Preferences to set your user name.)

View other revisions
Robo Home | Pugilist | Changes | Preferences | AllPages