View source for 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)

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...

Do it. >:)

Kind of a one trick pony these days, but let's see if it still works.

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.

You didn't remove it from Nene there's GuaranteedHitTargeting.class in Nene 1.0.5

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.

In the top 10 it is Nene and GresSuffurd, although GS is using simple VCS surfing with no rolling and a (fairly) simple VCS gun as well.

WaveSerpent is the highest ranking bot that doesn't use DC, not Dookious.

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.

I was replying to GrubbmGait's post.

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 ;-)

You can have a KNN 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...

Combat uses k-NN/kernel density in energy management.

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 would like to see a simplified approach to modeling that kind of behavior.

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.

For the longest time I considered Dookious to be an untouchable barrier. I might be able to get close to it, but never beat it. It is such an amazing robot, and it was the top bot for such a long time.

It is a bit weird to have a robot out ranking him.

Congrats dude! :-)

Pretty exciting times for the top 10. I don't think I've ever seen so much activity at the top of the RoboRumble in all my Robocoding days, and that when it's harder than ever to get there.

I don't think so either!

Looking over the risk system I put into it, it does not seem to take into account enemy 'nearness' at all in the risk evaluations. Meaning it doesn't really take into consideration the distance to the enemy when determining which way to go. In fact it doesn't take this into consideration period. It doesn't even have a catch to avoid ram bots.

The only close avoidance method it has is its minimum risk movement when there isn't any waves (which when you are very close is a percent of the time), and its natural tendency to try and spiral away from the enemy.

It only cares about the waves. Which is fine, and works great obviously (considering the rankings). It just seems to be really good at dodging bullets™. That aside, I am wondering if I should try to hammer some enemy distance risk into it. Considering how potent the movement is already, tweaking anything could really really break it, especially something as key as the risk evaluation.

I (and I believe Voidious) had extremely good experiences with incorporating some sort of way that weights closer points to the enemy as more dangerous. I multiply by botwidth, which effectively divides by distance. I then divide by the min(distance_to_wave_centre,distance_to_enemy) from the test point. I also then weight by how long it will take the bullet to arrive at that point.

Hey, thanks for the advice. I added a really tiny bias to avoid being to close to the minimum of those two things and it is looking really good so far. I hope it can keep this ranking with full pairings.

Just a quick note: you score awful against the (rsim) bulletcatchers, while RaikoMX does score good. You have a few tenth's of points to gain in that area. And congrats for entering the top-10 (and pushing me down).

Apparently Raiko and RaikoMX do not entirely share a gun. Raiko does poorly against them, and it is Raiko's gun it uses. So I don't think it is a movement issue exactly. I know RaikoMX's page says it shares the gun, but there might still be some slight differences between them.

Sorry for pushing you down further, but if I can do it I am pretty sure you can do it to. After all you have been doing it longer.

Anyway I want to get to 8th before I start on a gun. Broken record I know, I want to get to 20th... to 15th... to 10th... I'll write a gun eventually!

Speaking of this however. I have been reading over Nene's code and honestly... it is really confusing. I am not entirely sure why I did some of the things I did. I can only hope, that there was a good reason for doing them at the time. Considering the rank, there `probably` was a good reason for most of it. I just don't happen to remember the reason.

This of course makes refactoring difficult. Maybe I will just rewrite the movement once I get into writing a gun (I have sorta started).

I should get back to work. Tomcat and Xandercat (whoa, both cats), are getting pretty close, only a matter of time before they reach my current rank I think. There is a lot more I can do in my movement department.

The movement has a good ways to go before I consider it 'good' enough. I feel I can probably get it into the top 10 with just modifications to that.

Been considering changing the name, probably will not. Even though I never expected the finished version (with gun) to get this half this high.

I think it will still be awhile before I catch up with Nene. Nene is pretty impressive. Everything easy I can do to improve XanderCat is already done. I'm still working on it though. :-)

I'd watch out for Pris and YersiniaPestis, too. ;)

I think you can feel comfortable yourself in nearest future with Tomcat, because i cannot get stable performance test and development process. So relax, be happy and do not spend yours time on robocode >;-)

I am probably the one who has the most to loose. If either of you guys will pass GresSuffurd, Shadow will pass him also, letting me fall out of the top-10. But still best luck, see if I can pass Hydra before all of you enter the top-10.

And in common, all robocoders, here everything ok, so relax, be happy and do not spend yours time on robocode. You're all in safety and there is no reasons to worry>;-)

Haha, I guess he is saying "It's okay guys, take a break. I'm not going to attempt to take #1 or anything while you're gone, no, never!" :P

Yes, you are right Chase:)