This is what I do for fast learning in 1.7.6. I have an unsegmented visits array that I shadow the segmented stats in. Like so:
![[Home]](/images/RoboWiki.png)
void registerVisits(int count) {
int index = visitingIndex(targetLocation);
visits[index] += count;
fastLearningVisits[index] += count;
}
Then when I read the data I do:
smoothed += (((double)fastLearningVisits[i] / (double)Pugilist.enemyHits) + (double)visits[i]) / Math.pow(Math.abs(index - i) + 1.0, 0.5);
That's in contrast to the way it's done in 1.6.4.4 which simply does:
smoothed += (double)visits[i] / Math.pow(Math.abs(index - i) + 1.0, 0.5);
Anyone see if/where I am doing something wrong?
-- PEZ
I see nothing wrong with that code. Maybe you are giving too little importance to the unsegmented data? The way you have it, you only use the fast learning data while there is no segmented data available, since "fastLearningVisits?[i]/Pugilist?.enemyHits" will allways be < 1. -- ABC
Yes, that's by intention. But that's not to say it's the right thing to do... -- PEZ
I don't think there is an absolut "right thing to do" ;). You could try canging it to "fastLearnigVisits?/numSegs + visits" like I do, or "fastLearnigVisits?*someFactor + visits" like Axe does... -- ABC
Well, I define "right thing to do" == "gains you more rating points" =) I'll try it your way first, since it makes sense. -- PEZ
Don't know much about right or wrong, but tht's what i do in SS:
// Jamougha´s gf rating formula
public double[] newrateGFs(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;
}
That was originally based on a similar Jamougha's method (Credits for him). But i have tweaked it, originally the pow function raised to 0.5, but my tweaks gave me 1.5 (i use 97 bins, remember). The important things here are the weights to the flattener (visits[]), the fast-learning segment (allHits[]) and the "segmented segment" (hits[]). I made some experiments with those weights:
| SS version | FLATTENER_WEIGHT | UNSEGMENTED_WEIGHT | SEGMENTED_WEIGHT | score | |
| 2.15 | 0.1 | 1 | 1 | 2013.79 | |
| 2.17 | 0 | 0.5 | 1 | 2010.80 | |
| 2.17.1 | 0 | 1 | 0.5 | 2004.95 | |
| 2.17.2 | 0 | 1 | 1 | 2013.56 | |
| 2.17.3 | 0 | 1 | 0 | 1978.45 |
Hope this help u... -- Axe
97 bins? Why did you chose such a big number? -- ABC
The number of bins probably doesn't matter as long as you compensate with enough smoothing. Interestingly enough I ended up with the same smoothing function as Jamougha did. Not a total coinsidence though, since it was Jam who hinted at me to try smoothing when reading rather than when writing. Just until a few days ago I did Math.sqrt() instead of Math.pow(x, 0.5). This is of course the same, but my intention was to open up for experimenting with different coefficients.
Since the rating points of a particular bot can vary some 10 points from one day to another (today RaikoMX had 2044 points, for instance, some days ago it read 1951) I guess what your table says it apart from going totally unsegmented it doesn't matter much how you weight your data. This is surprising like hell to me. I would expect 2.17.2 and 2.17.3 to be about the same thing since the unsegmented stats would always outnumber the segmented dittos. Anyone, please explain this to me. I'm baffled.
You don't do any edge smoothing protection at all? Have you tried adding some? Since your smoothing is so massive you might find some rating points with it. Or you might not. But for P it makes a difference anyway.
-- PEZ
I agree the number of bins shouldn't matter much, but my experiments tell me it does.
About the smoothing formula, maybe Jamougha has his reasons, but I don't really understand why the sqrt. I use 1/Math?.pow(dist, 2) anywhere I want an inverse proportion to distance (bin distance, in this case), the gravitational formula works best for me in almost every case, nature is always right ;). I have also used Gaussian smoothing (visits[i] * Math.exp(Math.pow(i - index, 2) / -k) successfully.
What I read from SS's table is that the flattener is not very important, the segmented statistics are the most important ones, and that the unsegmented statistic also help. The small difference whith the increased unsegmented weight may be explained by the small number of rounds in the rumble, a long term battle might tell a different story...
-- ABC
Gravitational you say? That makes so much sense. I'll try it right away. -- PEZ
The hight number of bins have historical reasons, I started wanting a good resolution at bigger distances for my AM (at dist=800 and pwr=3.0, 97 bins give me a resolution of ~15...), and now that is working, i am too afraid to change this (maybe i'll test fewer bins later). I have to remember, also, that i compensate the bot width when hitted (for example: if i am hit by a wave with the "resolution" of 10, i'll mark hitten not just the hitten bin, but also two for the left and two for the right).
About the tests, i'm not ready to say that the flattener is not important, i'll make a test weighting it higher (0.5 maybe)...
About the edge-smoothing protection, no i ain't using nothing yet, but i think that it would be a good test, what are u using for that "edge-protection"? -- Axe
ABC asked the same on the main Pugilist page. Check it out. My guess is that the flattener is unimportant as long as it gets a low enough weight. After that it's just bad. (Just a guess. I would very much like to see you test it.) -- PEZ
Thanks, just saw the main page, but where u use 2 or 3 extra bins, i'll have to use a dozen (given my 97 bins again...)... I was thinking in an approach (try not to laught too laud, please): Take bin graph with all bins set to 1 for example. This will give you a perfect horizontal line at +1.0, correct? If we apply our smoothing function on it, it would end up with a graph like an inverted U (curve), right? The problem is that a "smoothed" graph for a line should stay a line... I am thinking of apply another factor to that smoothing that would give a higher weith to the edge bins, and a lower weight for the middle bins. That way i can "flatten" the inverred U. Does it make any sense to you both? -- Axe
It sounds like a much better approach than mine. Please let me know if you can do it with less than 10 bytes. =) However adding a dozen bins or just 2 or 3 is equivalent. Same code I mean. -- PEZ
PEZ, is this code needed in Pugilist 2.0.9 ?
if (enemyHits == 0)
Wave.fastVisits[Wave.MIDDLE_FACTOR] = enemyHits;
I saw it will never be true.
-- iiley
Whoa! No, it's not needed as it stands now of course. Must have been a late night hack that! But for the sake of FeederOfRavens I think you should let it be so that we have the comparison to Pugilist as intact as possible. And thanks for alerting me to this. I could either remove it and save bytes or I can fix it and just maybe earn some extra rating points. With Pear and YALT pushing P is in danger of losing its top-10 position. Not that I will be able to keep P there once you and David get your surfing bugs sorted away. -- PEZ
I removed it from FeederOfRavens sm to save bytes to made it a mini, It is same to current version of Pugilist, well i'll try to compress other code to save it. -- iiley
Yes, I said that wrongly. What I meant was, "don't fix it in FoR". Removing it doesn't matter since that test never evaluates to true. And if it did, it wouldn't change anything anyway. It's one of the most stupid pieces of code I have ever seen actually. =) -- PEZ