Editing revision 28 of Pugilist/HelpRequests

Robo Home | Changes | Preferences | AllPages

Editing old revision 28. Saving this page will replace the latest revision with this text.

I need some help with my implementation of fast-learning WaveSurfing. SilverSurfer 1.17.x shows that it can mean a huge difference in rating to get this to work. Pugilist 1.6.4.4 and 1.7.6 shows that it can be a huge difference in a bad way if you fail to get it to work though...

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:
<pre>
    void registerVisits(int count) {
        int index = visitingIndex(targetLocation);
        visits[index] += count;
        fastLearningVisits[index] += count;
    }
</pre>
Then when I read the data I do:
<pre>
            smoothed += (((double)fastLearningVisits[i] / (double)Pugilist.enemyHits) + (double)visits[i]) / Math.pow(Math.abs(index - i) + 1.0, 0.5);
</pre>
That's in contrast to the way it's done in 1.6.4.4 which simply does:
<pre>
            smoothed += (double)visits[i] / Math.pow(Math.abs(index - i) + 1.0, 0.5);
</pre>
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:
<pre>
// 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;
}
</pre> 
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]]
* not only gravitational, other things magnetic fields use it too (as a matter of fact God seems to like this formula a lot:) -- [[Axe]]

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). <br>
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)...<br>
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]]
* But more processing (SS is a very SlowBot as it is). I think that that (mine) approach it wont cost much (in bytes or even processing), since it´s just a multiplier factor for the bin after smoothed... The problem is how to calculate that factor (it would lead probably to an equation function of the "distance from GF0") -- [[Axe]]
* Yeah, that sounds like it makes sense. Let's see if I can figure something out. *starts Excel*... -- [[PEZ]
* Seeming to me harder than i thought... -- [[Axe]]
* To me too. Though I have an excuse since it's really late here. =) -- [[PEZ]]

PEZ, is this code needed in Pugilist 2.0.9 ?
<pre>
      if (enemyHits == 0)
         Wave.fastVisits[Wave.MIDDLE_FACTOR] = enemyHits;
</pre>
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]]

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

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