Talk:Nene
Nene is Turkish for Grandmother, at least in the book I'm reading. I'm surprised to see it was the name of a happy, hyper girl. Blubex 15:29, 7 August 2011 (UTC)
The funny thing about names, is that they can come from any number of sources, and mean any number of things. For example Nene was also the name of the most beautiful wife of one of Japans great generals, that is to say Hideyoshi. But still isn't where I got the name. Wikipedia. Names are completely context based. — Chase-san 17:18, 7 August 2011 (UTC)
Haha, Interesting. I'm very unoriginal with my own robot names. Squidman, Tentaclemelee, Octopi, etc.. ( I have a small obsession with tentacled creatures.. ) Blubex 00:52, 8 August 2011 (UTC)
50,51,52
All these and possibly future versions are all part of a large refactor, while I tried to keep the core working bits the same there will likely be issues that need to be sorted out. In case you're wondering why they are bobbing up and down the rankings as they area. Likely later versions will also be possible even more refactoring. — Chase-san 06:12, 20 August 2011 (UTC)
- [View source↑]
- [History↑]
Contents
Thread title | Replies | Last modified |
---|---|---|
Down the Ranks | 4 | 15:33, 9 June 2019 |
Guaranteed Hit Targeting | 2 | 01:37, 15 July 2015 |
Long Standing Bugs | 0 | 06:15, 3 December 2013 |
New Gun | 28 | 04:30, 1 March 2013 |
Untouchable Barrier | 2 | 00:31, 1 March 2013 |
First page |
Previous page |
Next page |
Last page |
Sad to see me lose 4 ranks, but I guess it has been 3 years since I updated Nene. Maybe I should start work on a new robot...
Down to #10, well that's disappointing. I am going to be losing my top 10 spot soon it seems.
Yep, 1.5 year ago I updated GresSuffurd resulting in a 0.5 APS gain, and lost 2 places due to young, smart and active Robocodes. That is the price you have to pay when you're not young and smart . . .
Why does Nene's gun have Guaranteed Hit Targeting when Mint's gun doesn't? Can it increase performance in Mint?
I don't entirely recall, but I think I removed it because it was buggy and didn't work very well. If I never removed it from Nene, it might be able to improve Nene's score by removing it.
But the main difference between Mint and Nene right now is Bullet Shadows and a lot of corner case work that Nene has. Mint was designed to eventually replace Nene, which is why I can backport changes from Mint into Nene.
Nene just happens to be massively complex, where as Mint is highly simplified.
Reading over Nene's movement code for refactoring and gun code (in general) I have found a number of minor bugs.
First, it seems the Heat Wave system is broken in it and never could have worked. Since it never sets the heat waves escape angle. Second, it seems a weight in the gun never worked correctly. Since the timeSinceVelocityChange is always 1 (or 0 on change).
There are probably more, but these are the ones I have found so far.
Well it could have been worse.
But considering it suddenly beats bullet shielders leads me to believe there is a bug in my gun. I'll do some debugging and see what I get.
But I am guessing my problem with some of these is actually my terrible bullet power selector.
Combat beats all bullet shielders except EnergyDome. And without specific anti Bullet Shielding.
Don´t know if there is a bug in learning GF0 angles. At least graphical debugging against SittingDuck looks bug free.
Well Nene beats them all. Plus some of the scores seem skewed in odd ways. Since I tested against some of them with just the gun, and I happen to know the movement is relatively decent.
It seems the fast math in my next position calculator as well as some bad bullet power was really hurting it. Nene ranked 8th is perfectly acceptable to me. I would have been happy with it passing Ascendant. Considering its score it might switch places with Phoenix and end up #9.
Congrats with this improvement. You left me dangling at 10th place. And all I want to do is pass Dookious as that is the highest ranked non-DC bot. Your gun probably has some more room for improvements considering your movement is that strong.
Well the gun wasn't done. But Skilgannon's comment got me thinking. I figure it was overdue.
But this kills two birds with one stone. Means I can change the license entirely to ZLIB, and it sorts out many of the issues Nene was having with surfers and (to my surprise) bullet shielders.
With this development, I am fairly sure Nene is the only top-10 robot who not only has no flattener but also no VG array. This appeals to my sense of simplicity. I am currently going about fixing a few minor bugs in Seraphim. To see where it would have ranked if I had been competent at the time.
We were talking about Virtual Guns and Flatteners. Neither GresSuffurd or Nene use either (as far as I am aware).
Never said that GresSuffurd was the highest ranking VCS. If I recall DrussGT doesn't use DC for its movement.
Yup, DrussGT still uses 'stone-age' VCS for the movement =) I've tried DC several times, but I just couldn't get the same performance. Maybe DC using range-based searches instead of KNN would work better, I seem to remember Jdev saying that worked a lot better for him in movement.
For both movement and targeting in XanderCat, I use a KDTree to store both hits (bullet hits target) and visits (where robot at time bullet would have hit whether it did or didn't). When moving or aiming, a certain number of hits are pulled from the tree using KNN search. Those hits are then dumped into a factor array (with a little smoothing for movement but not targeting). And then the lowest (or highest, for targeting) area of the factor array is where I drive to (or shoot). Visits are only used in my movement, and only when my flattener is active. When talking DC and VCS, what would you consider this to be? I've always thought of it as something of a hybrid, but I don't know if I clearly understand how you all define these terms.
I'd definitely call that KNN (or DC as we do on the wiki), you are just using a discrete kernel density estimation to find your peaks/troughs. Your algorithm would give identical results if, instead of smoothing into bins, you reversed the loops and checked each angle for a 'score' by evaluating its nearness to previous data, which is just discrete kernel density estimation through sampling. VCS refers to the way that the data is gathered in the first place, smoothing the data into segmented bins as it is collected.
DrussGT doesn't use bins until it's time to surf (like you), instead just keeping a list of the last 2*rollingDepth hits for that buffer, but I did the math so that it is functionally equivalent with rolloff and weights, and as such I still call it VCS.
As I've seen it used the "DC" terminology applies to any KNN-based system. I would classify XanderCat's strategy as you describe it as being part of the group "K-Nearest-Neighbor, Guessfactors, with Bins".
Personally I dislike the "Dynamic Clustering" term because it's a bit of a misnomer in my eyes. While ABC coming across this technique and bringing it to Robocode was inspired by clustering algorithms, k-nearest-neighbor search is not a clustering algorithm.
Oh that's what you meant.
I agree with Red that DC is kind of a misnomer. It was similar to k-means with only one cluster. Which is how it got its name. But DC is really just a KNN system.
In that case I want to pass WaveSerpent, as that is the highest ranked bot without any DC in its gun, movement or radar ;-)
Eh? The only way I can think of a K-NN search being useful for radar... would be in a field that is much larger than radar range, to predict the angle the opponent is most likely to come back into view at
Or if you're being very aggressive about an optimal radar, guessing at their movement instead of going as far as they could have gotten. :-) But GrubbmGait might have been making a subtle joke...
Nene uses a kNN for estimating the bullet power of the enemy (for its heat waves).
How do you use kNN to determine the power to fire at?
Most energy management strategies are based on estimating hit rate and then using high bullet powers with high hit rates and low bullet powers with low hit rates.
When calculating kernel density, Combat uses a uniform kernel and checks the density. If there are k waves and x uniform kernels overlapping, it assumes hit rate is x/k. Then bullet power is adjusted accordingly.
Works well in melee. High bullet powers against tight packs of bots, and low bullet powers against lone bots. Low bullet powers against flat profiles, and high bullet powers when spikes are detected.
Maybe simply counting how many bullets hit and how many miss is more accurate, but kernel density is cool.
That it is. So basically you fire a more powerful bullet when your robot is more confident that the bullet will successfully hit the opponent. Possibly based on hit rate of previous shots. That isn't a bad way to do it. How do you choose when you have no data?
With little or no data, it assumes worst case. k is always constant and with no data, x is always zero. It needs at least k waves to have any chance of estimating 100% hit rate.
The strategy works as long as the opponent does not use adaptive movement. Because if it does, spikes in movement profile are usually angles avoided the most.
I spent a bunch of time trying to optimize higher hit rates = higher bullet power. Several times at different points in Diamond's history, even. Even the most conservative of these always performed worse than my hand-tuned formulas. I presumed due to some combination of:
- It's advantageous to use a consistent bullet power for more accurate data classification.
- It's advantageous to prioritize survival at the expense of the bullet damage gained by more aggressive bullet powers.
I've done some work on algorithms to give optimal firing power. My method itself seems quite effective for the most part except there are a few caveats:
- Optimizing for score, optimizing for survival, and optimizing for PL yield rather different results for bullet power. The score vs survival difference is obvious, but optimizing for PL vs score is also important because the risk/reward tradeoffs are different depending on the score thus far in the match.
- It depends on accurate numbers for hit rates. For this I've implemented hitrate calculations which factor out the impact of distance on hit rate, but being able to incorporate other aspects would be better.
- Ideally you ought to try to model the future hitrates, by observing how the hitrates are changing over the course of the battle, however because the amount of data is limited, this can be difficult. It may be best to assume the hitrates are following a certain curve until the battle shows otherwise.
- My modeling of outcomes at different bullet power values is easiest to implement as a monte carlo simulation of the rest of the battle. Implementing this in a bot like I have in the past causes a dilemma, because with few iterations it's accuracy is very poor, but with many iterations it starts to use a very large portion of the bot's avaliable cpu time.
- One could approximate this modeling by curve fitting it, though that could get a bit messy because of how many input parameters influence it. In my next bot I probably will use a curve fitted approximation of my bulletpower modeling.
Part of what really has me feeling good about accurate modeling of outcomes caused by bullet power, is that my implementations have had emergent behavior which I didn't expect at all but makes sense in retrospect. For example, it turns out that if it's almost 100% certain that the opponent will win a particular round, it can be worth it to dump remaining energy into high power bullets to deny the enemy bullet damage score.
I'd love to see direct data of how it compares to what Diamond and DrussGT have right now. I also have well-normalized hit rate data, and even things that seem extremely safe and advantageous, like "use power 3.0 in situations where I expect a hit rate over 25% with 95% confidence" hurt me, or at least didn't help.
I just noticed.
That on adding this new gun, I accidently broke Nene's bullet shadows.
By that I mean 1.0.2 doesn't use them at all! All the code is there, it still considers them, except they never get produced/added. So it acts as if it has no shadows (per default). The thing is I used to route the targeting through a custom fire routine that informed the movement when it fired. But I bypassed that custom routine on accident when I glued the gun onto Nene.
To fix it, I only needed to remove 5 characters. I am going to test this and release a 1.0.3.
First page |
Previous page |
Next page |
Last page |