FastKDE?

Jump to navigation Jump to search
Revision as of 1 October 2017 at 01:45.
The highlighted comment was created in this revision.

I've heard that recent works have done some improvements over traditional KDE (kernel density estimation).

And this project fastKDE contains an implementation.

Any thoughts on that?

    Xor (talk)16:23, 30 September 2017

    Well, assuming that you are using binning followed by KDE, this process doesn't seem to be anywhere near a bottleneck in Robocode. Or is it? I mean, binning reduces the number of kernel evaluations from quadratic order to linear order if you precompute the results for each possible delta. You still get a quadratic number of additions and multiplications, but it shouldn't be that expensive and even if it is, the biggest improvement I can imagine is using FFT here, which would not have a big impact for the number of bins we usually use in Robocode (I've never seen more than 120). And I don't see any advantage on not using binning if you have more than number_of_bins samples, since the GuessFactor [-1, +1] range is pretty "small".

    Anyway, seems to be a really nice article to read :P Maybe those optimizations can work well on swarm targeting?

      Rsalesc (talk)23:20, 30 September 2017

      Well, afaik DrussGT is using 151 bins in his movement, iirc. And my old experimental anti-aliased VCS gun uses more than 1500 bins (where continuing increasing bins no longer increase performance).

      In targeting, DrussGT and ScalarBot (inspired by DrussGT) is using max overlap to reconstruct firing angles, not kernel density estimation, and it's O(nlgn).

      Anyway, fastKDE is not to accelerate existing computation — but to accelerate the process of getting the real probability density function (which includes computing bandwidth and shape function effectively), with way less samples. You know, in robocode, the sample amount is really restricted, and I think this method is exactly what modern bots needs.

        Xor (talk)02:45, 1 October 2017