User talk:Nat

Archived Talk:

2009/04/06 - 2009/06/20

Let see if I get confirmation email. » Nat | Talk » 14:34, 23 July 2009 (UTC)

I think it ignores your own edits. So here you go. =) --Voidious 14:37, 23 July 2009 (UTC)

Thank you, it does ignore owner edits. » Nat | Talk » 14:40, 23 July 2009 (UTC)

Birthday 2009

Attention guys, today is a very special day! At least to me, because today (July 3) is my birthday! Mind giving me a little "Happy Birthday"? LOL » Nat | Talk » 11:15, 3 July 2009 (UTC)

Happy Birthday!--CrazyBassoonist 12:44, 3 July 2009 (UTC)

Lol, happy birthday man! Hope it's a good one ;) --Spinnercat 15:28, 3 July 2009 (UTC)

Happy birthday =) --Skilgannon 15:40, 3 July 2009 (UTC)

Happy Birthday, Nat. Don't party too hard. =) --Voidious 17:26, 3 July 2009 (UTC)

Happy Birthday Nat, hope you have fun ;-) --zyx 18:25, 3 July 2009 (UTC)

                     {}
                     ||
                 ____||_____
            {}  {~ ~ ~ ~ ~ ~}  {}
            ||  { ~ ~ ~ ~ ~ }  ||
          __||__{___________}__||__
         {\/\/\/\/\/\/\/\/\/\/\/\/\}
      {} {        H a p p y       \} {}
      || {\/\/\/\/\/\/\/\/\/\/\/\/\} ||
    __||_{_________________________}_||__
   {\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\}
   {                                     }
   {         B i r t h d a y ! ! !       }
   {                                     }
   {/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/}
   {_____________________________________}

-- Synapse 21:17, 3 July 2009 (UTC)

Haha, happy birthday Nat. Hope it's a good one! --Rednaxela 23:50, 3 July 2009 (UTC)

