Effectiveness

Hmm, interesting. With regards to the "wavesurfing without explicit dive protection" part though, I feel that Waves/Precise_Intersection covers that perfectly well, and no additional "dynamic bandwidth" is needed for that purpose. Really, the only reason I can think of for any kind of "dynamic bandwidth" besides that provided by precise intersection, is for the case of small data set size near the start of a round, where the uncertainty is greater.

I'm not sure about precise intersection negating dive protection, because the precise intersection only helps determine what part of the wave you would be hit by, not how dangerous that part of the wave may be.

I agree that variable bandwidth isn't a replacement for some sort of dive protection, though, because they really solve different problems - variable bandwidth doesn't take into account the reduced reaction time to enemy bullets, escaping rambots etc. But I think that variable bandwidth certainly has applications. Particularly with multi-modal distributions on the wave, the relative danger of particular locations can change considerably if the bandwidth is changed - what was considered to be a safe point between two logged GF hits with a small bandwidth might be considered more dangerous than either of the peaks with a large bandwidth.

Er, precise intersection most certainly handles "how dangerous that part of the wave may be", at least if you take full advantage of the data it returns, to integrate the danger over the full range it returns.

The actual precise intersection just gives the angle range of the wave which could contain a bullet and hit you. It's the stats system which says how likely a bullet is to be within this range, and the danger function which adds other information such as wave weighting.

Precise intersection isn't any better at dive protection than just dividing by distance-to-enemy in your danger function. What it's better at is dodging bullets in tight situations where you're reasonably sure where the bullet is =)

In my view, the wider range of angles that bullets may hit you at, is the only real "current danger" to include in the danger function. Now, it may be appropriate to also add a "future danger" for how a closer distance may affect waves not yet existing, but that should be:

1. additive on top of normal danger (because it's not additional risk of current waves, it's a risk due to being close in later waves)
2. based on the distance-to-enemy at the end of the last wave currently surfed (the future risk is all after that point in time)

Dividing by distance-to-enemy is really kind of a fudge factor that IMO doesn't reflect the real dynamics of the situation very well.

re-reading the comments, it sounds like you may not understand how I calculate danger, so here is a quick summary:

1) KNN with several classifications schemes.

2) Using the points from step one, save the corresponding angles, a weight for each angle, and a bandwidth for each angle.

3) GoTo wave surfing to find precise intersection range of angles for different movement paths.

4) Use integral of sum of functions from step 2 evaluated over the range of angles from step 3 (with bullet shadows subtracted).

5) Use the safest movement path.

With such an algorithm, I am nearly certain that bandwidth strongly influences how frequently I will change direction due to walls.

Makes sense, and actually that isn't different from what I would have expected your algorithm to be.

I see what you mean in terms of the bandwidth impacting the dive protection provided by precise intersection. I see that as a side effect that's not directly related to it though. If your level of bandwidth is bad for the dive protection provided by precise intersection, it should be bad in general, because either way the goal of optimizing the bandwidth should be to estimate the real probabilities as accurately as possible in the circumstance of sparse information.

I feel like a good experiment would be to do something like... take a large amount of wave data pre-recorded... pick out subsets of this data, and with different bandwidths check how closely it matches the distribution of the whole data set.

Thinking about it some more... the main thing I'm wondering, is how to deal with the issue that that ideal bandwidth could vary across different parts of the distribution. One could very well have a situation where say... in the dense part of a distribution, there are enough data points to make it clear that the enemy has VCS bins that are slightly too wide and that you can fit between, but a more sparse part of the distribution also has danger worth considering.

Most of the information I'm seeing in searches for bandwidth estimation for kernel density estimation, involves coming up with a single estimate for the whole distribution, which wouldn't be ideal when the data has widely varying density...

Well, I built my surfing algorithm in such a way that that would be possible, so its a matter of figuring out what the ideal bandwidth would be. My first guess would be to use some function of the distance between the data point and the search point as well as time. But in my opinion this whole idea deserves a lot of research. (I'll ask my professor about using some of the computer labs for robocode)

I'm thinking that the fastest way of doing research on the ideal method for determining bandwidth for robocode purposes, might be to benchmark it outside of robocode using pre-saved data. It would be a lot faster than running battles.