Archived talk:Pugilist 20040501

From Robowiki
Revision as of 20:37, 29 May 2009 by Voidious (talk | contribs) (migrating from old wiki)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search
Pugilist Sub-pages:
Pugilist - Version History - Help Requests - Guess Factor Chat - PugilistGL - PugilistGL/Code - Archived Talk 20040501 - Archived Talk 20090529
       Archive        This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.     

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: 

    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);
    }

To this: 

    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);
    }

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: 

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
Òo pode encontrar o arquivo especificado)
Ignoring pez.mini.Pugilist_1.3.1.jar: .\pez.mini.Pugilist_1.3.1.jar (O sistema n
Òo pode encontrar o arquivo especificado)

(the message in portuguese means something like "the system couldn´t 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´m feeling like a real surfer listening all that chat... Didn´t understood a half of it. Probably because i´m 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´m 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´ve had graphed it with FloodGrapher. Okami´s graph is reasonably flat (5.4), but it´s curve stop a lot before GF 1.0. This was bothering me, and finally yesterday i´ve had found out the reason (at least i think): the bloody sin in the escape angle formula!! Stupid, ain´t? -- 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´ll 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´m 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´m doing. It´s 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´t 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´t 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´t 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´t u show us? I´m 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´m going crazy, don´t? 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: 

class EnemyWave {
...
    public void test() {
        if (passed(-18)) {
            // registerVisit(1);
        }
    ...
    }
...
}

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: 

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

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´s easy to do, so u should made a try... About Okami, i´m 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´t 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´t 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´s a pity that he isn´t 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

You cannot post new threads to this discussion page because it has been protected from new threads, or you do not currently have permission to edit.

There are no threads on this page yet.
Retrieved from "http://robowiki.net/w/index.php?title=Archived_talk:Pugilist_20040501&oldid=7846"