Thanks guy. Actually I don't have a party, nor cake (except the one above), nor presents =) I've got my present 3 months ago (new notebook that I'm currently sitting in front of) and I hate party! It take the time that I usually sit in front of my computer away. However, this isn't a good one. I've got a cold! Or at least I hope it only cold, not swine flu ;-) » Nat | Talk » 01:38, 4 July 2009 (UTC)

MicroBot Wave Surfing

Anyone have 10TB of memory and hard disk to spare? I need that to perform my own microbot wave surfing. The large part of Wave Surfing is precise prediction, which nonetheless can't fit in micro. I wonder if I cached all the prediction and just access it at runtime. Now I roughly calculated. Let see, I restricted the location, absBearing, velocity and distance to all integer. Total possible location on the map is 764*564 = 430896 locations, multiply by 360 absBearing, ~950 distance, 17 velocity. Saves in short (2 bytes), contain x and y will result in around 764*564*360*950*17*2*2 = 10020917376000 B = 9786052125 KiB = ~9,556,692 MiB = ~9,333 GiB = ~9.114 TiB.

Anyone have ideas how can I reduced those number? If I use 80*60 possible locations, 36 possible absBearing, 17 velocity and 19 possible distance, it still cost 43MB Note that this need to be preloaded into the robot, not calculating on-the-fly. Nat | Talk » 05:17, 20 June 2009 (UTC)

I've done a fair amount of work with precalculated movement table things. I once got a precalculated movement table down to about 2MB, but that's still too big for ethical pre-loading, AND the optimizations it used took rather large codesize to turn into something usable in battle. I don't think you're going to be able make this realistically work Nat honestly. --Rednaxela 05:27, 20 June 2009 (UTC)

=( Well, thanks for the info. » Nat | Talk » 05:50, 20 June 2009 (UTC)

I'll let you borrow my tables when I get around to adding micros to my list ;) --Miked0801 09:02, 20 June 2009 (UTC)

I'm not talking about the VCS table, I'm talking about movement table i.e. the table that allow you to know what is your position next tick if you are at (x,y) with a velocity of v and the enemy is at θ with a distance of d or something. It is the replacement of Precise Prediction used in minibot and megabot. » Nat | Talk » 09:25, 20 June 2009 (UTC)

I haven't dealed with wavesurfing yet, but do you need precise prediction? Is there anything less complex that could replace it? Anyway, take a look at kb.WaveShark, it's supposed to be a wavesurfer. --HUNRobar 14:38, 20 June 2009 (UTC)

LOL, it is kc.WaveShark. Actually it is that robot which inspire me about this. » Nat | Talk » 14:40, 20 June 2009 (UTC)

Pugilist is an example of a wave surfing without precise prediction I think, that might be able to give some inspiration --Rednaxela 15:53, 20 June 2009 (UTC)

Thanks. I have looked at it now, the prediction thing is still too large I think. But I'll give it a try... » Nat | Talk » 16:09, 20 June 2009 (UTC)

Bi-hourly release

Wonder is this is right thing to do or not. Because the number of clients running among this day, I can release my robot bi-hourly. But since I'm not running those clients, I not sure if this is right thing to do or not. » Nat | Talk » 11:42, 21 June 2009 (UTC)

if there are no other bots waiting, not a problem. But, my bot has been waiting for a bit to get to 2k battles in nanos. If you need this much info and are feeling guilty, use roboresearch for your tests. You'll get your answers just as quick without the guilt. --Miked0801 15:26, 21 June 2009 (UTC)

Sorry. When I checked and see the "PAIRINGS COMPLETE" text, I decided that the ranking is completed. Actually I'm not needing it fast, just roughly seen where it place is enough for me to decided what to do with next version, and I usually take only 10 minutes to do it. I'll try to run it on RoboResarch next time. Thanks. » Nat | Talk » 15:39, 21 June 2009 (UTC)

I think the rule of thumb used to be maximum one release per day? There are quite a few bots in the nano & micro categories still below 2000 battles. If you're feeling guilty, run a client and help out... --Darkcanuck 17:28, 21 June 2009 (UTC)

Number of Edits

Hmm... I wonder if the number of edits at Special:Preferences correct? Mine is currently 1,653 (at the time of writing, so perhaps this shall count as another one), but the Special:Statistics said that total edits is currently 9,954. I don't think I make an edit that much. » Nat | Talk » 13:36, 29 July 2009 (UTC)

{{Wikipedia}} template use

Hey Nat, I really recommend you don't use the {{Wikipedia}} template on the Twin Duel and RoboRumble pages like that. The reason being, the text "Wikipedia has an article about: Twin Duel" is very much NOT true, as it's only a minor section. I don't think it's sensible to use this template for one-section-only links. See Talk:Anti-Gravity_Movement#Wikipedia_link --Rednaxela 15:24, 12 August 2009 (UTC)

I see. Thanks, perhaps new template with "Wikipedia has a section about: Twin Duel ... in page Robocode" is better =) I'll remove them. Thanks again. » Nat | Talk » 15:31, 12 August 2009 (UTC)

SDS + Zoom = ?

For any who doesn't know what is SDS and Zoom Targeting, I'll explain briefly. SDS (Symbolic Dynamic Segmentation) is a data management system that you will map the data to a string that represent a state of the data. When you need data, just match the current state with the state of each data. If they are no match or too few matches, just strip last character out and do the match again. Do this until you have enough matches you want.

Zoom Targeting looks similar but indeed it isn't. It have fixed number of 'zoom' level, each level with different preciseness of the states. The deeper the zoom level, the more precise the state is. When you zoom in, it will act more like wave-based pattern matching. When you zoom out it will act more like statistical gun.

Now I'm thinking of combine them together. Like SDS-based data storing and using Zoom Targeting algorithm to choose number of segmentation to use? Any ideas?

Also, please help me think of a name. I'm considering of 'Statistical Zoom Data Management Algorithm' but it won't fit at all. » Nat | Talk » 07:32, 3 September 2009 (UTC)

OOP vs. Pluggable?

Hmm... I want to know, do you guys prefer more OOP or more Pluggable? I mean, I'm development a very pluggable robot (I mean, they have very little shared class) and still OOP-ed (mean that it have clean structure). (While I must accept that current top robot, DrussGT is the most pluggable =)) I realised that my repeat my code a lot. Currently the core of my GF gun contains 6 files: EnemyMovementProfile (interface), GuessFactorGun, GunScanLog, GunScan, GunWave and GunStats (interface). My movement engine has almost exact file with almost exactly the same content (EnemyMovementProfile vs SelfMovementProfile; GuessFactorGun vs WaveSurfingmovement; Gun... vs Movement...). And I can merge a lot of it into single file (or using abstract class) easily. In this case, do you guys choose to use the very pluggable structure with less OOP or more OOP with less pluggability? » Nat | Talk » 10:54, 5 September 2009 (UTC)

I think mixing movement and targeting classes is providing an opportunity for bugs to creep in, because there are many small differences. So for good programming practices try to keep them separate, but that doesn't mean that they shouldn't have many small subclasses. And DrussGT isn't that pluggable, for an example of pluggable look at Dookious or CassiusClay, my next release will be working on that though =) --Skilgannon 11:28, 5 September 2009 (UTC)

One thing I hate about Dookious is loads of utility class in the *.util package. With DrussGT, movement need DrussGT and BufferManager, while gun need DrussGunDC, PreciseUtil and PreciseWave. Dookious, err, have too many files too lazy to copy over =) » Nat | Talk » 11:34, 5 September 2009 (UTC)

