Archived talk:User:Rednaxela 2012-05-16

Hey, Rednaxela. Are you repine with me? At first you answer ALL my questions and comments, but in last weeks, you answer none of my questions/comments. » Nat | Talk » 12:24, 22 March 2009 (UTC)

No no, not repine at all. I've just some of the recent ones I've been less sure of the answer to, and been rather distracted for the last while. Sorry about that. --Rednaxela 15:53, 22 March 2009 (UTC)

Java assembly is fun. I've downloaded a bytecode reader plugin thing in eclipse, and it's very helpful for codesize stuff. I will try Jasmin in the near future (though for complicated code I'll still probably use Eclipse)
Also reiterating question here: why does ldc take up 1 byte less than sipush (i.e. why does loading the int 32768 take up one byte less than loading 32767)? --Starrynte 17:58, 9 April 2009 (UTC)

Hmm, well, looking at the CodeSize util, it uses Apache's bcel, and the codesize is the summation of Code.getLength() calls on things in the bytecode. A brief glance at the bcel code indicates this is the raw size of the bytecode in bytes... so it appears that sipush takes one more byte in bytecode by nature? I'd have to check the java bytecode specs. --Rednaxela 18:51, 9 April 2009 (UTC)

---

Rednaxela, where do you come from? You said that you are Canadian, and your roborumble flag is Canada, but here is show that you are from Afghanistan. » Nat | Talk » 10:48, 12 April 2009 (UTC)

... Hahahaha! On Roborumble.org I accidentally left it as that when I made an account to test it with, and since roborumble.org leaves no way to change it after, it's stuck as that. Ignore that silly mistake XD --Rednaxela 14:37, 12 April 2009 (UTC)

---

PolishedRuby is mirror movement with FlemmeRouge (RougeDC), right? When I see the name 'PolishedSaphire', is it mirror movement with SaphireEdge? » Nat | Talk » 13:20, 13 April 2009 (UTC)

Yes, and also possibly using movement tables from SaphireSlippers in order to have a more optimal goto for the mirroring --Rednaxela 13:37, 13 April 2009 (UTC)

---

Next time please make sure you post on the talk page. It look really funny when the user page is your and on the talk page is mine. Anyway, as I'm slower you got the place. I was watching his robot battle before click submit, which is obiously too late. » Nat | Talk » 16:36, 31 July 2009 (UTC)

Haha, whoops. Hm, I should watch more battles with new bots... --Rednaxela 16:41, 31 July 2009 (UTC)

Slow Algorithms

Well then... I set up some code to via brute force calculate nearly all possible ways a bot could move (restricts turning to 3 possible values and acceleration to integers) within a given amount of time. To calculate for 10 ticks it took about 1 second, which is very good for my purposes. To calculate for 20 ticks however... it didn't seem to stop even after hours so I calculated roughly how long it would take with my algorithm that got 1 second for 10 ticks and it turns out that for 20 ticks would take at least 110 years!!! Wowzers... looks like I'll have to diverge from brute force and work with some methods that drastically reduce calculation at the cost of significant approximation... --Rednaxela 16:07, 26 January 2009 (UTC)

Those exponential algorithms =S, maybe instead of approximating you could prune branches of your search tree, a lot of states will be very similar and some others will have low probability. Hope it gives ideas to improve your algorithm. --zyx 23:42, 26 January 2009 (UTC)

Well, for my purposes, pruning low probability states would be unacceptable, however I am planning to redesign it so it can prune sufficently similar (or exactly the same if I can afford it?) states of each tick. The memory requirement will unavoidably be drasticaly increased however in order to make non-recursive as that would require. Hopefully that memory requirement increase won't get too high. I intend to make these calculation for at least 100 ticks so yeah... Hopefully I won't need to borrow a supercomputer to get SaphireSlippers on the road... --Rednaxela 02:06, 27 January 2009 (UTC)

How about working the other way around? Instead of working out all the different ways you could move, and seeing where you end up, take lots of different places, try to get to them, and see where you end up. (Basically, my style of GoTo Surfing ;-) ) This way it is very easy to limit computational time: just increase or decrease the granularity of the places you are using as 'targets'. And also: what's up with 1 second of computational time being acceptable? Are you pre-computing all possible locations, and then just transforming them at runtime? My guess is that would be slower than precise-prediction due to evaluating the danger at the HUGE number of possible positions. Although I can see it's usefulness... finding optimal locations considering distance etc. For a 'pruning' technique, how about 'merging' all entries that are at the same velocity and have less than a certain amount of difference in the heading and the location? --Skilgannon 10:01, 27 January 2009 (UTC)

