kernel density is important

• Diamond 1.7.47: Math.exp(-0.5 * ux * ux)
• Diamond 1.7.50: Math.pow(2, -0.5 * ux * ux) (.47 vs .50)
• Diamond 1.7.51: Math.pow(2, -Math.abs(ux)) (.50 vs .51)

I know 1.7.51 is far from stable, but it blew away my test bed enough that I'm pretty sure it's a nice jump (knock on wood).

Fun to experiment with!

I just need to figure out where my major performance problems lie, because if I try directly using Math.exp() or Math.pow(), I get hundreds or thousands of skipped turns in a round. I'm pretty heavily reliant on using a fast approximation for Math.exp() right now.. but I don't think I should have to be...

Using the approximator seems reasonable to me. I actually saw that in your version history and played with one a bit in my gun. =) In my main gun, where I do over 10k kernel density calculations per tick, I long ago abandoned gaussian because it was too slow. But I thought with an approximation, which I already had laying around from some experiments with an integral surf danger formula, it might work. It was fast enough, but it didn't perform better anyway...

I've found that a formula that smooths across the whole angle range is really important in movement. And in my movement, it's a max of 200 data points * 12 firing angles tested = 2400 kernel density calculations (across both waves). So until now, I stuck with gaussian because it's the only common kernel density formula I'd seen with that property. But I finally started playing with modifications of that and it was quite an improvement.

Wow, nice work. I haven't really stopped robocoding (does anyone ever really stop?) but I took a break for a while and now I'm working on an R-Tree, and some rewriting for Gilgalad. I had an idea that might push Diamond to the top. As far as I can tell, you only surf three options on the second wave for each of your three options on the first wave. I suspect that the bullet shadows make the dangers much less continuous so that using more points on the second wave would help your score a bit. (For Gilgalad, I thought I had more or less fixed the skipped turns problem by using every 5th point and making sure I got the extreme points in either direction for the second wave, but I got a new computer that has an intel processor rather than an AMD. It's more than twice as fast as my old one from four years ago, but it seems to have way more skipped turns.

Hmm, interesting thought. My original surf algorithm was to check every point along the second wave (in the days of bins and no precise intersection), but just checking forward/stop/reverse somehow always outperformed it. It's true that a lot has changed since then, including bullet shadows, so maybe you're right. But my most recent experiments with changing my surf algorithm were even more significant and came out with almost no change in score, so now I'm a little skeptical about tweaking my surf algorithm. =)

Wow, congrats on these tweaks, although it brings Diamond a bit too close for my liking there! I think that we tend to weight the second wave so low anyways that minor inaccuracies aren't as big of a deal. Wintermute does that though, for each tick on the second wave try stopping and see where the intersection is. It mostly just made it slow.

You mean you only use three movement options on the second wave for each movement option on the first wave? And I've spent all these hundreds of hours optimizing for nothing!

Hey, you can never be too optimized! =)