I don't really understand - why do you think OOP and pluggable are opposites? A good OOP design will also be pluggable. Dookious certainly tries to be both (and succeeds, I think). Coding style is a personal preference, but since you're asking =) ... My advice would be to use OOP design principles as best you can. OOP is an important thing for any aspiring programmer to understand, and Robocode is a great place to practice those concepts. Also, having code copied in multiple places is a Very Bad Thing, if you ask me (or just about any programmer)! And why not have movement and targeting share code when it makes sense? Of course, pay attention to subtle differences in targeting/movement, but a lot of stuff can be safely shared. --Voidious 16:25, 5 September 2009 (UTC)

I think I have difference definition of Pluggable =) Basically, I mean that Dookious isn't pluggable because I need to copy a whole util package too, which contains a lot of unnecessary classes. DrussGT is pluggable in my mind because I can copy it over without any unnecessary classes. OK, pluggable redefined... Thanks for your opinion. » Nat | Talk » 02:26, 6 September 2009 (UTC)

What I believe you mean, is the scale from Monolithic, to Monolithic Modules, to Granular Modules, to Very Granular Modules. DrussGT would be in the general region of "Monolithic Modules", whereas Dookious would be closer to "Granular Modules", some others like most of my large ones might go into "Very Granular Modules", and things like nanobots are almost always in "Monolithic" of course. Anyway, I believe which is best depends on the complexity of the bot (no point in very granular modules when things are simple enough anyway), and personal preferences. It's quite easy for either too monolithic or too granular to make code hard to maintain/read, but ultimately what's right depends on the bot and the authod in question. --Rednaxela 04:33, 6 September 2009 (UTC)

Yes, thanks. It took me long enough to look into a dictionary (I have been googling for those terms for quite a time and found nothing) =) » Nat | Talk » 07:31, 6 September 2009 (UTC)

Trig Help!

Anyone please help me with this: given the angle a1 and a2 and the distance d, how can I calculate the distance r if the shape is a segment of a circle?

http://nat.robothai.net/robocode/trig-help.png

» Nat | Talk » 06:11, 20 September 2009 (UTC)

Is this the only info you have nat, or do you also know exactly where the origins of a1 and a2 lie on the circle? --Positive 09:23, 20 September 2009 (UTC)

Yes, this is all information I have. I'm not sure it can be calculated. In my melee gun development, I use very rough (but better than linear) approx. for interpolation, but if I can calculate this, it will be much more accurate. » Nat Pavasant » 09:34, 20 September 2009 (UTC)