Nah, choosing destinations like that defeats the main resons for this method: It allows the robot to be completely aware more optimal ways to get to a location than a robot's typical goto(location), inherently know the perfect amount to smooth movement around a wall, and inherently will know exactly how much slowing down on big turns is right, and so on. And yes, 1 second i extremely acceptable because I'm precomputing a table that designed to be quick to look up at runtime for: what locations can be reached, any possible ways to get to them, and enough just enough information to in order to know at runtime if a wall will be blocking one of the ways to get there. Also, as for runtime performance, I avoid the number of possible locations to evaluate at runtime being too "HUGE" by putting the end resuts into a resonable finite number of 'slices' of sorts. As far as 'pruning' to improve computation speed, what you say is essentially what I'm planning :) --Rednaxela 14:53, 27 January 2009 (UTC)

---

Surfing

Melee Surfing

As you write to me, I now have some new ideas on melee surfing!

I'd agree with your wave detection, but I have some new Surfing ideas to you!

For surfing, you need multiple ways of Precise Prediction (or your Slow Algorithm). Only return set of points before the first wave hit. I think 8 ways should be enough. Now, for each of these points, do minimum risk! Multiply risk by wave danger and move to lowest. And one more ideas, you should surf non-firing wave, too. only weight a little bit lower since many melee GF gun take stats from non-firing wave.

