View source for User talk:Tmservo
These Two Versions of Linio are different jcz.linio.Linio 1.0,https://www.dropbox.com/s/m4yq1gsf6f67cmh/jcz.linio.Linio_1.0.jar jcz.linio.Linio 1.0.H,https://github.com/L1ni0/rcb-bin/raw/master/jcz.linio.Linio_1.0.H.jar
- [View source↑]
- [History↑]
Contents
Thread title | Replies | Last modified |
---|---|---|
does bin smoothing make guns better or worse | 8 | 03:09, 26 November 2013 |
netbeans vs eclipse | 1 | 14:24, 23 November 2013 |
AW's kd-tree | 15 | 00:38, 15 October 2013 |
Skilgannon's kd-tree | 30 | 20:43, 11 October 2013 |
First page |
Previous page |
Next page |
Last page |
In movement, Bin Smoothing helps bots dodge bullets with a margin of safety.
In radar, why would you use bins?
In guns, Bin Smoothing helps spot crowds in melee/team if combined with swarm targeting. In 1v1 I don't see any use.
You do not have permission to edit this page, for the following reasons:
You can view and copy the source of this page.
Return to Thread:User talk:Tmservo/does bin smoothing make guns better or worse/reply (4).
Instead of applying methods of estimating the correct amounts of bin smoothing, people tend to switch to kernel density and tune the kernel function. There was a lot of discussion about the best kernel function and the best function width. The optimal changes for each opponent and some kind of averaging is needed, which is usually estimated through genetic tuning.
In guns, smoothing usually has no effect because you don't need to estimate the PDF, you only need to find the peak. But when you superpose many PDFs together (swarm targeting), things change.
Estimating the PDF can still a useful component of finding the peak when not superimposing things, particular when the density of observations is sufficiently low. The main reasons you don't see much effect in targeting is that the usual bin sizes inherently act similar to a certain amount of smoothing anyway, and for targeting you have a larger number of observations than movement which reduces the amount of smoothing that makes sense as well. Consider what happens when your bins are significantly smaller than what is typical without any additional smoothing. (A targeting system that accounts for botwidth also reduces the amount of smoothing that makes sense, but that's a bit of a different matter)
For me two things make smoothing more useful in movement than in targeting:
- Movement needs to estimate probability at arbitrary points, instead of a single peak, so the location the probability is required at isn't related to where data is available.
- Movement has much less data than targeting, so smoothing is needed to fill in gaps in knowledge.
Theoretically smoothing might help in targeting, but all my testing has shown that a simple square kernel works just as well or better, while running many times faster.
I've also considered something like Kalman filters, but they are Unimodal which doesn't work for targeting or movement at all. Perhaps particle filters, although the histogram filters we have right now in VCS also work pretty well.
re: why in movement, agreed 100%.
With WaveSim, I've tested different kernel densities (effectively smoothing formulas) in my main gun over a huge data set. There were differences, but IIRC on the order of thousandths of a percent in hit percentage (eg 12.004% vs 12.002%). Not sure of the margin of error, either... 5k battles * ~25k ticks = millions of records, and both algorithms were running on the same data set.
I use Eclipse. I don't use NetBeans in years, so I can't really compare the new versions against each other.
But in general terms, most of Eclipse features are based on plug-ins, which means you won't find all the features you need on the basic installation, but there should be a plug-in somewhere doing what you need. NetBeans is a fixed pack, if it has everything you need then it's fine, if not, then you will need additional tools outside NetBeans.
I suggest you stop worrying about how fast a particular kd-tree is and just use one of them. The top few kd-trees are all very similar in performance and I am sure each have their pro's and cons. I personally still use Rednaxela's Gen 2 tree because of how self contained it is (vs his Gen 3 which has more structure).
If you were using it for Robocode I don't think you'd be worrying about which one. What are you using the tree for?
The tree that I have, is approximately as fast as rednaxela's 2nd gen. (slightly faster in my tests). Are you trying to write a kd-tree or just looking for one to use? As far as I know, jk's tree, rednaxela's tree, and my tree are all quite similar. Bucket kd-tree. No recursive search methods. Use a MBR (minimum bounding rectangle). Use a heap to store the points. I think rednaxela was the first to introduce most of those ideas to robocode, but in my tests, mine was slightly faster and presumably the same can be said of JK's tests.
there is no kd-tree at http://robowiki.net/wiki/User:AW/kD-Tree but there is kd-tree inside gilgalad
Soooo, I've been staying out of this because I have nothing constructive to offer... But FYI, the fact you ignore pretty much every question someone asks makes you seem suspicious. And asking/demanding things without listening makes you seem rude.
If you'd engage in a conversation and tell us your situation, we could probably offer you a lot more help. If you're doing something shady, like cheating on homework, and that's why you're being so secretive, we probably don't want to help.
They're pretty much tied. Mine might be a little faster on systems where the data in the Kd-Tree is frequently pushed out of cache.
No, as I said above, they are mostly the same except for cache conditions.
3rd gen is the fastest of Rednaxela's trees. There's also a k-NN algorithm benchmark if you want to run some tests.
First page |
Previous page |
Next page |
Last page |