I think the answer is that the length, r, is Math.asin((d/a)/2)*2. Where d is the mentioned distance and a is the radius of the circle. You use the Math.asin function the calculate the angle z in radians. Multiplying the angle z by two gives the total length of r. Correct me if I'm wrong. :)

Hmm... I think you are correct, only that I don't know the radius of the circle... Note that a1 and a2 is the angle from line d to the dotted line, not r, so... I'm not sure, but I think a1 is equal to a2? But it still doesn't help. » Nat Pavasant » 10:22, 20 September 2009 (UTC)

It might just be my internet connection, but I can't get your image to load. If you upload it to the wiki I might be able to help. --Skilgannon 20:44, 20 September 2009 (UTC)

South Africa? I know some countries can't access this host (Netherlands, for one). Basically, the green lines/text, gray dotted line, and the curve r from Red's pic are mine. » Nat Pavasant » 11:22, 21 September 2009 (UTC)

I belive I've solved it Nat. Here's a picture with the solution, and some rough work overlayed on the original image :)

--Rednaxela 22:17, 20 September 2009 (UTC)

Thank you very much! But can you explain what is c please? I don't understand it. Thank you again. » Nat Pavasant » 11:22, 21 September 2009 (UTC)

c is circumference. He was just deriving the formula for arclength, which is radius*theta where theta is in radians. Also, b1 and b2 form an isosceles triangle with the radius, so b1 = b2 thus a1 = a2, so the formula can be simplified a bit =) --Skilgannon 11:31, 21 September 2009 (UTC)

Oh, thank you. *slap myself hard* How could I forget the formula for circumference? Hmm... I think I said somewhere about that a1 == a2 so the final answer will be <math>r = {{2a \times d}\over{\sqrt{2 - 2 \times cos(2a)}}}</math> where <math>a</math> is the angle. Will try this with the movement interpolater tonight =) » Nat Pavasant » 11:43, 21 September 2009 (UTC)

Movement Interpolater

Well, I just uploaded my File:Nat.Interpolater 1.0.jar. But there are still a few problems which I can't figure out what and how to fix it. First is when enemy change its direction, it mostly predict in something messy. Second is sometimes it don't get into fullAccl/Decel (look at the source code) mode. Thank you in advance. » Nat Pavasant » 16:02, 22 September 2009 (UTC)

Twin Duel battle selection

Hey Nat - I noticed you're running a lot of Twin Duel battles. I noticed that when everyone has enough battles, only four bots were getting battles from my clients, and it looks to be the same for you right now if you check the rankings. If you want to contribute battles evenly, I think you'll need to raise the BATTLESPERBOT to something higher. --Voidious 14:56, 23 September 2009 (UTC)

Yeah I noticed that too. It seems that I'm not able to finish my twin duel team shortly so I stop running it, for now. » Nat Pavasant » 15:10, 23 September 2009 (UTC)

Fast Play-it forward algorithm

Anyone know how to do fast Play-It Forward (like in Shadow?) I tried many ways, but still doesn't do as good as step-by-step method, which is so slow (my 13-dimension KdTree is slow enough) I tried to understand what ABC say at oldwiki:DCBot too, but fail. Any ideas? ABC? Nat Pavasant 23:49, 27 September 2009 (UTC)

I'm not sure how Shadow does it, but the way I way I do it is along the lines of the following: 1) Estimate the bullet-travel-time based on current distance and bullet speed, 2) skip that much time forward in the log, 3) check if the wave has passed, isn't there yet, or is just right, and if it's not just right make a revised bullet-travel-time estimate and go back to step #2, otherwise continue, 4) Only now, check if the final point is within the battlefield. To my understanding, this is along the same lines of how Shadow does it, but I'm not certain. It's requires iterations, but is far far faster than traditional play-it-forward. Also, while it isn't as strict when checking paths don't go out of bounds, it that tiny loss in accuracy is well worth it for the speed it gives for things like melee. --Rednaxela 00:42, 28 September 2009 (UTC)