I don't implements it yet but I'll use it in melee-compatible version of BlackHole (not sure for 0.2 but I promise I'll have it in 0.3).

I'd like to named this style WS-MR. You may named it if you finish first, but it a nice name.

» Nat | Talk » 07:20, 14 February 2009 (UTC)

Rambot Surfing

Ha ha, I really like your rambot surfer ideas! Do you have any ideas about it? I have.

In Voidious's Komarious movement, he use a little bit lower than half pi, so you may use a lot over half pi (let say 2.25 or more) in order to surf. Let say more, I think it will have an opposite way of Dive Protection (It avoid getting too close? this form will avoid getting too far.) You may add some factor to your wave surfing to cornered you enemy (like another rambot).

Once you getting enemy cornered or getting very close (say 150px), go ahead and ram him. That's all my ideas.

» Nat | Talk » 07:20, 14 February 2009 (UTC)

I've released WaveRammer. Is that what you planned to created? » Nat | Talk » 08:35, 14 February 2009 (UTC)

Hint about plans

Here's a random hint about my current experiment: Why do we have the divisions between segments only divide across one axis as at a time? Surely we could divide across any hyperplane in the data set... ;) --Rednaxela 20:26, 30 April 2009 (UTC)

Oooh, exciting! Reminds me of Support Vector Machines, which we touched on in a Machine Learning class in college. I actually tried classifying some data I collected with my Voidious/WaveRecorder bot with an SVM when I still had access to MATLAB at school, but it didn't seem any better than anything else I was tinkering with, and the prospect of coding one from scratch seemed so complicated, that I quickly moved on. Best of luck! --Voidious 20:36, 30 April 2009 (UTC)

Hmm, interesting, I never actually read much about SVMs before... My approach is kind of related I think. I take the hyperplane generated by a least-squares fitting of the data, then I split at the median value (GF) that the least-squares fit generates for the data points. When I get a certain amount of data points, I lock that hyperplane and splitting value in place, and recursively run the process on the data points on each side of the split. This generates a tree, that's not all that unlike a Kd-tree except that the splits are in more than one dimension at once. This results in the input space being subdivided in a "stained glass" like manner as opposed to hypercubes like traditionally segmented VCS. So then, within each of these nodes in the tree, I store VCS data , and when figuring out where to aim, I decend the tree until I get to the node where the current situation fits, summing the VCS data as I descend. This should result in something somewhat similar to a VCS gun except that it's self-segmenting, has more flexability in segmentation, deals with sparse/dense data gracefully, and other interesting things I plan to explore. --Rednaxela 22:08, 30 April 2009 (UTC)

Well, my gun based on that plan didn't really work out. It ran, and it was easily better than an unsegmented GF gun, but the problem was that it made it's subdivisions in the data, too quickly, based on too little information, however if I made it wait longer, it would build it's segments too slowly.

Some More Plans

My current plan? Dynamically Shifting Associative Clustering Tree. If you look up associative clustering you will find a variety of related things. My current algorithm is kind of a hack to do associative clustering with a weird modification on normal k-means clustering, however some papers in google show some methods which are more formally accurate than what I have. I may switch over to one of those (particularally if my method proves too inaccurate or slow). So yes... implementation of the clustering is mostly done with my weird method, and it's mostly a matter of linking it to a gun... --Rednaxela 12:50, 22 June 2009 (UTC)

Youtube template

The youtube template is pretty cool, I'll keep it. :) Although it perhaps it will be impractical if pages contain multiple youtube links? --Positive 01:38, 15 August 2009 (UTC)

Hm? In what way do you mean impractical if it contains multiple youtube links? I'd imagine in most such cases it would only be one or two per section of the page, and I think that'd work just fine.probably. --Rednaxela 03:27, 15 August 2009 (UTC)

Okay, that's true. Most pages don't need several videos. :) --Positive 12:04, 15 August 2009 (UTC)

I really love the new template. And Positive, thanks for posting all the videos! Way cool. --Voidious 15:42, 15 August 2009 (UTC)

Leapfrogging goal

I definitely appreciate the goal, but if you wait another two weeks before releasing this bot, leapfrogging Diamond and Portia may well put you at #1. That's a pretty lofty goal with a first version. =) Looking forward to your entrance, though - good luck. --Voidious 15:40, 31 August 2009 (UTC)

Thanks. I just need to write the code for calculating my new top-secret melee targeting dimensions, then I'll be releasing GlacialHawk. I know how to calculate it, but I just need to figure out how to most efficiently calculate it. :) --Rednaxela 16:09, 31 August 2009 (UTC)

RoboResearch TCRM

How can I fixed this problem with RoboResarch TCRM?

Thread 3: Unrecognized output from robocode, "Aborting battle, could not find ro
bot: apv.AspidMovement 1.0".  Killing battle.
Thread 3: Unrecognized output from robocode, "Aborting battle, could not find ro
bot: apv.AspidMovement 1.0".  Killing battle.
Thread 3: Unrecognized output from robocode, "Aborting battle, could not find ro
bot: apv.AspidMovement 1.0".  Killing battle.
Thread 3: Unrecognized output from robocode, "Aborting battle, could not find ro
bot: apv.AspidMovement 1.0".  Killing battle.
Thread 3: Unrecognized output from robocode, "Aborting battle, could not find ro
bot: apv.AspidMovement 1.0".  Killing battle.
Thread 3: Unrecognized output from robocode, "Aborting battle, could not find ro
bot: apv.AspidMovement 1.0".  Killing battle.

??? I have apv.AspidMovement_1..0.jar in my robocode_bots directory. » Nat | Talk » 17:31, 31 August 2009 (UTC)