3.1.3DC vs 3.1.3
The highlighted comment was created in this revision.
Both 3.13 and 3.13DC use GoTo surfing. 3.13DC uses DC, while 3.13 uses some form of VCS. (Correct me if I am wrong)
Correct :-) In the movement, to be more specific.
And considering I write a changelog, I don't see how this question is anything other than lazy at its worst.
I was always wondering why the best bot used VCS, DC seems much more elegant. Does it improve performance in your tests?
For some reason I've never managed to get the DC to perform as well as the VCS, so it still used VCS. I remember Jdev commenting that a range search worked better for him than a KNN search in movement, so I'll be trying that next.
Have you tried doing something similar to your many randomized attribute buffers with kD-Trees? You could make 100 trees, each with a random subset of the predictors, then combine the results. You could even start weighting some tree's results higher if they perform better.
In my mind, a tree is more heavyweight than a buffer. You need multiple buffers to begin to approximate the smoothing you get from KNN and kernel density. I use multiple trees in my surfing for the same reasons, but more on the order of 10 than 100.
I was running some tests over the holidays, and it seems I've improved my DC to the point where against weaker bots it is as good as VCS. However, against top bots VCS movement is still much stronger, ~15% difference on the MC2K7.
Adjusting rolling speed and changing the shape functions of some attributes.
Rolling speed is part of his moving average algorithm, basically how much new values supersede older ones based on time.
I assume shape functions here he means the shape of the kernel function he uses.
Close. The shape functions are the nonlinear scalings I do on attributes before adding them to the tree.
Could someone explain why averaging the results from many random trees is stronger than using a single well-tuned tree?
I would suspect it might make your nearest-neighbours come from multiple perspectives, giving you areas of concavity in your nearest-neighbour function instead of just a pure convex search area. I also suspect using some fancy pre-processing on tree attributes (perhaps dimension reduction/PCA) before adding could give equivalent search patterns.