I think this is how old Shadow does, I think new one do something like convert the current vel/heading to the relative point. When aiming, just add series of relative points and rotate the result location or something, but I never successful implementing this. Nat Pavasant 00:45, 28 September 2009 (UTC)

I fail to see how what you describe could be any faster. What I do is just calculate relative point between the two points in the log, and rotate that, and add to current location. Storing it as a series of relative points in the log would make it slower so far as I can tell, since it doesn't remove any steps yet adds an extra step of doing the summation. --Rednaxela 00:52, 28 September 2009 (UTC)

No, it is like:

double bulletD = 0;
int round = scan.round;
double x = 0, y = 0;
while (M.sqr(bulletD) < Point2D.distanceSq(x, y, last.distance, 0)) {
	bulletD += bulletV;
	x += scan.relativePoint.getX();
	y += scan.relativePoint.getY();
	scan = scan.next;
	if (scan == null || scan.round != round)
		return null;
}
Point2D newEnemyLocation = new Point2D.Double(x, y);
newEnemyLocation = rotate(newEnemyLocation, last.heading);
newEnemyLocation = new Point2D.Double(newEnemyLocation.getX()
		+ r._enemyLocation.getX(), newEnemyLocation.getY()
		+ r._enemyLocation.getY());
if (!_fieldRect.contains(newEnemyLocation)) {
	return null;
}

This is my not-really-working code, but I hope it can describe what I'm telling. Nat Pavasant 00:55, 28 September 2009 (UTC)

I don't see how that could work. The geometry of distanceSq(x, y, last.distance, 0) seems completely broken. That does give me an idea of what would work though: Instead of rotating the relative point every time, just rotate your firing point into the perspective of the old log. That would allow checking the distance between the future enemy location and the firing point very efficently. --Rednaxela 01:06, 28 September 2009 (UTC)

Well, because (x,y) start at zero, and the relative point is rotate((xDelta,yDelta),enemyHeading). Thus, my current position will be at (enemyDistance, 0) Note that last is the last scan in the log, i.e., current scan. Or am I wrong here? Nat Pavasant 01:12, 28 September 2009 (UTC)

I'm pretty sure the rotation should be the difference between the current enemyHeading and the enemyHeading at the start of the log sequence, thus no that wouldn't make sense much sense. What I proposed is similar to your code snipped though except: 1) the rotation is fixed as I note, and 2) your current location is your relative location, rotated to be from the rotation of the starting log entry --Rednaxela 03:01, 28 September 2009 (UTC)

scan.relativePoint = getVector(scan.headingDelta, scan.velocity); is how my relative point storage work. Nat Pavasant 03:51, 28 September 2009 (UTC)

Ahh, that makes more sense, and in that case, I see why your code doesn't really work: Adding the x and y values for the delta heading vectors like that together cannot yield a correct answer. Since it's delta heading vectors, when reconstructing a path, each vector needs to be rotated by the ones prior to it... and fixing that would make this method slowish again. --Rednaxela 04:30, 28 September 2009 (UTC)

Oh yeah... Thank you.

Anyway, do you understand how this work:

Yes, but that description is a mix of DCBot's and Shadow's current method. In DCBot I used the "iterative search" to speed up the trig needed to convert the enemy's past position to the position it would be in the current situation. Doing that step by step is slow, like you mentioned. But then I remembered I could just convert my relative position to the enemy once at the beginning and then the play-back of the enemy movement becomes just additions of dx/dy. And the final firing angle conversion is just 1 addition. It's so simple! I don't know how I didn't come up with it earlier. Now that I think of it, I can probably compare squared distances and save a sqrt per step. About the rotated battlefield, I thought about that, but that would reintroduce the trig complexity and would probably end up slower than the original method. -- ABC

? Nat Pavasant 04:35, 28 September 2009 (UTC)

Well "convert my relative position to the enemy once at the beginning" sounds exactly like what I proposed above, however I'm not sure what is meant by "And the final firing angle conversion is just 1 addition" since I still think that last step would involve trig... --Rednaxela 05:02, 28 September 2009 (UTC)

