Archived talk:SilverSurfer 20060602
- SilverSurfer Sub-pages:
- SilverSurfer - Version History - Wave Suffering - Help Requests - Archived Talk 20060602
|
This is the bot that i´ll use to test new ideas, David inspired me to do this with his JALT.
Just like the original Silver Surfer, i´ll send him to seek the universe for anything that can feed me. Guess who is Galactus? -- Axe
I inspired you? *cough* inspiration *cough* :-D --David Alves
You know, it's really not neccesary to pimp that page, let them come :P -- Kuuran
Yeah I'm a loser like that. :-P --David Alves
Kuuran is just waiting for someone to make him and inspiration page. -- Kawigi
I'm not really aware of anything I've inspired, so I'm not exactly holding my breath on that one... :p I talked about some stuff pretty similar to Nemo before it was released, I think that's about the extent you could go, and Nano is more than capable of coming up with Nemo without my inspiration ;) -- Kuuran
Although I needed to egg him on a bit to finish Nemo 2 ;-) -- Kawigi
What really did it was that lateral-velocity mirroring. Bloody brilliant at 10 bytes. And yes, I probably wouldn't have finished or released Nemo 2 without that chat session. ;) -- nano
btw: David, don´t u think that i had inspired u too? Afterall why did u took off from the battle your HeadOnTargeting bots? ;-) -- Axe
I have a question to u all robocoders: I am testing in version 1.01 pre-saved data, is this considered unfair? -- Axe
i think no, because many bots are using pre-saved data. we have to say clearly if it is allowed or not and then one could modify RR client to delete automaticaly bot.data directories, but till then it is and should be allowed imho. --deathcon
Hella yes! We have decided about that before you entered the game Axe. Pre saved data is considered a bit cheesy, but it's a valid strategy for sure. -- PEZ
Thnx. Let´s see if it works for me... -- Axe
That's one good looking details sheet! http://rumble.robowiki.net/servlet/RatingDetails?game=roborumble&name=axeBots.SilverSurfer%201.02 I think you have something really good in the coming there. You're strong against the strong and against the weak. -- PEZ
Hope so, but I think is too soon to say something, my tests with FloodGrapher wasn´t exactly perferct... -- Axe
Version 1.03 is another rotten version, argh! Seems that i´m becoming an expert on trashy versions... -- Axe
Hey! I'm that expert. You're just a novice in that game. =) -- PEZ
Just give me time, u are underestimating my trashing capacity, there goes one more... :))-- Axe
OK. So 1.06 proves you can at least try compete with me in trashing capacity. =) What's this new system about then? -- PEZ
I said you... It seems that everything that i try trashes it. I´m testing variations on what-criteria-do-i-use-to-choose-bad-gfs. This version has a good thing althought: It seems stronger against weaker (but a lot weaker against stronger). -- Axe
Interesting. I seem to be going in the opposite direction. Making P stronger against the strong and not strong enough against the mid range and weak. -- PEZ
My primary goal for now is to make my movement perfect against HeadOnTargeting bots... I think that the way to get things working in this kind of system (at least in the kind of system i imagine) pass throught beeing HeadOnTargeting bullet-proof. If i ain´t, something is very very wrong.
Your system (as far as i know) works not surfing the current wave, but all the waves in air, is that right? That kind of system probably won´t let u to be 100% precise, but can give u some advantadge against strongest bots (only a feeling).
The fact is that i have only one thing in mind that is 100% sure: we both have a lot of road to travel... -- Axe
Yeah, but I only weight in the "other" waves very little. I doubt it even matters. I don't know why ABC and Jamougha weights in the other waves, but for me it is mainly a (codesize) cheap way to choose the closest wave. I agree a system that works should be close to 100% against head-on. But maybe there's something in the fact that RaikoMX is almost 100% against FloodMini. At least in the long run. Food for thought. -- PEZ
BTW. Later Pugilists are pretty good at taking care of head-on targeters. -- PEZ
- I know. 96.8% against HawkOnFire. That is very good indeed, but i´m talking here about perfection, RaikoMX & Shadow makes it 99.6%... This means being hit only in blue-moon situations. And there is nothing absurd to me that 99.6%, if things were working i should score something above 99%. Obviously they aren´t for me ;) -- Axe
[[Pugilistrz.HawkOnFire_0.1 96.8
P should get something like 99+ too if things worked. Since default for P is to move GF1 until it has data in a segment. Or, that's how I intended it. I think, in practice it does other things. =) But I think 99.6% against head-on, the way RMX is built is just an effect of carefully choosen default behaviour. It probably doesn't get a score like that against some other fixed-GF targeting methods. So achieving 100% against head-on is just pragmatism, not perfection. Perfection is to give FloodMini only 15 or so rounds out of 1000. -- PEZ
Yes, feeding in a little head-on data at the start helps a lot against head-on guns. I've been working a a little on countering linear targeters more effectively, but the whole idea needs a considerable amount of polish; linearly targeted bullets don't hit the same guess factor much when your velocity is zero.
rozu is really the master of beating head-on targeting, though I've no idea how the heck he manages to make it so precise. Myself, I've found that one of the biggest problems is movement strategy. You have to turn sometime, and if you weigh things up wrong then you'll get hit, one way or another; usually by getting stuck between the wall and a bullet stream. I've probably spent close to half my time just working on when to bounce.
That's what is so great about ABC's method of weighting all of the waves, though. It lets you know when you're cutting things too fine with your wall smoothing. Helps quite a bit against simple guns. It also helps against pattern matchers; the danger against them is that you can get stuck always seeking the local minimum, and repeat your movement over and over until you get hit. Plus it helps you get out to the negative GFs. Real genius. -- Jamougha
Do any of you adaptive movement guys check to see if a bot is firing only at positive guess factors? Seems to me doing that and then avoiding those facotrs would make for a bot that could get 95%+ scores against an even greater range of bots. I think that's what Immortal might be doing, because it can really crush some non-headon bots like SandboxMiniMelee. -- Alcatraz
What I fail to understand is how such low weights can give any of the good effects you describe. Obviously you are right, but I can't intuitively accept it. Let's say you have 3 bins and smoothed values in the closest wave like 120, 250, 400. Weighted with / sqrt(distance) the next wave is something like 2, 2, 3 and next wave is 0.1, 0.1, 0.1. How can that have any effect at all?
I think I have spent 97% of my time with my (failed) wave surfing on dealing with wall bouncing and wall behaviour. The sad thing with Pugilist 1.3.1's relative success is that it creates a false flatness just because it happiliy bounces off of the wall very quickly. Against good wall segmentation it is a SittingDuck.
Alcatraz, good information you share! I can use that I think... Though it is pretty hard to create a negative GF movement as it is. =) -- PEZ
-- PEZ
what's this wall bouncing i keep hearing about? i thought you guys all had wall smoothers. or do you just ocasionaly bounce when you get near a wall instead of smoothing it? --andrew
I certainly have never managed to create a movement with successful NoFearTheWalls. So yes, until you master smoothing and collecting and acting on data perfectly near walls you need to bounce. Choosing when to bounce can make huge, huge differences in the performance of your bot. -- PEZ
very interesting news PEZ. because r2d2 has just been wall smoothing with no bouncing at all. so the idea of wall bouncing is that 20% of the time or so that you are aproaching the wall, instead of smoothing, you reverse directions? --andrew
Cool. You can have many rating points hiding there! Yes, increasing the probability of bouncing is one way to go. That's what Aristocles do if I remember correctly. Bouncing if you have wallsmoothed your destination more than X% is another. That's what current Pugilist do. There are lots of variious ways to do it. Go ahead experiment some. -- PEZ
Hmm, how are calculating those figures? I'm using bullet travel time, so at the point a bullet has passed me the rest will be e.g. 16, 32, 48 ticks away. So the second bullet counts for ~70% of the first, and the third for ~60% of the first. It will become more extreme as a bullet comes closer, e.g. when the nearest bullet is 2 ticks away and the next-nearest is 18 away the nearest counts three times higher. But it's not really trivial, still.
Alcatraz, wow, that's something... how is he getting 80%+ against random linear targeting? Must watch his bot for bit. :-) -- Jamougha
Well, you have seen my code for it quite a few times. Your ratios sound much sounder though. And I also use bullet flight time.. Maybe it's my Excel sheet that's wrongly set up... -- PEZ
Yes, your code for it looks fine, I've checked it a few times as you say. :-) I'd say it's an Excel issue. -- Jamougha
Cool. That's sets a piece of my mind at peace. I really couldn't figure it out. -- PEZ
@PEZ&Axe: IMHO, you must have some kind of serious bug or logical flaw in your code if your WaveSurfing implementation doesn't get you a 1950+ rating. I have tried countless variations of the same idea, and it seems to work everytime. I tried looking only at the closest bullet, at all the bullets with and without weighting (linear/exponential,bulletTime/distance), with/without bin smoothing, high/low segmentation, more/less bins (it works with as few as 5 bins!), multiple ways of comparing continue/invert positions, and many others. I would sugest you guys start by making sure your EnemyWaves and future position prediction are working correctly, and then try to flatten RoboGrapher's output with a simple non-segmented flattener. If you can get a "flat sugar on top" profile from Robographer it means you are on the right track, and probably in the 1950+ club. -- ABC
Tell me about it. =) Of course I have a serious bug. And I also have noticed that as few as 5 bins work and that the weighting of the waves seems to be something to worry about when the bugs are gone. It feels good that you say this ABC. Feel free to review P 1.4.4's code some. =) You know my e-mail address. -- PEZ
Thnx for your attention, ABC. I was thinking 'bout it these days... There is something very rotten in the state of denmark. Probably is my lack of knowledgment about the GF & Waves theory. The wave/bullet synchronization i can tell u that it is ok (RobocodeGLV014 gave me a huge hand with it). I am know suspecting of the GF "measuring". When i detect a wave, i am using the most simple way to calculate the GF points: i assume that i can go instantly to vel 8 to get the GF 1.0, and also instantly to vel -8 to calculate the GF -1.0. That would give me a much wider escape angles, and what i'm thinking that is GF 0.5 for example, can sometimes actually be GF 1.0... Don't know, but i'm suspecting that it could be this... -- Axe
I doubt it. The nature of GFs takes care of that for you. I think we all use a GF1 defined like that. -- PEZ
Really? To bad, i had hopes that it was only this... I was thinking that way because we are successfully avoiding GF 0.0 against HeadOnTargeting bots. Must be something that is giving us bad GFs above and/or below 0.0. Tell me something: how do u distinguish from positive/negative GFs? I am using only my velocity sign, is that good enought? -- Axe
I don't do it at all. All I do is check the forward and reverse positions and reverse should there be less danger that way. My reverse position I decide is the one I get to if I change my lateratVelocity sign and go for full speed. Maybe there's something inherently wrong with this... -- PEZ
Yep, i was thinking that it might be something like that. An error in it can easily explain our problems. I am thinking in a test: I´ll try to take out the sign of the negative GFs and sum with the positives. And when moving, consider that i´m always in a positive gf. That is: if i´m hit in GF 1.0, i´ll avoid also GF -1.0. What do u think? Btw: PEZ, what bot do consider the best simple gf gun to test? I´m using your Tityus, since it is strong and u described as "low segmentated", what do u think? -- Axe
Well, it's not lightly segmented. That must refer to an old version. Since Jamougha showed that my assumption that heavy segmentation slows learning was wrong I switched strategy. Still it's a straightforward GF gun. No rolling averages or anything like that. So it is easily fooled by good AM. It should be easy enough for you to remove segemnation dimensions though. If you want to test against a distance-only segmentation for instance. Keep me posted on how your esperiment turns out. -- PEZ
- (edit conflict) Right, i was thinking another thing: this should help also if the enemy gun isn´t distinguing well the gf signs. I´ll try the testings with TGB (Tityus-like, ain´t?). The idea of taking of the segmentation is good, i have once changed segmentation of your old RoboGrapher, this shouldn´t be difficult. Btw, nice and clean coding, congrats... Very different from my stuffed code (i really hate to organize my things, u should see my desk :). -- Axe
Axe, I believe it is very important to precisely simulate the acceleration/decceleration when projecting your future position, just assuming you'll instantly get from 8 to -8 will make your projected position miles away from where you'll really be. The tranjectory is not that important, I assumed a perfect orbit in Shadow 2.31 and it worked very well. About the +/- GFs, you must do it exactly like a GF gun: if you were moving clockwise when the enemy fired, the positions clockwise to where you were are positive GFs and the anti-clockwise are negative, and vice-versa. -- ABC
- I´ll make both tests...Don´t think that this diff. in both methods can be a problem to AM? For example: if Shadow is doing the precise gf calculation to avoid and Tityus is firing with the simple method, won´t be Shadow in disadvantage? More far: Shouldn´t SilverSurfer & Okami beating Tityus easily? -- Axe
I'm not sure what you mean by "simple method", using the absolute GF value is allways wrong, there is nothing more different than GF-1 and GF1... -- ABC
I don't think Axe means he is predicting his future positions using the assumptions of instant max velocity. It's just a definition of what is GF1. I think. -- PEZ
ABC, i think that we misunderstood each other... What i was mentioning was about the definition of what is GF 1.0. The formula asin(8/bvel) for max escape angle (or gf 1) is only correct if u asume that u can go in an instant to vel. 8 (or -8 for gf -1), right? Wouldn´t be more realistic if u use a precise-prediction method to calculate the max escape and then call it gf 1? That value would be at max. asin(8/bvel), and the difference can be very great if the distance is short or if u are stopped. Please feel free to correct me, as i said i´m a rookie with gfs. -- Axe
Ah, ok, I imagine that the fact that your maxAngle is dependent of your current speed could be used in a GF gun (it would be complicated, though), distance is not a factor. But for the dodger, considering you are doing precise prediction, you will allways evaluate possible angles. "(or -8 for gf -1)", not really, GF -1 is in fact impossible to reach. The GF sign is allways relative to your movement direction when the bullet/wave was fired. -- ABC
Woosh... Version 1.11 scored, at last, 1950+... Credits goes all to Jamougha´s "GF rating" formula:
// Jamougha´s gf rating formula
private static double rateGF(int gf,double[] hits,double[] visits){
double rate = 0;
for (int i = 1; i < hits.length ; i++)
{
rate += (hits[i]+(0.1*visits[i]))/Math.pow(Math.abs(gf - i)+1, 0.5);
}
return rate;
}
Amazing and simple. The funny thing is that my tests with TGB never show a big increase (as a matter of fact, pointed to zero increase). The real increase came from mid-ranked bots, i think. Congratulations Irish, u are really a bainiac (nothing that i didn´t knew it already)! -- Axe
You made it to 1950+ with SilverSurfer, congratulations! Best of luck in reaching the 2k barrier. :) -- ABC
Thanks, but the credits should really go to Jam. It saved me from beeing stucked within my own convictions.
I think that i have room for some extra points, since SilverSurfer & Okami are probably one of the few top bots without WallSmoothing. As PEZ said, (and i agree very much) i might be loosing some points. Graphed it with TGB, and the near walls segmentation seems very, very, very bad. -- Axe
SilverSurfer 1.16 is looking pretty good! :) -- ABC
Yep. Did u saw? It reached 2011 with ~100! First time ever above 2000 for me! Unfortunately it probably will fall a lot now (it uses to be like this.). -- Axe
Interesting... I have runned(?) ~800 rounds with 1.16 in my client. Before the upload SilverSurfer was with aprox. 580 battles and scoring ~1964. After the upload it gone to ~1300 battles and 1979.9! is that delta normal? Take in count that is AM and with very few pre-data. Strange... -- Axe
- Have anyone explanation for the above? -- Axe
Unusual. I've noticed that you bots are *ahem* on the slow side, perhaps you have an exceptionally fast computer and it doesn't skip as many turns? Good work on the improvements, anyway! -- Jamougha
- Thanks, but i don´t think that is the machine... My home computer is a win-XP, 1.7 athlon, 512Mb ram... No super machine... -- Axe
I was thinkin' in two possibilities: 1. Is 500 really stable? With ~250 bots is 2 battles per bot stable enough? 2. The saved data. With few pre-saved data, is expected that running more battles in one client, the results in that client to be better (perhaps also a 1.4.2 security bug in the other client too). -- Axe
When you run 800 battles on the same client, your ranking is not really in the same "scale" as everybody else, imho. The distributed nature of RR@H is a big factor in the ranking, it only works because every bot fights in the same basic conditions. If you really want to see your true ranking after 1300 battles you'll have to wait for it to get there "naturally"... -- ABC
I understand what u are saying, i really never thought that way... But in other hand, is this so different from pre-saved data (I mean, isn´t naturall too..)? -- Axe
Pre-saved data can also be considered a "trick", that's why I don't like it too much either. Fortunately the RR@H ranking is very resistant to those tricks, in the end they wont get you very far. Aleph is a great example of that, no data saving at all and very close to 2k points. -- ABC
It came to me now ( a little late, of course) that Aleph is in fact an example encouraging saved data. If he start to use saved data, probably the 2K club would have three members by now. -- Axe
Yes, but how many data saving bots have been completely out-classed by a well executed idea? Btw, congrats on your improvements with SilverSurfer, great work, hope to see you up there soon. :) -- ABC
Let's see exactly how much of Shadow's raking depends on data saving, should be interesting... -- ABC
Released with pre-saved data? SilverSurfer versions 1.18 & 1.20 have pre saved data, but only from low ranked bots (I suspect that the pre-saved could not be so usefull against GF guns, but against HeadOn & similars...). -- Axe
- I meant data for the AM moving, of course... -- Axe
Nevermind, just saw... without data. Any data? Movement & Gun? -- Axe
I disabled Shadow's AM data saving, I never used pre-saved data. I also never saved any gun-related data. -- ABC
The gun saved data isn´t that good (too large to be saved a good amount). It only serves to fill the 80 ticks lacune i have at the start without it. -- Axe
Turned out better than I expected! After 600 battles it has the 2020 points it had and a positive momentum. And I just edited the poperties file inside the jar, didn't touch the code... I'm considering going back to no data saving for future versions. -- ABC
Yep. Probably the saved data ain't that worth afterall... But don't think that it hurts too... -- Axe
Hey, add SilverSurfer to The2000Club! By the way, how did it get so many battles so fast? -- Alcatraz
Yep. 2K... I barely believe it... The number of battles is because of a bug with Freya in my client. Setted to 200 battles, and left it running, but with the exceptions the 200 battles cycle never get to 200 and the uploads accumulated (this plus the fact that it seems that my client was the only one running..). -- Axe
April 17, 2004: It seems that i finally made my way to the 2K at last! This must be one of the most "sweated" AMs ever. -- Axe
Congrats dude! Hard work payed off it seems. -- PEZ
Welcome to the 2k club, great work. Don't give up now, with that kind of dedication nothing can stop you from getting to #1. :) -- ABC
Thanks! That's the idea. :) -- Axe
just thought i'd cast your mind back to the "Musashi days" todo list:
Beat VertiLeach :). Beat Shadow & Tron :)). Beat DT :)))).
I just pe you've grown 3 new mouths to let you do the DT smile... --Brainfade
The To-Do list... Old stuff, that! Yes, that was before even the amazing appearance of Jamougha...
Good to see that i´m on the right way. But to be honest with Paul, I have only beatten DT in the ranking, he still one of the worst headaches to me (Let´s not talk loud, he (Paul) might wake up and blow up my 3rd place :)... -- Axe
Added a comemorative image for the 2K, also included a link to the latest source included version (since i am packing my versions with some pre-saved data, and the repository have a restriction on uploads > 250Kb, i had to made some space, so the competition version is not including source.) -- Axe
I'll really have to spare some time with those ram bots... They became the worst PBI difference between expected & acquired. Ramers are cool! -- Axe
What are you segementing your EnemyWaves on? -- PEZ
Distance (3 segs: 0-200;200-400;400-), acceleration (3 segs: accelerating, "deacelerating"(?), constant) and absolute velocity (3 segs: 0-2;2-5;3-8) -- Axe
Good. loose ~10 points. Probably the "lightened" gun, but it could be also the anti-ram tweaking... Repeat 10 times with me: "I shall never work in movement and gun in the same version."... -- Axe
I'll try your segmentations next. That will free some bytes in P as well. -- PEZ
When you get S back in the 2K club. Maybe you can try summarize what it was you think was bad with the current tweaks and such. I think that could make very interesting reading. -- PEZ
Of course. I was compiling some material, like a "diary of suffering" about these days :) -- Axe
2.11 has a bug where it gets disabled in the first round if it meets a new enemy. I'm not sure if this matter much for your rating, but anyway... -- PEZ
Thanks. I´ll take a look, never saw it in my computer... Didn´t understood exactly what u mean by "new enemy", do you remember against witch bot it was? Could be also that saving/loading files SecurityException issue, what JRE are u running? -- Axe
"New enemy" == enemy you don't have data on. Like dev Pugilist and such. -- PEZ
- That was what i thinked... Is your JRE 1.4.2 or higher? -- Axe
- Yeah, I think so. (I'm not at home now and I have about 12 or 15 or so JVM's installed...). -- PEZ
- Aren't you having data saving/loading problems with that SecurityException with JRE 1.4.2? Or have u found a way to avoid it (if u found a solution, do u mind to share it)? -- Axe
- Jim solved that. Add -Dsun.io.useCanonCaches=false to your java command when starting robocode. The bug in SilverSurfer seems to be of another nature. At the momement it doesn't even seem to be there any longer on my machine. Now I get this instead, regardless if the enemy is a new one or not:
========================= Round 1 of 100 ========================= SilverSurfer scorer new Round! StaticDataCenter:ahf.r2d2.R2d2 0.7 ahf.r2d2.R2d2 0.7 scorer new Round! IOException trying to read: java.lang.NullPointerException: name can't be null CREATING STRATEGO FOR:ahf.r2d2.R2d2 0.7 ********** PULOU ROUND:3 - 27
-- PEZ
- That exception just means that it hadn't found a data file for that bot, it's expected. I'll try at home with 1.4.2, now with Jim's solution. Thanks a lot! -- Axe
- Arggg... I just can´t reproduce that bug that disable it in the first round... It simply doesn´t happens when i´m watching (as usual with these weird bugs). If someone out there notice it, please post the trace here... -- Axe
@ ABC & PEZ: The results of the saving & pre-saved data experiments:
| Data saving | Pre-saved data | Score |
| Yes | Yes | 2009.46 |
| Yes | No | 1988.63 |
| No | No | 1984.64 |
Seems that the big difference here came from the pre-saved data, next version I'll try a fast learning approach (based on ABC's brilliant idea, probably...), and without the pre-saved data.
That fast-learning idea can also give me room for new segmentations. -- Axe
A good implementation of that fast-learning strategy will allow you to add as many segmentations as you fancy. =) Collecting data in the rumble doesn't give too many points of course, since you seldom meet the same opponent twice and when it happens chances are that it's on a different computer anyway. -- PEZ
Yep. Thats why ABC's idea is so nice. As ABC, I don't like much the pre-saved data idea, it seems unnatural. Your (PEZ) approach for the problem (if there is no data in that segment use a "general" segment) is very fancy too. Don't know yet how i'll do it, tests will tell... -- Axe
My approach obviously doesn't gain me any rating points so I can't really recommend it. =) -- PEZ
Still think that is a good idea. SS is very SlowBot, your idea probably will require less processing than ABC's... Well, tests will tell... -- Axe
My solution doesn't cost much at all. It's just a few (less than 10) more calls to Math.sqrt() per tick. And that's only while I haven't got a hit in the segmented container. -- PEZ
I´m recalling the versions. 2.07 will be untill i have time to work on the blitz-adaptation. I really enjoy that 3rd. place :) -- Axe
@ PEZ (or someone that have experience with that): This is the first time that i "downgrade" a version of a bot of mine... My client is priorizing SS 2.07 battles, but it was already with > 500 battles. Strange, is that normal? -- Axe
I've seen it happen. Don't know why though. But the priority-code is quite entangled and hard to follow so from what I can understand anything can happen. =) Funny that you grew fond of your test bot. I was thinking that would happen. =) -- PEZ
Sorry, "grew fond of" = ?? -- Axe
- "grew fond of" == to be proud of? If is that, sure! But if you meant that it would be permanent, no. I'll make Okami = SilverSurfer when I consider the WaveSurfing development completed (and take out SS from the rumble until i start my new cannon dev.) -- Axe
I would translate it to "afeiçoou-se". -- ABC
If you say so. =) It means something like "begin to like". -- PEZ
Yep. it's very convenient to know someone that speak the same language and with a better english, thanks! :) Yes, i grew found of SS (is that correct?), as a matter of fact, i don't like much the idea of SS suffer that much to give Okami all his knowledge... But life isn't supposed to be easy to SilverSurfer, right? :) -- Axe
You're right. Okami is a demanding master it seems. "afeiçoou" looks like the same word as "affection" by the way. We have that word in swedish too. (And it's "fond", not "found", since you asked.) -- PEZ
- right, fond. And you r right too about affection (only that affection is a substantive, the correpondent would be more to "afeicão", that is a substantive too. "afeiçoar" is a verb, and "afeiçoou" is the past-tense). But the master (Galactus) is me and not Okami, obvious. Even if my disciples dont obey me that mutch (for example: I gave to SilverSurfer the order to take the 1st place from RaikoMX...) :))-- Axe
Well, my heralds don't do as I tell them either. =) -- PEZ
@PEZ & ABC: From my history control, entry for version 2.14:
"Trying a FastAdaptation solution, that is a merge of ABC´s across-segments smoothing solution and PEZ´s "unsegmented segment" approach (credits for them both)".
I thinked in one interesting approach to that adaptation speed problem (at least i think it´s interesting :):
First i mantain an extra "unsegmented segment" for the GF hits (like PEZ), and every hit-me event i update not only the segment that the enemy´s bullet wave matches to, but also that "unsegmented segment".
Then when chosing the good gf for the incoming next wave, i just add the bins of the unsegmented segment to the bins of the incoming-wave-matching segment.
Probably this will give me a similar result that ABC´s across-segments smoothing achieved, but without the processing cost of smoothing across all segments (that is specially good for me, seen that i´m using 97 bins).
It seems good in theory, let´s see if it works... (btw, 2.14 was released without pre-saved data). -- Axe
Congrats, you did it. Like I said, no (pre)data saving is needed for a 2k rating. What you describe sounds just like what I did in most of Shadow's versions. Actually, I had 4 arrays: GF0[], GF1[][], GF2[][][], GF3[][][][], updated with every bullet. I used the extreme smoothing in 2.49 because I was experimenting with different kinds of rolling averages. Since then (in Tron, f.e.), I went back to "normal" visit counts and multiple segmentations, only this time I save memory by just adding up sub-segments on the fly to get the less segmented counts. It is my opinion that, after you get a good wavesurfing scheme (fast learning + long term FloodMini fooling), it becomes less important to tweak it, the "extra" ranking points are in the small movement details and probably in the gun. I believe your next step in joining RaikoMX in the 2050 club is trying to get the least possible hits by a headOnTargeting bot in 35 rounds, and that is all about avoiding wall traps and similar "no escape" situations... -- ABC
Cool! Do you weight the GFs in the unsegmented bins lower or do you just make a straight sum? I would guess the latter is rather like going fully unsegmented to begin with. Maybe you should try that? P seems to do equally well with unsegmented as it does with the fast-learning thingy applied.
As for the 2050 club. I agree with ABC that it could be with the "other" movement details. Aristocles can totally shut out head on targeters because it refuses to wall bounce against them. RaikoMX doesn't wall bounce either. It uses its wave surfing stats to know when it's time to reverse. All my experiments with this fails. Very probably because I only have rough estimates on my future positions and these get very faulty near walls. Thus I am doomed to wall bounce. Thus I tend to give head-on targeters a free hit now and then.
But the next thing you might consider is that RaikoMX's gun is super strong. And P has taught me that there are still rating points to gain by improving the gun.
-- PEZ
I have used 2 solutions for the wheighting of multiple segmentation levels. I used normal wheighting: GF3*dists*acels*vels + GF2*dists*acels + GF1*dists + GF0 works nicely. Other times I used percentages: you keep the total hits for each segment in bin[GF-1] and use the percentage of hits in each bin instead of the count (bin[GF] / bin[0]), that way the danger value is proportional to the quantity of samples in each segment, and you can just add them up. -- ABC
I figured that would be the way to do it. After I released P 1.7.3 that is. =) There I just divide fast-learning by 100... Now I'll try something completely different. Code name: "Doris". Let's see if it fools those PM guns like I think it might... -- PEZ
Can't you try a 2.17.2 fully without segmentation please? I'm very curious! -- PEZ
- no problem. -- Axe
- Released 2.17.3, only the unsegmented_segment. But i´m curious... Did u saw something interesting? Version 2.17.1 seems to show that the higher i weigth the unsegmented_segment, the worst gets my score. -- Axe
- I missed that. And now when you weight it 100% your down on 1980 points. So, your segmentation gains you 30+ points. That's good to know. Thanks! -- PEZ
An antry with a bang, 2.19 did! 25 battles, 1997 points and a momentum of 355. =) Let's see if you can bring RaikoMX down! -- PEZ
These weirds things sometimes happens, too soon to tell (although, i´ll not be sad if u r right). I´m trying a version with your idea of "mirror the edges" for edge-protection. A little modified: While smoothing the bins, i smooth 46 in each direction, and if it falls over the edges (0-96), they´ll refer to the "mirrored" position (like two mirrors at the both edges).
The old code (discussed at Pugilist/HelpRequests page:
// Jamougha´s gf rating formula
public double[] rateGFs(double[] allHits, double[] hits, double[] visits) {
double rate[] = new double[hits.length];
for (int i = 0; i < hits.length; i++) {
double rating = 0;
for (int j = 0; j < hits.length; j++) {
rating += ((SEGMENTED_WEIGHT * hits[j])
+(UNSEGMENTED_WEIGHT * allHits[j])
+(FLATTENER_WEIGHT * visits[j]))
/ Math.pow(Math.abs(j - i) + 1, 1.5);
}
rate[i] = rating;
}
return rate;
}
The new code with the mirror edges:
// Based on Jamougha´s gf smoothed-rating formula
public double[] rateGFs(double[] allHits, double[] hits, double[] visits) {
double rate[] = new double[hits.length];
int delta = (int)(hits.length/2);
for (int i = 0; i < hits.length; i++)
{
double rating = 0;
int start = i-delta;
int end = i+delta;
// loop based on PEZ´s idea of mirror the edges for
// edge protection uppon the smoothing
for (int j = start; j <= end; j++)
{
int index = (j<0)?Math.abs(j):(j>=hits.length)?Math.abs((2*(hits.length-1))-j):j;
// allHits[] is an "unsegmented segment" that uses PEZ´s "unsegmented segment"
// to accomplish ABC´s brilliant idea of fast-learning.
rating += ((SEGMENTED_WEIGHT * hits[j])
+(UNSEGMENTED_WEIGHT * allHits[j])
+(FLATTENER_WEIGHT * visits[j]))
/ Math.pow(Math.abs(j - i) + 1, 1.5);
}
rate[i] = rating;
}
return rate;
}
-- Axe
Funny, that's very much how I tried to apply it. But i faied utterly. I must read your code and see what little detail it is I have missed. SS stayed at 1997 with this applied though it seems, so maybe it's not the way to go? -- PEZ
Here's my stab at it BTW. Maybe you or someone else sees where I go astray?
double smoothedVisits(int index) {
double smoothed = 0;
int i = Math.min(index - Pugilist.MIDDLE_FACTOR, 0);
int k;
do {
k = i;
if (i < 0) {
k = -i;
}
if (i > Pugilist.FACTORS - 1) {
k = Pugilist.FACTORS - 1 - (i - Pugilist.FACTORS + 1);
}
smoothed += (double)visits[k] / Math.pow(Math.abs(index - k) + 1.0, 2.0);
i++;
} while (i < Math.max(index + Pugilist.MIDDLE_FACTOR, Pugilist.FACTORS));
return smoothed / Math.sqrt(distanceToTarget() / bulletVelocity);
}
It should be compared with the version posted on the Pugilist pages I guess. There I replaced the byte saving do loop with a more readable for loop before posting it though.
-- PEZ
Aren't you still having an edge smoothed problem with your code Axe? It looks to me like the edge bins still will have fewer neighbours than the GF0 bin. I try to avoid this in my code. Even though I have some other failure in it... -- PEZ
I'm still not convinced that edge smoothing is a problem. Think of it this way: if you have a perfectly flat profile, the best place to go to, where you are furthest away from where the enemy might shoot at, is to the edges, since he might shoot with equal probability at every guess factor. And the most dangerous place is GF0.
Today I implemented exactly what Axe described, something like this:
gFact = new double[bins]; for (int i = 1; i < bins; i++) for (int j = 1; j < bins; j++) gFact[i] += 1 / Math.pow(Math.abs(i - j) + 1, 2);
Then I did "danger /= gFact[index]", so that the smoothed curve is flat when the visit counts are flat. It didn't help much, in fact I think it works slightly better without it (Tron vs FloodGrapher)...
-- ABC
Why's GF0 the most dangerous place? -- PEZ
Probably because many bots default the guess factor to 0, Meaning that on a perfectly flat profile they'd fire straight at you. --Brainfade
If you define danger as the proximity to the enemy's bullet, GF0 is the most dangerous one because it has the most "close neighbours". -- ABC
Could that be right? In my thinking GF0.5 has as many close neighbours. And the edge GFs have no neighbours on one side only because you can't reach them (by definition). Which makes me think I should count the neighbours it has twice. But it doesn't seem to improve my bot when I do that so I suspect you are right in your reasoning, even if I can't really understand it... -- PEZ
Well excluding the "near-edge" guess factors would have the same number of "close neighbours" wouldn't they?? The large (far from zero) guess factors have an added risk, as they are more likely to wake you bounce (or smooth) the walls). Speakign as someone who has no knowledge of wavesurfing; when counting the neighbours around a guess factor, when your on an edge factor, would it not make more sense to just count the GF1 value repeatedly rather than using the values from just inside?? To be honest i can't think of any situation where it would make much difference, but it just sounds more logical in my mind... --Brainfade
The problem is smoothing it correctly. If you just add it up then you might easily overweight it. But as long as you "move" it away while you are recounting it, it could work. I'll have to see if that's easier than my mirroring strategy.
ABC, you divide "danger" by the factor for the particular index there above. What's "danger" before that division? I just use the index factor. But applying your trick to that would end up in all danger being 1...
-- PEZ
My reasoning is like this: You have 3 bins, 1 visit to each of them. Bin 0 has 2 neighbours at distance 1, bin -1 and bin 1 both have 1 neighbour at distance 1 and 1 at distance 2. Defining danger as the visit count divided by "sqr(abs(distance) + 1)":
danger(-1) = 1 + 1/4 + 1/9 = 1.36 danger(0) = 1/4 + 1 + 1/4 = 1.5 danger(1) = 1/9 + 1/4 + 1 = 1.36
PEZ, danger is your smoothed var, the sum of the visits weighted by distance. The gfFact[] array is constant (initialised in the constructor), it stores the pre-calculated proportions of each GF in a flat profile to compensate for the inverted U curve that Axe mentioned.
-- ABC
Ah, I missed the precalc thingy. Well, I can't fit it in Pugilist anyway I think. Unless... yeah, I can calculate it in the same loop as I calculate the danger value. Must try that. Should cost less bytes than my mirroring thingy with some luck. Thanks!
About your danger reasoning above. I'm with you so far. But does it follow that it is more dangerous to surf to GF0? What happens for me (when graphing with TGrapher at least) is that I get a GF1 spike. I have thought this is because the smoothing under-rates GF1 and makes P go for it even though it might still be the most visited GF.
-- PEZ
If you consider dangerous to be near the enemy bullet (even if it doesn't hit you), then yes, GF0 is the most dangerous.
About the pre-calc, I just did it like that because my math skills are not the best ;). It can surely be done on the fly, you need to divide the danger by the area below the smoothing function's curve for the current GF.
-- ABC
I thought I could calculate it the same way as you do above, just using my existing loop structure. Less efficient CPU-wise, but costs less bytes. But I haven't tried it yet, so I'm not sure I'm thinking correctly. -- PEZ
Hey, been busy that keyboards, ain´t ?:) I´ve wasted a lot of brain cycles thinkin ´bout that edge thing. First i came with that "adjusting" factor to compensate the inverted U graph, but made some calculations and moved to PEZ´s mirroring the edges idea (afterall if u put two mirrors in front each other u´ll get the infinite), and the tests with 2.19 went really bad.
Reading ABC´s words makes echo with my own thoughts: It really makes sense that GF0 is the most dangerous if u apply a smoothing formula. The question that i´m thinkin now is: and what if we just don´t smooth, or smooth by a higher power factor? -- Axe
Tests increasing the participation of the flattener in 2.17.4 (the best scoring SS version till now) indicates that the flattener isn´t that useless... The diff. is small, but i think that it increased the performance against PM guns. 2.17.5 was just released with an even higher participation factor for the flattener. Let´s see. -- Axe
For that flattener; Are you firing EnemyWaves every tick or just when the enemy fires? Or rather; Is the flattener updated with every-tick waves or follow-bullet-waves? -- PEZ
- Only real waves -- Axe
Here's my adaption of ABC's implementation of BinSmoothing/EdgeProtection using an inverted smoothed flat curve like you suggested Axe:
double smoothedVisits(int index) {
double smoothed = 0;
double edgeFactor = 0;
for (int i = 0; i < FACTORS; i++) {
edgeFactor += 1.0 / Math.pow(Math.abs(index - i) + 1.0, 1.5);
smoothed += (double)visits[i] / Math.pow(Math.abs(index - i) + 1.0, 1.5);
}
return (smoothed / edgeFactor) / Math.pow(distanceToTarget(), 0.5);
}
Note that the main difference from ABC's implementation is that I don't have an outer loop updating the smoothed value of every bin. I just check the bin I am currently interested in. Saves some CPU I guess. And also it's very easy to request an all-bins array (should I ever need one):
double[] smoothedVisitsArray() {
double smoothed[] = new double[FACTORS];
for (i = 0; i < FACTORS; i++) {
smoothed[i] = smoothedVisits(i);
}
return smoothed;
}
-- PEZ
- Very fancy, let me know the results when u get them. I really have my doubts on that idea. For example: try to apply it into 5 five bins array like that: 1.0;0.0;1.0;0.0;1.0. The resulting wave isn´t correct too... But I hope that it work for u :). -- Axe
Well, after some excel graphing, I came to the conclusion that the best edge smoothing protection is the repeating of the edge values. Like this:
for (int b = index - (bins - 1); b <= index + (bins - 1) ; b++) danger += visits[Math.max(0, Math.min(bins - 1, b))] / Math.pow(Math.abs(index - b) + 1, 2);
-- ABC
I'm a bity too giddy waiting for the Hockey World Championships final to start. Sweden is meeting Canada in a repeat of last years final. Let's hope it's not a total repeat though. =) But your code resembles my edge mirroring. Is that what's going on or is it just a reapeat of the edge value? I'll try your code once I figure it out. Doesn't eat many bytes. Thanks for sharing! -- PEZ
It's just a repeat of the edge value. -- ABC
I've been focused on my bot so much the latest day that I just now noticed that you've pushed SS past Shadow. Way cooooool!!! -- PEZ
I am seeing right now! 2nd! But i´m afraid that it won´t last... Only 1 point of diff. and the Shadow´s score seems to be in a "low tide" of the scoring oscillation. 2nd (at least for now)!... :))) -- Axe
Wow, congrats! 1 point isn't much, but it's enough to get me working on Shadow again... ;) -- ABC
Thnx. And thanks also for updating Shadow only after SS have surpassed it :) -- Axe
But speaking seriously, SS had already reached 2015+ in other versions, the reason for surpassing Shadow is only because of the scoring tide humor (I think that is one of the few times that i saw Shadow bellow 2015). Actually i think that kind of diff. is more to a draw. -- Axe
But those tides happen to everyone, I usually look at Shadow's score in relation to RaikoMX, it's always around -30. It's a draw, but it's the first time SS manages to draw against Shadow, regardless of the actual score ;). -- ABC
Nice Axe! -- Pulsar
Maybe you can leave SilverSurfer at version 2.22? Then I stand a chance to grab that #3 slot. =) -- PEZ
- :^) ! -- Axe
That probably won´t last, but... :)))!!
http://robowiki.net/robocode/uploads/axe/SS_2060_1ST.GIF
-- Axe
The version of SS in the repository is not the same as in the RoboRumble/Participants page (2.43 vs. 2.42) which keeps my RR@H client from running any SS battels. -- Strider
I noticed when running in other computer... Fixed it. Thanks! -- Axe
Hey Axe, I just thought you might like to know: SilverSurfer doesn't fire 3.0 power bullets if you set "TC = true" in the AxeBot.java. At first, I was amazed by the 96% score for TargetingChallenge2K6, but I quickly noticed that he wasn't firing 3.0 bullets :) -- Voidious