I got a working implementation of what ABC does. Take a look at oldwiki:DrussGT/HelpRequests for a coded version of this. (The problem I actually had was that I was recording heading in degrees, not radians). --Skilgannon 05:49, 28 September 2009 (UTC)

Thank you! --Nat Pavasant 06:29, 28 September 2009 (UTC)

Ahah! Shadow'smethod is indeed exactly what I described with projecting the firing location into the perspective of the history. :) Now... what will make the fastest projection perhaps... will be combining that method with the fast-forward base on bullet-travel-time estimation :) --Rednaxela 06:14, 28 September 2009 (UTC)

Well, I think in this case the overhead/re-calculation of the BFT estimation will make it slower than ABC's method. --Nat Pavasant 06:29, 28 September 2009 (UTC)

Yep, I do exactly like Skilgannon's code. It's very fast, don't know if the iterative BFT search would make it faster, for long BFTs it probably would. --ABC 11:30, 28 September 2009 (UTC)

How about jumping forward BFT ticks and then just doing the regular tick-by-tick simulation (either forwards or backwards) from there? I think that would probably be fastest. --Skilgannon 14:33, 28 September 2009 (UTC)

Hey Nat. I've seen that you are trying to use melee surfing. For dodging the bullets you can get the distance to closest bullet and create some points in that distance. It works well in melee but it dowsn't work very well in one on one because it uust goes to a safe point. Not the safest one. It is also very easy to use.

So I have been gone for about a year and a half, and want to go back to this game again (guess you can never left robocode completely).

Basically, what innovations/technological breakthrough did I miss?

Not sure if you noticed, but we transitioned to LiteRumble when DarkCanuck's server went down. Sheldor and I took the nano crown with a collaboration bot, Yatagan. Nz.jdc updated LittleBlackBook's table, and wrote his own table-driven bot. They are both above Yatagan in the nanorumble, but they are sort of cheesy because they react to enemy name, not enemy behaviour. DrussGT now has a bullet-shielding mode which is tried at the beginning of each match. Chase finally found a bug in Seraphim and its APS now matches its strong PL score. I improved Neuromancer's 1v1 score a lot, and got it to 1st in melee.

I'm sure I've missed a lot of other stuff.

I just couldn't give up on that robot. Even though I wanted to. I might have to go back and look over other old robots of mine and fix errors in those, and re enter them into the rumble. Like Tyrra.

Welcome back!

• RoboRumble 1v1 crossed 1,000 participants.
• I wrote RoboRunner, a new multi-threaded battle runner, and Skotty wrote RoboJogger, a GUI version of it.
• We upgraded to MediaWiki 1.19. So the Twitter feed and bigger font got reverted and we still haven't fixed it. Need to upgrade PHP before moving past that.
• Personally, I've written/released a game called BerryBots in that time, which spawned from the Raspberry Pi discussion here at the RoboWiki. Right now working on replay support, which is almost ready (sample).

I restarted working on Roboflight again for a bit, made it easier to write stuff in, currently on the back burner though. Not sure if you were around for it, but I also finally added a proper gun that I wrote to Nene. Aside from that a lot of robots have been updated in general.

Thank you. It seems that I does miss a lot :)

This ought to cover a lot.

Skilgannon's and my bot Yatagan did quite well in the NanoRumble. My bot EpeeistMicro has a perfect PWIN (PL percentage) score in the MicroRumble. I still haven't started writing a minibot yet, but I do plan to sometime in the current century. :)

Would this be a good extension to install on this wiki?

I'm open to it if people want it. Would you have preferred to login with OpenID?

Only problem I see is it requires MediaWiki 1.21 and we're on 1.19. I think I stopped there because it required upgrading PHP, but we should do that and upgrade MediaWiki sometime anyway.

I am not even sure why he made this post on Nat's talk page. That said, I never found OpenID to be that easy to use (or to setup to use).

It would be easier for the end user and probably to setup to use one of the many "Login in X" systems. Where X is Twitter, Google, Facebook, or what have you.