http://robowiki.net/w/api.php?action=feedcontributions&user=Simonton&feedformat=atomRobowiki - User contributions [en]2024-03-28T16:39:38ZUser contributionsMediaWiki 1.34.1http://robowiki.net/w/index.php?title=User_talk:Pedersen/kdTree&diff=15234User talk:Pedersen/kdTree2010-03-11T17:04:44Z<p>Simonton: Blasphemy!</p>
<hr />
<div>I don't have an application for a tree yet (though conceivably it would work with a gun if I bothered to develop weights for the various dimensions, after determining what those dimensions should be) but I figured it would be fun to whip one up. It turns out it was pretty quick to crank out, and after a little debugging I not only had blazing fast speeds at high volumes, faster by far than the samples that came with the benchmark at about 5000 data points, I found that at about that range I started dipping below 100% accuracy. I have spent most of today, longer than it took to write the first draft, trying to find out what is going wrong. As the day winds to a close, I've found that I can get it to bleed accuracy by setting the capacities really low, which will also help with debugging (in terms of diagramming out in code and by hand). When I set the dimensions to 2, neighbors to 10, and sample size to 50, along with a bucket size of 4, I caused it to hit 90% accuracy. My time is up today though, so I'll have to proceed with debugging another evening. --[[User:Pedersen|Martin]] 00:27, 6 March 2010 (UTC)<br />
<br />
The fact that accuracy bleeds as bucket capacity goes down, suggests to me that something is wrong with the logic for when to descend a branch or not is broken but the logic for processing points within a leaf is fine. Chances are you'll see accuracy decrease much further if you increase the count of fetched neighbors while keeping bucket size constant. Given the results you've said, it's quite possible that it is never descending into 'second choice' paths ever in fact. --[[User:Rednaxela|Rednaxela]] 01:10, 6 March 2010 (UTC)<br />
<br />
: It could be (also) using the nearest value to determine if the next path is viable, rather than the furthest in the current matching set. --[[User:Chase-san|Chase]] 02:06, 6 March 2010 (UTC)<br />
<br />
I've suspected that the problem is when I split more than once in the same dimension, but that speculation hasn't borne out through trials. I know it has to do with the logic for talking alternate branches, since if I remove the conditional logic and force it (i.e. a full tree search) it gets 100% every time. --[[User:Pedersen|Martin]] 05:03, 6 March 2010 (UTC)<br />
<br />
My hypothesis was that I could eliminate alternate paths by finding the distance between the reference point and the plane across the splitting point. The problem arose because rather than finding the simple distance in the same dimension between my reference point and the splitting plane, I was finding the distance to the exact point where the plane intersected all of the previous planes used to reach the present point. That was a bit wordy, so I'll give an example. Let's say our point is (7.5, 7.5). So far we have branched at 5 on the X axis and then 5 on the Y axis. The distance I should obtain is 2.5 (distance between (7.5,7.5) and (7.5,5.0)), i.e. the closest possible point on the other side of the splitting plane. Instead, I was finding the distance to (5.0,5.0). Many eligible values could have lain in the arc that I culled. <br>Getting the distance corrected has fixed the accuracy problem, but now I am walking a heck of a lot more tree than previously, so it is much slower. My own 'flat tree' search is outperforming it, and it only outperforms Simontons's, in terms of reference implementations in the benchmark. --[[User:Pedersen|Martin]] 21:58, 8 March 2010 (UTC)<br />
:Scratch that. I still had a bucket size of 4 from my stress testing. Putting the buckets to 40 (first test) put the performance halfway between Red's and Void's. So I'll have a contender yet, though I know Red has some stuff that hasn't been released yet. --[[User:Pedersen|Martin]] 22:07, 8 March 2010 (UTC)<br />
<br />
Well, I posted the code, in case anyone wants to see my raw implementation. I started with Duyn's tutorial, at least as far as the Exemplar class and making the KDBucketTree class use generics, so that much at least will look familiar. There may also be other familiar parts, but I think at that after about 10 minutes I went off the reservation and ran with it. I made some tweaks to run with the benchmark tool, and then came a simple bug fix followed by the planar distance described above. Since then I also made a 5-way branching tree as a test but it didn't seem any better in terms of speed so it is back on the shelf. There's definitely room for improvement. For example I presently make no effort to re-balance the tree. When my sample exceeds my bucket capacity I sample all the data ranges and use the mean of the largest range. I avoid the infinite loop problem Red mentioned by not testing for re-splitting after a split. It will take a new element being added before testing for a split. Ultimately it may get a stack overflow error anyway. /shrug Another improvement could be to keep a list of all splitting points, find the squared planar distances from the control point, and processing them from nearest to farthest until the closest neighbor is closer than the closest plane. That would mean an end to walking the tree though. --[[User:Pedersen|Martin]] 01:05, 9 March 2010 (UTC)<br />
<br />
<pre>public class KDBucketTreeComparator<T extends Exemplar> implements Comparator<KDBucketTree<T>> {</pre><br />
After figuring out how to define a Comparator for a generic class (above), I was explaining the design to a co-worker buddy and my design for "finding nearest neighbors by walking through a list of Leaves rather than walking the tree" fell apart for two reasons: 1) leaves don't have splitting planes, and 2) the splitting plane concept only applied to following the least favorable branch, which is lost if you aren't walking the tree. I'll still mull over the potential, but this is a setback. --[[User:Pedersen|Martin]] 21:44, 9 March 2010 (UTC)<br />
:I created another speedy-but-flawed implementation, getting in the 95-100% range at about a third of the KNN time of Void's at 100k records. It even beats his linear search by 1ms. It is just me, or are the flat searches faster than the tree searches for everyone else? I thought the trees were supposed to be a performance gain... But I digress. The new implementation still creates a tree but no longer walks it for finding nearest neighbors. Instead, it finds the distance to the nearest corner of every leaf, sorts them as a PriorityQueue, and walks through them until the closest neighbor is closer than the closest corner of the next leaf. --[[User:Pedersen|Martin]] 00:09, 10 March 2010 (UTC)<br />
::Well, the fix was pretty simple. Turns out that PriotityQueue.iterator() is useless, so you can't do a modern for-loop. A minor refactor and the implementation is back on its feet and faster than the fastest benchmark tree, but I really think it should be even faster, so I'll mosey over to the recent post by Duyn about PriorityQueue performance. --[[User:Pedersen|Martin]] 00:38, 10 March 2010 (UTC)<br />
::: Fun story: Before Shadow switched to my tree, it was victim to this actually! PriorityQueue.iterator() (as used by Simonton's tree (which is what Shadow used to use)) returns the output in heap ordering (contrary to what ABC had assumed), the same type of ordering as what my currently released tree does if you tell it not to sort. Funny enough, Shadow still did quite well despite this bug. That behavior of PriorityQueue was mentioned in the talk page of my tree I believe. --[[User:Rednaxela|Rednaxela]] 01:23, 10 March 2010 (UTC)<br />
: Haven't played with this stuff in a while, but last I did, my tree outperformed my linear search by maybe the 10-15k mark? Certainly by 25k (end of a normal battle), and by leaps and bounds beyond that. And Red's is several times faster than mine. At 100k my tree is slower than linear? How many dimensions/what cluster size? Trees do worse vs linear as those go up... I was usually testing ~10 dimensions and 30-50 cluster size. --[[User:Voidious|Voidious]] 00:41, 10 March 2010 (UTC)<br />
:: I've been testing with 13 dimensions, at 5k, 50k, and 100k data points. Beyond that I blow out the memory. Your flat search is always run first and is always in the lead at the end. Maybe it is just a quirk of my work computer (Intel Dual CPU @ 2.66GHz, JRE 1.6.0_01). It consistently beats the other benchmark implementations. I don't know how old those examples are. It is rare that I can outperform it without a bug in my implementation. --[[User:Pedersen|Martin]] 19:25, 10 March 2010 (UTC)<br />
::: That... doesn't really make any sense. My tree in the example is about 25% to 50% slower than my currently posted one, however tests here show my tree being close to 30 times faster than Voidious' linear search. I doubt such a massive difference could be accounted for by a quirk of the computer. I'd be curious what your results would look like with a graph like I posted in the kd-tree talk page. Should I upload the updated version of the benchmark I have here (Has CSV export for that type of graph, updated version of my tree, Chase-San's new tree, and Duyn's tree)? I'm also curious whether you would have the same results for the non-random data set. --[[User:Rednaxela|Rednaxela]] 21:01, 10 March 2010 (UTC)<br />
:::: An update would be handy, for other reasons as well. As an example, I had to tweak the took to make use of the random number generator, as I wasn't aware of any sample file to use. There have been some other tweaks I did, but I doubt they were necessary, such as removing the dependence on execution parameters. I've always run it through Eclipse anyway. Perhaps that is part of the problem. If you prefer, you can email the benchmark to me directly, 'martinalanpedersen' by way of gmail. --[[User:Pedersen|Martin]] 22:03, 10 March 2010 (UTC)<br />
::::: Here's an update to [http://robowiki.net/w/images/a/ac/KNN.jar KNN.jar], with new/updated trees, csv output for graphing, and when started without arguments works in an interactive mode asking the user for the parameters (including support for optionally downloading the standard data file normally used with it). :) --[[User:Rednaxela|Rednaxela]] 05:31, 11 March 2010 (UTC)<br />
: Yeah, and actually, if the tree is optimized well, it's speed can be indistinguishable from a well optimized linear search, even with almost no points. Check out the charts on [[Talk:Kd-tree]] to see how performance of various searches varies over the course of the battle. Even extremely early, the best few trees perform no worse than linear search right from the start. Actually, Voidious's tree is the only one significantly slower than linear search at low numbers of points. --[[User:Rednaxela|Rednaxela]] 01:23, 10 March 2010 (UTC)<br />
:: You mean Simonton's right, because Voidious' does about the same as the rest, where as Simonton's is pretty slow according to the charts. --[[User:Chase-san|Chase]] 14:56, 10 March 2010 (UTC)<br />
::: Er, yes, that's what I meant. Was getting the lines at the start confused. --[[User:Rednaxela|Rednaxela]] 15:03, 10 March 2010 (UTC)<br />
::: Did you think you could dis my tree with my notice?! -- [[User:Simonton|Simonton]]</div>Simontonhttp://robowiki.net/w/index.php?title=Talk:Kd-tree&diff=10547Talk:Kd-tree2009-08-15T15:36:35Z<p>Simonton: also ...</p>
<hr />
<div>== Bucket PR k-d tree ==<br />
<br />
I think you all know about Bucket PR k-d tree (aka Simonton's tree), right? I'll get directly to my point.<br />
<br />
The Bucket PR k-d tree (I'll refer as just a tree from now on) is a binary tree split by the median of the bound, right? I wonder if I make it m-''ary'' tree, let say, Ternary or Quaternary tree instead of just binary? Will it better? &raquo; <span style="font-size:0.9em;color:darkgreen;">[[User:Nat|Nat]] | [[User_talk:Nat|Talk]]</span> &raquo; 09:12, 15 August 2009 (UTC)<br />
<br />
Note, it doesn't by definition have to be split by the median, though the median is usually considered the best place. As far as your second question... it may be better, or it may not. I'm pretty sure it will depend heavily on the implementation details and the data set in question. --[[User:Rednaxela|Rednaxela]] 14:51, 15 August 2009 (UTC)<br />
<br />
In a binary tree you do 1 comparison to narrow it down to 1/2 the tree (if it's well balanced). In a 3-ary you do (on average) 1.5 comparisons to narrow it to 1/3. 4-ary 2 comparisons for 1/4 of the tree. 1*1/2 = 1.5*1/3 = 2*1/4. They're all theoretically the same. --[[User:Simonton|Simonton]] 15:33, 15 August 2009 (UTC)<br />
<br />
* Also note that with a 4-ary tree it's best to do a binary search at each node, which is pretty much the same thing as going back to a binary tree, except you'd be doing two comparisons for the same dimension instead of stepping to the next. --[[User:Simonton|Simonton]] 15:36, 15 August 2009 (UTC)</div>Simontonhttp://robowiki.net/w/index.php?title=Talk:Kd-tree&diff=10546Talk:Kd-tree2009-08-15T15:33:02Z<p>Simonton: -ary-ness</p>
<hr />
<div>== Bucket PR k-d tree ==<br />
<br />
I think you all know about Bucket PR k-d tree (aka Simonton's tree), right? I'll get directly to my point.<br />
<br />
The Bucket PR k-d tree (I'll refer as just a tree from now on) is a binary tree split by the median of the bound, right? I wonder if I make it m-''ary'' tree, let say, Ternary or Quaternary tree instead of just binary? Will it better? &raquo; <span style="font-size:0.9em;color:darkgreen;">[[User:Nat|Nat]] | [[User_talk:Nat|Talk]]</span> &raquo; 09:12, 15 August 2009 (UTC)<br />
<br />
Note, it doesn't by definition have to be split by the median, though the median is usually considered the best place. As far as your second question... it may be better, or it may not. I'm pretty sure it will depend heavily on the implementation details and the data set in question. --[[User:Rednaxela|Rednaxela]] 14:51, 15 August 2009 (UTC)<br />
<br />
In a binary tree you do 1 comparison to narrow it down to 1/2 the tree (if it's well balanced). In a 3-ary you do (on average) 1.5 comparisons to narrow it to 1/3. 4-ary 2 comparisons for 1/4 of the tree. 1*1/2 = 1.5*1/3 = 2*1/4. They're all theoretically the same. --[[User:Simonton|Simonton]] 15:33, 15 August 2009 (UTC)</div>Simontonhttp://robowiki.net/w/index.php?title=Talk:RoboRumble/Reported_Problems&diff=10491Talk:RoboRumble/Reported Problems2009-08-14T21:35:07Z<p>Simonton: /* IllegalThreadStateException */ new section</p>
<hr />
<div>== Repeated Battles ==<br />
<br />
Not sure if this is the best place to put this, but here it is. My roborumble client would keep getting hung up running the same bot over & over, regardless of how many battles it already had or how many other bots were below the <tt>BATTLES_PER_BOT</tt> limit I set. I think I took care of the problem by deleting files between between runs of the rumble. This is my <tt>roborumble.bat</tt> file now:<br />
<pre><nowiki><br />
:TOP<br />
java -Xmx256M -Dsun.io.useCanonCaches=false -cp libs/robocode.jar;libs/codesize.jar;libs/roborumble.jar roborumble.RoboRumbleAtHome ./roborumble/roborumble.txt<br />
del roborumble\temp\battles*<br />
del roborumble\temp\priority*<br />
GOTO TOP<br />
</nowiki></pre><br />
I think the priority battles file was the culprit, but I'm leaving the other line in for good measure. --[[User:Simonton|Simonton]] 16:35, 22 September 2008 (UTC)<br />
<br />
Woah, I certainly see the results of these stuck pairings... such as Drifter vs Okami over 200 times, and similar for Fermat vs Okami. It sure feels unusual seeing over 100 battles in any pairing in RR, but at least we know those pairings are accurate haha. --[[User:Rednaxela|Rednaxela]] 19:22, 22 September 2008 (UTC)<br />
<br />
As for accuracy, below is the impact of battles on the score. This is 0.7*old + 0.3*new. For first battle you can also read 'all battles till now'. This means that 2 new battles will reduce the influence of the previous ones to 50%.<br />
<pre><br />
1 2 3 4 5<br />
first 100<br />
second 70 30<br />
third 49 21 30<br />
fourth 35 14 21 30<br />
fifth 25 10 14 21 30<br />
</pre> --[[User:GrubbmGait|GrubbmGait]] 23:52, 22 September 2008 (UTC)<br />
<br />
Sorry, Grub, I'm not really following you. What does this table represent? What is its relevance to rumble scores? --[[User:Simonton|Simonton]] 23:57, 22 September 2008 (UTC)<br />
<br />
It's the influence of each battle on the % score. From the table, after a bot has 5 battles in a pairing, the most recent battle has a weightage of 30%, 2nd most recent 21%, third is 14%, fourth is 10% and the first battle ever run for that pairing is 25% (the first battle always has a disproportionate weighting) towards the % score for that pairing -- [[User:Nfwu|<font color="#3B9C9C">Ketsu</font>]][[User Talk:Nfwu|<font color="#F87217">Nfwu</font>]] 08:48, 23 September 2008 (UTC)<br />
<br />
My fault, I should have explained it better. Its relevance to the stability of the rumble scores is this: The last 4 battles determine 75% of the performance against an opponent. So when 100 battles are fought against a particular bot, battle 1 till 96 determine only 25% of the performance. The good part is that this info can be used to 'repair' results from bad clients. --[[User:GrubbmGait|GrubbmGait]] 19:23, 23 September 2008 (UTC)<br />
<br />
Now I understand! So - the rumble uses .7*averagePercentScore + .3*percentScore (similar to a [[Rolling Average]]) to calculate the %score of any given pairing, and you are showing us that running 100 battles doesn't really make that number any more reliable than running maybe 10 battles (at which point the first only has a weight of 4%). [[User:ABC|ABC]] talked about making his server use absolute averages instead of rolling averages; I wonder if he implemented that. --[[User:Simonton|Simonton]] 20:15, 23 September 2008 (UTC)<br />
<br />
== Security exception 1.6.0 ==<br />
<br />
One bot suffers from a security exception in v1.6.0, namely axebots.SilverSurfer.<br />
It seems the only bot that has this problem, so the impact is not that big. Maybe someone (or Axe himself) can update the bot so it can be processed by the latest robocode versions. --[[User:GrubbmGait|GrubbmGait]] 23:52, 22 September 2008 (UTC)<br />
<br />
== IllegalThreadStateException ==<br />
<br />
In response to a bug report I filed, FNL has made a patched 1.6.4.1 robocode.jar that doesn't suffer from the annoying IllegalThreadStateException while running the rumble. It is available at http://robocode.sf.net/files/robocode.jar, though it doesn't sound like it will be there forever. --[[User:Simonton|Simonton]] 21:35, 14 August 2009 (UTC)</div>Simontonhttp://robowiki.net/w/index.php?title=Talk:RoboRumble&diff=10022Talk:RoboRumble2009-08-07T17:05:59Z<p>Simonton: I do</p>
<hr />
<div>== RoboRumble history ==<br />
April 27 2005 - The RoboRumble@Home server is now moved to Pulsar's machine. See /TemporaryServerUp for the RR@H settings files to use and some more details. The only difference you should note is that the flag-less bots no longer have the Jolly Roger flag. This is temporary and will be fixed soon. Huge thanks to Pulsar for carrying the burden (reponsibility-wise) a while with this. I'll sleep tighter now when I don't need to worry if my WinXP Home PC (yes, it was hosted in such an environment before!) is awake and responsive. -- PEZ<br />
<br />
October 28 2005 - The RoboRumble@Home server will be down for several hours for upgrades tomorrow (Saturday Octber 29). As a side effect this will solve the issues some people have with port 8080. --Pulsar<br />
<br />
October 29 2005 - The RoboRumble@Home server is going down shortly and will be up and running again within 12hours hopefully. -- Pulsar<br />
<br />
October 29 2005 - The RoboRumble@Home server is up and running. Updates are needed for RoboRumble@Home clients. -- Pulsar<br />
<br />
February 18 2006 - The RoboRumble@Home server connection might experience some downtime the following hours as I will reorganize the firewall setup. --Pulsar<br />
<br />
March 7 2006 - The firewall switch over has now finally been done, and everything seems to be working. Some people might experience a short delay until DNS records have been updated around the world (though they were and are set to a very short "time to live" to minimize this). RoboRumble@Home clients need to be restarted as Java by default caches DNS lookups. --Pulsar <br />
<br />
== Subpages ==<br />
Should we replace ALL of the subpages? or just the 'important' ones? -- [[User:Starrynte|Starrynte]] 22:16, 17 November 2007 (UTC)<br />
<br />
== Name ==<br />
<br />
Since the new wiki supports symbols in page names, should we put this page at [[RoboRumble@Home]] instead of RoboRumble? We already have a redirect from that page to this one... --[[User:AaronR|AaronR]] 23:34, 17 November 2007 (UTC)<br />
<br />
I second this change. &raquo; <span style="font-size:0.9em;color:darkgreen;">[[User:Nat|Nat]] | [[User_talk:Nat|Talk]]</span> &raquo; 02:30, 28 April 2009 (UTC)<br />
<br />
== RR seems to be down ==<br />
<br />
Roborumble is returning 503 Unavailable for all pages today. Not sure why. -- [[User:Synapse|<font style="font-size:0.8em;font-variant:small-caps;">Synapse</font>]] 03:07, 19 September 2008 (UTC)<br />
:Are you sure? Both [http://rumble.fervir.com/rumble/Rankings?version=1&game=roborumble rumble.fervir.com] and [http://abchome.aclsi.pt:8080/ ABC's] work for me. -- [[User:Nfwu|<font color="#3B9C9C">Ketsu</font>]][[User Talk:Nfwu|<font color="#F87217">Nfwu</font>]] 03:33, 19 September 2008 (UTC)<br />
::I fail. I meant Robocode Repository. -- [[User:Synapse|<font style="font-size:0.8em;font-variant:small-caps;">Synapse</font>]] 05:44, 19 September 2008 (UTC)<br />
::Not a big surprise there. =P -- [[User:Nfwu|<font color="#3B9C9C">Ketsu</font>]][[User Talk:Nfwu|<font color="#F87217">Nfwu</font>]] 13:21, 19 September 2008 (UTC)<br />
<br />
Hi! What the heck happened to RR@H again? The main roborumble has only ~60 bots again... Otherwise, I uploaded Pugio 1.2 1 week ago and has only 120 battles in nanoRumble. Situation is the same in Darcanuck's page, too. Nobody is contributing?--[[User:Robar|HUNRobar]] 12:30, 11 October 2008 (UTC)<br />
<br />
Both ABC's server and DarkCanuck's server have no full pairings yet. Once the megabots have full pairings, the minirumble will get filled completely and as last the micro- and nano-rumble. Be patient, but it probably requires a few weeks before all nanobots have 1000 battles. Remember, 640 * 640 bots means a lot of battles! Pulsar's server has another issue. I don't know what happened, but I still run (repair)battles there. --[[User:GrubbmGait|GrubbmGait]] 13:14, 11 October 2008 (UTC)<br />
<br />
I realised that in Darcanuck's server the older versions of bots are still in game. I think the competitors there should be cleaned up. For example, I don't want to generate battles for Pugio 1.0 when I wait for the results of 1.2. --[[User:Robar|HUNRobar]] 14:57, 11 October 2008 (UTC)<br />
<br />
That's a temporary thing -- I'm uploading a huge amount of data from [[User:ABC|ABC]]'s server which includes old participants. There's a big performance hit to activating/retiring participants repeatedly, so for now everyone's in the rankings until I get caught up. But don't worry, no rumble clients will actually run these bots. They'll use only the version from the participants list. In a few days you should see the old bots disappear from the rankings. --[[User:Darkcanuck|Darkcanuck]] 15:03, 11 October 2008 (UTC)<br />
<br />
Whoops edit conflict, accidentally overwrote Darkcanuck's reply with this: "What versions get battles doesn't depend on the server, it depends on the participants list that clients are configured to (which should be the old wiki's one, the one here has not been synced for a long time). The server would have nothing to do with that so you shouldn't be generating battles for Pugio 1.0 unless your client is misconfigured I believe." Anyways Darkcanuck's reply clearly explains why there are currently old versions listed :) --[[User:Rednaxela|Rednaxela]] 15:10, 11 October 2008 (UTC)<br />
<br />
Ok, thanks but I'm very excited about the results of Pugio 1.2. :)--[[User:Robar|HUNRobar]] 17:40, 11 October 2008 (UTC)<br />
<br />
Why can't I access ABC's server? My connection get timeout before it finished loading! -[[User:Nat|Nat]] 12:42, 6 January 2009 (UTC)<br />
<br />
== Lynch the Multi-Threaders! ==<br />
<br />
A thought just occurred to me. I have never liked the fact that robots could be threaded. Why?<br />
# On a single-core (non-hyperthreaded) machine it cannot help the bot without hurting the opponent. Either a) all computation is done on one CPU during your turn, in which case you could have done the same computation with less overhead without the threads, or b) you do computation past your turn, eating up CPU cycles from your opponent.<br />
# On a multi-core (or hyperthreaded) machine, it violates the idea that all bots are equal except for their AI. You suddenly get 2 CPU's in your robot, essentially.<br />
This is a reality we have had to live with, because that's the way robocode is designed. HOWEVER - it just occurred to me that we ''could'' enforce a rule saying that no multi-threaded bot is allowed in ''the rumble''! Which I hereby propose. Besides being unfair to the bot's opponent, acting like a virus stealing CPU, it steals CPU from bots in OTHER battles now-a-days when more than one rumble client executes at a time on multi-core machines! Any bot caught using multiple threads would be immediately removed from the rumble. Does anybody agree? --[[User:Simonton|Simonton]] 02:47, 23 September 2008 (UTC)<br />
<br />
Agreed. It isn't fair on the opposition, and makes it impossible to design a bot within the CPU-constant constraints. --[[User:Skilgannon|Skilgannon]] 10:34, 23 September 2008 (UTC)<br />
<br />
I either didn't see or forgot about this section. There are already bots that use multiple threads in the rumble: [[Toad]] definitely does, possibly [[X2]] (which shares some Toad code), and probably others. Not sure how I feel about removing them at this point, just contributing some facts here... --[[User:Voidious|Voidious]] 02:20, 7 August 2009 (UTC)<br />
<br />
Well, there are java APIs that allow things like only measuring the time used in a particular thread. Robocode could start to use these in order to make this fair, AND as a '''major''' bonus it would make using Robocode on a computer with a heavily loaded CPU not cause skipped turns. The issue is... those APIs don't give the same kind of resolution, thus meaning that the only way we do it would be if we calculated something more like "How much CPU time did threads of this bot use in the last 20 ticks?", instead of "How much time did this robot take between the start and end of this turn?" which would make skipped turns behave a bit different. Personally I think that may not be such a bad thing, but I'm not really entirely sure... --[[User:Rednaxela|Rednaxela]] 02:51, 7 August 2009 (UTC)<br />
<br />
: It looks like [https://sourceforge.net/tracker/?func=detail&aid=2456831&group_id=37202&atid=419489 this] &raquo; <span style="font-size:0.9em;color:darkgreen;">[[User:Nat|Nat]] | [[User_talk:Nat|Talk]]</span> &raquo; 12:53, 7 August 2009 (UTC)<br />
<br />
:: Hm? "ERROR This artifact is not accessible." is what that page gives --[[User:Rednaxela|Rednaxela]] 13:11, 7 August 2009 (UTC)<br />
<br />
::: Sorry, I never noticed that this is 'private' tracker... Fnl thought that he needs more precise time and mem.usage detection. I have a comment on some time measuring much like to your "How much CPU time did threads of this bot use in the last 20 ticks?". However, we didn't mention a thread at all. But I believe that Robocode allow Robots to create up to 5 threads, I'll email Fnl this. &raquo; <span style="font-size:0.9em;color:darkgreen;">[[User:Nat|Nat]] | [[User_talk:Nat|Talk]]</span> &raquo; 13:53, 7 August 2009 (UTC)<br />
<br />
== What Now? ==<br />
<br />
How can I submit the new versions of DrussGT and Cunobelin? Has anybody heard any news on the old wiki? Will it be recovered? Is it gone forever? --[[User:Skilgannon|Skilgannon]] 15:47, 8 December 2008 (UTC)<br />
<br />
Well on November 30th I emailed PEZ and got a reply that it's an ugly error and that he'd look into it. I haven't heard anything since but I guess I might email PEZ again. I certainly hope it won't be gone forever as I'd at least like to have a read-only version due to how much great stuff there is there that's unmigrated. --[[User:Rednaxela|Rednaxela]] 16:12, 8 December 2008 (UTC)<br />
<br />
I really hope the old wiki content still lives on. In the meantime we could agree to use this wiki's list for my server. I don't have time this week to make the proposed participant list changes, but I could lock out add/removes for all but a few select clients to make sure we all use the same list? --[[User:Darkcanuck|Darkcanuck]] 18:28, 8 December 2008 (UTC)<br />
<br />
Well, the old wiki is back! I do wonder though, should we switch to using this wiki's participants list anyway? or should that wait till some other day in the future? --[[User:Rednaxela|Rednaxela]] 18:17, 9 December 2008 (UTC)<br />
<br />
: I'd like to keep using the old wiki at least until I can code up something to validate participants on the server side. Then it would be easier to switch and not have to worry about some clients using the wrong list. --[[User:Darkcanuck|Darkcanuck]] 05:39, 10 December 2008 (UTC)<br />
<br />
Random question: How much do you think the local client would speed up if I compiled it natively? Right now, we haev a bit of a bottleneck figuring out battles andif we could speed it up by a factor or 3 or so, why not? --[[User:Miked0801|Miked0801]] 21:52, 25 May 2009 (UTC)<br />
<br />
== Nanos get little love when things get busy ==<br />
I've been waiting for nearly 4 days for my latest bot to get to 2k battles against nanos, and I'm probably gonna have to wait 3 more for it to happen. Why? Nanos, after they get to their 1 battle per bot limit, are the last bots to be updated under the current system. I understand why the system was done this way, but is there anyway we can add a time component to the battle chooser to make sure that when things heat up in the rumble, nanos get some love as well? --[[User:Miked0801|Miked0801]] 20:47, 19 June 2009 (UTC)<br />
<br />
I hear ya. Even in Mega-land, it can take a while to get to 2k battles, and I don't really trust a rating until it does (even with all pairings). There are some RR client options you could try, like excluding bots or running NanoRumble only, but the latter will just do random battles, I think. A couple of nice client side options, imo, would be mini/micro/nano while still honoring pairing priority, and ignoring pairings while running bots with under NUMBATTLES (in all applicable rumbles). I'm definitely in favor of RR contributors having control over what battles they want to run... --[[User:Voidious|Voidious]] 22:48, 19 June 2009 (UTC)<br />
<br />
Nanos get ''way'' more than their fair share of processing time. By a time a nano reaches 2000 battles in its own class, it has typically reached 5000+ battles in the main rumble. Few, if any, megabots have yet to reach that level. Not only is it unfair to folks releasing larger bots, it also takes away cpu time from other nanos. So should we abolish nanos? Of course not!<br />
<br />
I'd vote for changing the client's battle selection such that when a new bot reaches full pairings, the remainder of its 2000 battles are fought against opponents in its own size class. Those battles will still count for the higher classes, so a nano would really only need 2000 battles overall. This would mean faster results for nanos and more cpu time for everyone else, regardless of size. --[[User:Darkcanuck|Darkcanuck]] 03:19, 20 June 2009 (UTC)<br />
<br />
I second Darkcanuck's suggestion, as it seems most fair to me. :) --[[User:Rednaxela|Rednaxela]] 05:12, 20 June 2009 (UTC)<br />
<br />
And yet, some nanos love to beat up on their larger sibling... But yes, when things slow down, nanos do get a ton of extra battles, but to be fair, most nanos run much, much faster than megas so the hit isn't that bad. My main concern was waiting at the back of a line of never ending micro/mega selections. Impatients and such. If we're going to change things to minimize waits, then first completing pairings, then 2k in class, then low priority updates across other classes would be awesome. Unlike melee, just 2 or 3 battles with a mega are usually sufficient to get a strong idea of where things stand. --[[User:Miked0801|Miked0801]] 09:10, 20 June 2009 (UTC)<br />
<br />
You can also set RUNONLY=NANO, but alas then no priority battles are fought, just random ones. And I set the battlecount to 1000, so nanos will get their battles earlier. --[[User:GrubbmGait|GrubbmGait]] 10:51, 20 June 2009 (UTC)<br />
* setting RUNONLY=NANO is not a good idea. The results only count for nano, so is not counted at micro/mini/mega. Setting the battlecount lower does pay off however, except when the bigger rumbles are flooded with new versions. --[[User:GrubbmGait|GrubbmGait]] 11:00, 20 June 2009 (UTC)<br />
<br />
It would be awesome if roborumble could execute smart battles with runonly parameters. For example, run prioritary battles but only among nanos. I don't think it would be such a difficult developement. --[[User:Robar|HUNRobar]] 14:33, 20 June 2009 (UTC)<br />
<br />
: I think the RUNONLY setting needs to be fixed -- as [[GrubbmGait]] pointed out, the battles don't get uploaded to the bigger size classes, which they should. I might put together a patch for this, but first I have some wave surfing to iron out... --[[User:Darkcanuck|Darkcanuck]] 17:41, 20 June 2009 (UTC)<br />
<br />
About battlecount, one habit I have, is constantly making my battlecount set to just a little above the lowest value in the rumble. That seems to have nice results sometimes. --[[User:Rednaxela|Rednaxela]] 16:03, 20 June 2009 (UTC)<br />
<br />
All right, I think I've figured out how to implement the change I suggested, plus fix the RUNONLY problem. If enough people are ok with this, I'll put together a patched 1.6.1.4 client with the changes and send the patches to [[Fnl]] for future releases too. --[[User:Darkcanuck|Darkcanuck]] 18:21, 21 June 2009 (UTC)<br />
<br />
: Quick question: Would this only affect the 1v1 pairing order? I definitely support it there, but making your suggested change in Melee pairings would have a major impact on some bots' scores... And thanks as always for your RoboRumble efforts! --[[User:Voidious|Voidious]] 19:33, 21 June 2009 (UTC)<br />
:: Only at first. The game already does all class battles for roughly 50% of the numbers in nano now. That's why [[DustBunny]] has been slowly rising in APS - he does worse in nano only. --[[User:Miked0801|Miked0801]] 20:42, 21 June 2009 (UTC)<br />
::: Well, right now a NanoBot gets 2,000 battles against the whole field, then a bunch against MiniBots and below, then MicroBots and below, then NanoBots. With this change, it would get some amount of battles against the whole field, then all NanoBot-only battles. Depending on the bot, I think it could have an impact. Then again, that's a quirky aspect of MeleeRumble that's tough to really regulate, anyway, so maybe it's not worth worrying about. --[[User:Voidious|Voidious]] 21:51, 21 June 2009 (UTC)<br />
:: Ah, good point, I hadn't considered melee. It does use a different routine for preparing battles though, so it's possible to patch 1v1 without affecting melee. Looking at the melee routine, it does create an interesting mix of battles -- I didn't realize that there were all-nano matchups. That must skew the scores depending on the ratio of battles a nano gets with mixed sizes versus all-nano? --[[User:Darkcanuck|Darkcanuck]] 02:15, 22 June 2009 (UTC)<br />
: I don't think it is a bug, i think it was made on purpose the way it is. Alas I don't remember the reason . . . --[[User:GrubbmGait|GrubbmGait]] 21:03, 21 June 2009 (UTC)<br />
<br />
== Mobile Devices ==<br />
<br />
Who here things I'm crazy to try running roborumble on my Ipod Touch? :) --[[User:Rednaxela|Rednaxela]] 02:01, 7 August 2009 (UTC)<br />
<br />
* Definitely crazy. --[[User:Simonton|Simonton]]<br />
<br />
I think you're crazy, but only because the iPhone OS doesn't have Java. =) I actually just looked into this the other day, lol. Was there some tech you were looking at to make it work? --[[User:Voidious|Voidious]] 02:03, 7 August 2009 (UTC)<br />
<br />
Actually, when you don't limit yourself to the app store, there is a port of [[wikipedia:JamVM|JamVM]] w/ [[wikipedia:GNU Classpath|GNU Classpath]]. There's no JIT so it won't be fast... but it'll run.. or... almost:<br />
<pre>Iteration number 0<br />
Downloading rating files ...<br />
Downloading participants list ...<br />
Downloading missing bots ...<br />
Removing old participants from server ...<br />
Preparing battles list ... Using smart battles is true<br />
Prioritary battles file not found ... <br />
java.awt.AWTError: Cannot load AWT toolkit: gnu.java.awt.peer.gtk.GtkToolkit<br />
at java.awt.Toolkit.getDefaultToolkit(Toolkit.java:607)<br />
at robocode.security.RobocodeSecurityManager.<init>(Unknown Source)<br />
at robocode.manager.RobocodeManager.initSecurity(Unknown Source)<br />
at robocode.control.RobocodeEngine.init(Unknown Source)<br />
at robocode.control.RobocodeEngine.<init>(Unknown Source)<br />
at roborumble.battlesengine.BattlesRunner.initialize(Unknown Source)<br />
at roborumble.battlesengine.BattlesRunner.<init>(Unknown Source)<br />
at roborumble.RoboRumbleAtHome.main(Unknown Source)<br />
Caused by: java.lang.UnsatisfiedLinkError: Native library `gtkpeer' not found (as file `libgtkpeer') in gnu.classpath.boot.library.path and java.library.path<br />
at java.lang.Runtime.loadLibrary(Runtime.java:763)<br />
at java.lang.System.loadLibrary(System.java:662)<br />
at gnu.java.awt.peer.gtk.GtkToolkit.<clinit>(GtkToolkit.java:173)<br />
at java.lang.VMClass.forName(Native Method)<br />
at java.lang.Class.forName(Class.java:233)<br />
at java.awt.Toolkit.getDefaultToolkit(Toolkit.java:583)<br />
...7 more<br />
</pre> It seems that both:<br />
# RobocodeSecurityManager is foolish and tries to query the default graphics toolkit even if run from the command line<br />
# The install of GNU Classpath is foolish and thinks it has GTK avaliable when it's running in command line only<br />
Were it not for one or the other of those issues, it'd probably run just fine... Now can i fix this I wonder... --[[User:Rednaxela|Rednaxela]] 02:13, 7 August 2009 (UTC)<br />
<br />
Wow, that would be really cool. But I'm a wuss and I'm afraid to jailbreak and void my iPhone's AppleCare; I was thinking more from the perspective of writing an iPhone app myself that could do it. Good luck, though, I'm curious to hear your results! --[[User:Voidious|Voidious]] 02:17, 7 August 2009 (UTC)<br />
<br />
Aha! I got around that stupid issue! I just had to pass the VM <code>-Djava.awt.headless=true</code>... When you see rumble uploads with a user of "RednaxelaIPod", that'll be it :) --[[User:Rednaxela|Rednaxela]] 02:32, 7 August 2009 (UTC)<br />
: Ouchie, building the robot database this first time sure isn't fast... --[[User:Rednaxela|Rednaxela]] 02:39, 7 August 2009 (UTC)<br />
<br />
Sadly, while it mostly ran, it didn't quite work:<br />
<pre>java.lang.ArrayIndexOutOfBoundsException: 1<br />
at java.util.concurrent.CopyOnWriteArrayList.get(CopyOnWriteArrayList.java:27<br />
5)<br />
at java.util.AbstractList$1.next(AbstractList.java:354)<br />
at robocode.battle.Battle.updateBullets(Unknown Source)<br />
at robocode.battle.Battle.runTurn(Unknown Source)<br />
at robocode.battle.Battle.runRound(Unknown Source)<br />
at robocode.battle.Battle.run(Unknown Source)<br />
at java.lang.Thread.run(Thread.java:743)<br />
<br />
...<br />
<br />
java.lang.NullPointerException<br />
at robocode.battle.Battle.updateBullets(Unknown Source)<br />
at robocode.battle.Battle.runTurn(Unknown Source)<br />
at robocode.battle.Battle.runRound(Unknown Source)<br />
at robocode.battle.Battle.run(Unknown Source)<br />
at java.lang.Thread.run(Thread.java:743)<br />
<br />
...<br />
<br />
Exception in thread "sul.Pinkbot 1.1" java.lang.NullPointerException<br />
at robocode.peer.RobotPeer.setEnergy(Unknown Source)<br />
at robocode.peer.RobotPeer.setEnergy(Unknown Source)<br />
at robocode.peer.RobotPeer.run(Unknown Source)<br />
at java.lang.Thread.run(Thread.java:743)<br />
Exception in thread "serenity.moonlightBat 1.17" java.lang.NullPointerException<br />
at robocode.peer.RobotPeer.setEnergy(Unknown Source)<br />
at robocode.peer.RobotPeer.setEnergy(Unknown Source)<br />
at robocode.peer.RobotPeer.run(Unknown Source)<br />
at java.lang.Thread.run(Thread.java:743)<br />
</pre> Though if a workaround can be found for those issues (most likely bugs in the version of GNU Classpath in question. May not apply to newer versions, or a patched robocode might be able to work around it), it may work. Not sure that'll be possible though. Oh well... --[[User:Rednaxela|Rednaxela]] 03:54, 7 August 2009 (UTC)</div>Simontonhttp://robowiki.net/w/index.php?title=Talk:RoboRumble/Contributing_to_RoboRumble&diff=9944Talk:RoboRumble/Contributing to RoboRumble2009-08-06T05:36:09Z<p>Simonton: TY</p>
<hr />
<div>{{CreditForOldWikiArticle|oldpage=RoboRumble/StartingWithRoboRumble}}<br />
<br />
<br />
== Old Wiki ==<br />
----<br />
I presume all older issues are not valid anymore, otherwise you can find them on [[RoboRumble/StartingWithRoboRumbleOld|/StartingWithRoboRumbleOld]] or put them here below again.<br />
----<br />
<br />
Sweet. Much easier now thanks. How can I control how many battles are run at once? Or should I just setup a for loop in a batch file for that? --[[User:Miked0801|Miked0801]]<br />
* Halfway the file "roborumble.txt" you'll find "NUMBATTLES=xx", there you fill in the number of battles fought before uploading results and quitting robocode. In the batch-file I have made an infinitive loop so my client can run unattended all night. -- [[User:GrubbmGait|GrubbmGait]]<br />
* (Edit conflict) There are .txt files for each type of rumble - roborumble.txt, meleerumble.txt, and teamrumble.txt - in the 'roborumble' directory. The "NUMBATTLES" controls how many are run before uploading, "BATTLESPERBOT" is the minimum number of battles a bot needs before it stops getting priority, and "USER" is just to identify yourself in the logs and such. I have mine with "ITERATE=NOT" and I do use a shell script that loops to keep it running. -- [[User:Voidious|Voidious]]<br />
<br />
this bash script will be good for unix "roborumbler". Run forever battles, it catch standard and error stream and put it to a file in the directory ./log/tempNUMBER_OF_BATTLE.txt (the script have to be in the roborumble directory). For Linux: save it to a file in the roborumble directory, right click and set the file executable, create a directory called "log", then run the script from shell:<br />
<pre><br />
#!/bin/bash<br />
<br />
echo # new line<br />
count=0<br />
while [ "$var1" != "fine" ] # forever<br />
do<br />
let "count=count+1"<br />
echo "battle n: " $count<br />
sh roborumble.sh &> ./log/temp$count.txt<br />
echo<br />
done <br />
<br />
exit 0<br />
</pre><br />
<br />
p.s.: it's very useful for catch error, someone can traslate the script in windows's dos?<br />
[[Asdasd]]<br />
<br />
Wow - is 256MB still the default for the rumble? Why not at least 512, if robocode's default itself is 512? -- [[User:Simonton|Simonton]]<br />
<br />
I'm not sure - maybe because the GUI takes a lot of memory? -- [[User:Skilgannon|Skilgannon]]<br />
<br />
Ehh, the GUI shouldn't, not compared to many adaptive bots (particularly log targeting). Personally I always set 512MB in the rumble, and the only time I've had an out of memory problem with 512MB was when some particularly memory-heavy team (can't remember which one) was going. Personally I'd support defaulting to 512MB, at least for teams/melee, if [[Fnl]] is listening :-) -- [[User:Rednaxela|Rednaxela]]<br />
<br />
Can someone please zip a new update, i've unzipped the archives above and still get a ton of "Ignoring xxx..." message because they weren't download...thank you! (or even better someone start a new repository and put the zipped bots there...) --[[User:Starrynte|Starrynte]]<br />
<br />
== RoboRumbler ==<br />
I didn't know where to post this, but I guess the talk section is always good enough. I created an Java Application called [[Zyx/RoboRumbler|RoboRumbler]] to help controlling the resources [[RoboRumble]] uses. It's basically an application to let me work and run [[RoboRumble]] at the same time, I further explain it in it's page if anyone is interested. --[[User:Zyx|zyx]]<br />
<br />
Hmm, I'm curious about this. How does it account for the fact that RoboRumble is highly sensitive to the amount of CPU allocated to it? (i.e. other apps taking lots of CPU can make bots skip turns and potentially give very wrong results). If this limits the CPU allocated to RoboRumble, does it correctly make sure the constant for the time robots get per turn is increased suitably? ''(P.S. on the new wiki you can use <nowiki>--~~~~</nowiki> or the signature button to sign your messages with time/date easily. Personally I'd recommend it because it makes it possible to look back at conversations and know when they happened. :))'' --[[User:Rednaxela|Rednaxela]] 21:45, 26 November 2008 (UTC)<br />
<br />
Right now the application is not intended to work with CPU intensive applications, it basically runs them in the same way as they would normally do, but allows you to run then from time to time, and then forever by itself again and stuff like that. So you could be working in the machine, but not hogging the CPU yourself, you can set it to have a few battles and then sleep for 20 minutes. You could be writing some code(I did it to work on my thesis in the mean time), but not execute it until the [[RoboRumbler]] goes to sleep. Then you would have those 20 or any other amount of time to use the whole CPU when no rumble battles are running, so you could compile and test your application, and then, when the rumble is about to start again, you lower your activity. And when you are heading to your bed, set the sleep time to 0 and let it rumble without stop.<br />
<br />
Hopefully it will grow to a system that doesn't need for the user to be careful, but right now is the best I have. I was doing the same thing but manually, I ran the rumble battles while I was writing stuff, waited for it to finish so I could ran my application and then set the rumble again. But in no moment my idea was to really lower the CPU usage for [[RoboRumble]] during battles, but to have some deterministic break times when I could use the computer. (P.S. Thanks about the <nowiki>--~~~~</nowiki>, I saw it before in your post, but thought you wrote it yourself, and seemed like to much work) --[[User:Zyx|Zyx]] 23:44, 26 November 2008 (UTC)<br />
<br />
==stable rumble client==<br />
<br />
Are the stable rumble client 1.5.4 and, 1.6.0 or 1.6.0.1? someone have tested the new robocode version? --[[User:Lestofante|lestofante]] 15:44, 10 December 2008 (UTC)<br />
<br />
I know 1.6.1.4 is stable (some earlier 1.6.1.x versions were bad), with a minor aesthetic bug that it sometimes spams the "Round 31 initializing...." to stdout but that doesn't affect the battles or the uploading so it's good for RR. Additionally, as of 1.6.1.4 the ITERATE option works properly again, so external loop scripts shouldn't be needed. I plan to test 1.6.2 Beta 2 some time but haven't done that yet. --[[User:Rednaxela|Rednaxela]] 20:10, 10 December 2008 (UTC)<br />
<br />
==RUNONLY==<br />
I have RUNONLY=NANO in meleerumble, yet it still runs battles with tons of non-nano bots. 1) will this affect rankings improperly 2) how do you get it to run only nanos...as runonly is supposed to do (using version 1.6.0.1) --[[User:Starrynte|Starrynte]] 00:59, 3 April 2009 (UTC)<br />
<br />
* I've never tried these modes so don't know how well they work. I'm pretty sure RUNUNLY=SERVER is the only way to guarantee full pairings, since that's the mode where the client uses priority battles sent by the server. Also, I think the client considers nano pairings in melee to be any matchups between two nano bots, even if there are other sizes in the same battle -- which means you don't need a battle with 10 nanos in order to get meleenano results. That's why ntc.Opposite's nano results are up to 600+ already. --[[User:Darkcanuck|Darkcanuck]] 01:18, 3 April 2009 (UTC)<br />
<br />
==Questions from Positive==<br />
<br />
Hey, I'd like to contribute, but need some help. I've followed the instructions on this page (I used version 1.6.1.4). But what's the correct configuration for meleerumble.txt for Darkcanuck's server? Also: Can I safely quit the roborumble client when I need my CPU back? Is there something else usefull to know/do before running? :) --[[User:Positive|Positive]] 16:40, 17 July 2009 (UTC)<br />
<br />
I think you can just replace the domain with darkcanuck.net, but my full URLs are:<br />
* PARTICIPANTSURL=http://robowiki.net/w/index.php?title=RoboRumble/Participants/Melee<br />
* UPDATEBOTSURL=http://darkcanuck.net/rumble/RemoveOldParticipant<br />
* RESULTSURL=http://darkcanuck.net/rumble/UploadedResults<br />
Yes, run the client as much or as little as you like, of course. =) Hmm, one issue comes to mind: the bots using Robocode Repository ids will fail to download, I think. I fixed the URLs on the 1v1 list and some on the Melee list, but still lots of ids there. Running the 1v1 client to download bots first might get a lot of the missing ones. I'll try and get that fixed today.<br />
<br />
--[[User:Voidious|Voidious]] 16:58, 17 July 2009 (UTC)<br />
<br />
Hrm, well it seems like it should work, with Portia it did, or did you have to add it manually? I could make a script and change all lines with "ROBOTNAME,NUMBER" to "ROBOTNAME,http://www.robocoderepository.com/BotFiles/NUMBER/ROBOTNAME.JAR" --[[User:Positive|Positive]] 17:11, 17 July 2009 (UTC)<br />
<br />
Hmm, now I'm not sure, really. I don't think I grabbed Portia manually. Feel free to update the list yourself, if you want, I did exactly as you said using regular expression find/replace in my text editor (TextWrangler). I'll get to it later today if you haven't yet. --[[User:Voidious|Voidious]] 17:24, 17 July 2009 (UTC)<br />
<br />
Hmm, I tried it, and it's not that easy. For example, the pure converted form of TheArtOfWar changes from "tzu.TheArtOfWar 1.2,689" to "tzu.TheArtOfWar 1.2,http://www.robocoderepository.com/BotFiles/689/tzu.TheArtOfWar 1.2.jar". But I don't know what the actual download link is. (It's not "tzu.TheArtOfWar_1.2.jar" either). Any downside to just activating roborumble and seeing what happens? --[[User:Positive|Positive]] 17:54, 17 July 2009 (UTC)<br />
<br />
It seems TheArtOfWar was an exception, I'll replace the original with the new in a few moments. :) --[[User:Positive|Positive]] 18:06, 17 July 2009 (UTC)<br />
<br />
Cool. I'm not sure what's up with that, but I was thinking, "I swear I used that same format for the 1v1 list and it worked." =) Also, Darkcanuck was kind enough to post all his rumble bots here: [http://darkcanuck.net/rumble/robots/], so you can grab any missing ones. (I didn't mention before because it's not a great way to get all of them.)<br />
<br />
One of us should post an updated .zip of rumble bots as a base point for new RoboRumblers... there are a few old ones posted around the wiki, but I can never remember where. The hurdle with that is cleaning out all the multiple versions of certain bots before zipping.<br />
<br />
--[[User:Voidious|Voidious]] 18:14, 17 July 2009 (UTC)<br />
<br />
I found the .zip here: [[RoboRumble/Starting With RoboRumble]]. That zip is pretty complete, the message I got only showed a few missing:<br />
<br />
<pre><br />
Trying to download tripphippy.Alice 1.0<br />
Downloaded tripphippy.Alice 1.0 into ./robots/tripphippy.Alice_1.0.jar<br />
Trying to download voidious.Diamond 1.183b<br />
Downloaded voidious.Diamond 1.183b into ./robots/voidious.Diamond_1.183b.jar<br />
Trying to download voidious.micro.BlitzBat 1.04<br />
Downloaded voidious.micro.BlitzBat 1.04 into ./robots/voidious.micro.BlitzBat_1.<br />
04.jar<br />
Trying to download voidious.mini.BrokenSword 1.04<br />
Downloaded voidious.mini.BrokenSword 1.04 into ./robots/voidious.mini.BrokenSwor<br />
d_1.04.jar<br />
Trying to download zyx.mega.YersiniaPestis 1.1<br />
Downloaded zyx.mega.YersiniaPestis 1.1 into ./robots/zyx.mega.YersiniaPestis_1.1<br />
.jar<br />
Trying to download zyx.micro.Ant 1.1<br />
Downloaded zyx.micro.Ant 1.1 into ./robots/zyx.micro.Ant_1.1.jar<br />
Trying to download zyx.nano.Ant 1.1<br />
Downloaded zyx.nano.Ant 1.1 into ./robots/zyx.nano.Ant_1.1.jar<br />
Trying to download zyx.nano.BacillusComma 1.0<br />
Downloaded zyx.nano.BacillusComma 1.0 into ./robots/zyx.nano.BacillusComma_1.0.j<br />
ar<br />
Ignoring jwst.DAD.DarkAndDarker_1.1.jar: .\robots\jwst.DAD.DarkAndDarker_1.1.jar<br />
(Can't find file)<br />
Ignoring jwst.DAD.DarkAndDarker_1.1.jar: .\robots\jwst.DAD.DarkAndDarker_1.1.jar<br />
(Can't find file)<br />
Removing old participants from server ...<br />
Removing entry ... bzdp.BoxCar_1.0 from meleerumble<br />
FAIL. Function temporarily disabled. Please try again later.<br />
Removing entry ... bzdp.BoxCar_1.0 from minimeleerumble<br />
FAIL. Function temporarily disabled. Please try again later.<br />
Removing entry ... bzdp.BoxCar_1.0 from micromeleerumble<br />
FAIL. Function temporarily disabled. Please try again later.<br />
Preparing melee battles list ...<br />
No robocode.properties, using defaults.<br />
Building robot database.<br />
Executing melee battles ...</pre><br />
<br />
So only a few are actually missing at the moment. No idea how much old ones there are. Anyway [http://darkcanuck.net/rumble/Contributors the rumble server] has gotten 3 battles from me! Thanks for the help. :) --[[User:Positive|Positive]] 18:34, 17 July 2009 (UTC)<br />
<br />
Feel free to replace links in the participant lists to those on the rumble server (if they exist). I'm not planning to remove any of those bots, and will periodically copy new ones over from my client. --[[User:Darkcanuck|Darkcanuck]] 18:53, 17 July 2009 (UTC)<br />
<br />
I'll see if I can post new versions of the participants zipfiles for one-on-one and melee this weekend. Last time I had trouble getting it online as my webspace (20Mb) was full. --[[User:GrubbmGait|GrubbmGait]] 13:00, 18 July 2009 (UTC)<br />
<br />
: You may contact me or Voidious to put them on my or his webspace. I don't know how much Voidious has, but I have around 1.1GB free. &raquo; <span style="font-size:0.9em;color:darkgreen;">[[User:Nat|Nat]] | [[User_talk:Nat|Talk]]</span> &raquo; 14:33, 18 July 2009 (UTC)<br />
<br />
:: Just curious, isn't it possible to upload the zipfile to this wiki? It seems the right place to put it. A complete zip for one-on-one would be approx 18 Mb, for melee approx 8 Mb. Just need to bring up my rusty Perl knowledge so I don't have to sort out the current participants manually. --[[User:GrubbmGait|GrubbmGait]] 11:30, 19 July 2009 (UTC)<br />
<br />
::: You must have access to this server to do that. I don't know if you have it or not. Because the wiki only accept .png, .gif, .jpg and .jpeg files. I agree with you that the wiki is the right place to upload them; but if you can't, feel free to contact me, my email is on my user page. &raquo; <span style="font-size:0.9em;color:darkgreen;">[[User:Nat|Nat]] | [[User_talk:Nat|Talk]]</span> &raquo; 11:41, 19 July 2009 (UTC)<br />
<br />
:::: It's not possible for me, max download is 2Mb. Melee is 6.5Mb, full one-on-one 16.8Mb. I'll try to put it on my own space first. --[[User:GrubbmGait|GrubbmGait]] 12:51, 19 July 2009 (UTC)<br />
<br />
== Friendlier Starting? ==<br />
<br />
We've always had this problem, but now I'm the victim instead of the perpetrator! "Getting Started" really should be ... let's say three steps at the most: 1) Install robocode in a fresh directory. 2) Apply this patch (that takes care of config). 3) Download these bots (all in one file). And really, (2)'s config should be packaged w/ robocode as long as the rumble itself is. In the mean time, perhaps update the instructions to point the config files to the correct server? I followed them, and unless I missed it every time I read through them, it never says to change the URLs to something other than http://rumble.fervir.com/... What should they be? I tell ya - a guy just wants to help out his old community and has to go to all this trouble ... --[[User:Simonton|Simonton]]<br />
<br />
Because the newer version isn't stable yet, we don't use the newer version of Robocode in RoboRumble. Starting from 1.7.1, you just install it, edit a little config, download bots and let it runs. We can't package the (2) with Robocode though, it is older version. This feature has already been implemented in 1.6.2 and later.<br />
<br />
And I must say, we are close to the new stable release. If we change to 1.7.1.x, we must all change (diff movement rule) our client. &raquo; <span style="font-size:0.9em;color:darkgreen;">[[User:Nat|Nat]] | [[User_talk:Nat|Talk]]</span> &raquo; 14:21, 5 August 2009 (UTC)<br />
<br />
Oh, Simonton? Nice to see you still randomly visit the wiki. I'll update it soon. &raquo; <span style="font-size:0.9em;color:darkgreen;">[[User:Nat|Nat]] | [[User_talk:Nat|Talk]]</span> &raquo; 14:23, 5 August 2009 (UTC)<br />
<br />
(Edit conflict) Yeah, we can use all the help we can get, so this should be as easy as possible. I think you just replace the rumble.fervir.com domain with darkcanuck.net. For Melee, the URLs are:<br />
* PARTICIPANTSURL=http://robowiki.net/w/index.php?title=RoboRumble/Participants/Melee<br />
* UPDATEBOTSURL=http://darkcanuck.net/rumble/RemoveOldParticipant<br />
* RESULTSURL=http://darkcanuck.net/rumble/UploadedResults<br />
I think just the participants URL would lack "/Melee" for 1v1, but I'm not at my rumble computer right now to confirm. And yeah, like Nat mentioned, we only allow 1.6.1.4, with the patched .jar, for RoboRumble clients right now. --[[User:Voidious|Voidious]] 14:25, 5 August 2009 (UTC)<br />
<br />
: I think he know what to do, he just pointed out that the newbie won't understand it at all =) &raquo; <span style="font-size:0.9em;color:darkgreen;">[[User:Nat|Nat]] | [[User_talk:Nat|Talk]]</span> &raquo; 14:38, 5 August 2009 (UTC)<br />
<br />
As I rewrote the starting guide, I noticed some funny thing. It used to say that: <p style="color:white">(Sorry, a little dirty) ... on your ''first time'' you can start robocode with ...</p> Sorry, for anyone who didn't find this amusing at all. And feel free to delete this if you think it shouldn't be here. &raquo; <span style="font-size:0.9em;color:darkgreen;">[[User:Nat|Nat]] | [[User_talk:Nat|Talk]]</span> &raquo; 14:38, 5 August 2009 (UTC)<br />
<br />
How about this... as soon as I get home from work, I'll make a patched robocode-setup-1.6.1.4.jar (maybe renamed robocode-rr-setup-1.6.1.4.jar or something), which includes the patched robocode.jar, fixed config files, AND the jar files of all robots currently in roborumble, that'll solve this :) --[[User:Rednaxela|Rednaxela]] 16:41, 5 August 2009 (UTC)<br />
<br />
That's what basically Simonton asked. I don't think ALL robots in rumble is good idea, it is large! And the installation will take very long. It is better if you just do all thing, zip it, and upload. You don't want the desktop and start menu shortcut for RR client. &raquo; <span style="font-size:0.9em;color:darkgreen;">[[User:Nat|Nat]] | [[User_talk:Nat|Talk]]</span> &raquo; 16:48, 5 August 2009 (UTC)<br />
<br />
The '''Roborumble Superpack''' is here! With this simple zip file, it is now virtually effortless to deploy a robocode installation suitable for your RoboRumble needs! I intend to update the ''Roborumble Superpack'' whenever a new version of robocode is approved for RoboRumble submissions, or the list of bots changes significantly. Cheers! :) --[[User:Rednaxela|Rednaxela]] 02:08, 6 August 2009 (UTC)<br />
<br />
I'm not sure having all the bots in the pack is such a great idea, as I think roborumble downloads them automatically, no? As long as they have to download it anyways, they may as well get the complete list instead of an old version ;)<br />
But having the pack will definitely help, it was a bit of a nuisance to get the old robocode when I was starting with it last week. [[User:Spinnercat|Spinnercat]] 02:20, 6 August 2009 (UTC)<br />
<br />
Awesome! Sure, you'll have to download the new versions for some of them, but probably 90% of the bots in that .zip are unlikely to ever change, so I like having the option to get them all at once. And some of us are still scarred from the days when the Robocode Repository would crash if you tried to actually download hundreds of bots in a row witha fresh RR client. =) --[[User:Voidious|Voidious]] 02:28, 6 August 2009 (UTC)<br />
<br />
Thanks, Red! Works great. --[[User:Simonton|Simonton]]</div>Simontonhttp://robowiki.net/w/index.php?title=Talk:RoboRumble/Contributing_to_RoboRumble&diff=9891Talk:RoboRumble/Contributing to RoboRumble2009-08-05T14:12:37Z<p>Simonton: /* Friendlier Starting? */ new section</p>
<hr />
<div>{{CreditForOldWikiArticle|oldpage=RoboRumble/StartingWithRoboRumble}}<br />
<br />
<br />
== Old Wiki ==<br />
----<br />
I presume all older issues are not valid anymore, otherwise you can find them on [[RoboRumble/StartingWithRoboRumbleOld|/StartingWithRoboRumbleOld]] or put them here below again.<br />
----<br />
<br />
Sweet. Much easier now thanks. How can I control how many battles are run at once? Or should I just setup a for loop in a batch file for that? --[[User:Miked0801|Miked0801]]<br />
* Halfway the file "roborumble.txt" you'll find "NUMBATTLES=xx", there you fill in the number of battles fought before uploading results and quitting robocode. In the batch-file I have made an infinitive loop so my client can run unattended all night. -- [[User:GrubbmGait|GrubbmGait]]<br />
* (Edit conflict) There are .txt files for each type of rumble - roborumble.txt, meleerumble.txt, and teamrumble.txt - in the 'roborumble' directory. The "NUMBATTLES" controls how many are run before uploading, "BATTLESPERBOT" is the minimum number of battles a bot needs before it stops getting priority, and "USER" is just to identify yourself in the logs and such. I have mine with "ITERATE=NOT" and I do use a shell script that loops to keep it running. -- [[User:Voidious|Voidious]]<br />
<br />
this bash script will be good for unix "roborumbler". Run forever battles, it catch standard and error stream and put it to a file in the directory ./log/tempNUMBER_OF_BATTLE.txt (the script have to be in the roborumble directory). For Linux: save it to a file in the roborumble directory, right click and set the file executable, create a directory called "log", then run the script from shell:<br />
<pre><br />
#!/bin/bash<br />
<br />
echo # new line<br />
count=0<br />
while [ "$var1" != "fine" ] # forever<br />
do<br />
let "count=count+1"<br />
echo "battle n: " $count<br />
sh roborumble.sh &> ./log/temp$count.txt<br />
echo<br />
done <br />
<br />
exit 0<br />
</pre><br />
<br />
p.s.: it's very useful for catch error, someone can traslate the script in windows's dos?<br />
[[Asdasd]]<br />
<br />
Wow - is 256MB still the default for the rumble? Why not at least 512, if robocode's default itself is 512? -- [[User:Simonton|Simonton]]<br />
<br />
I'm not sure - maybe because the GUI takes a lot of memory? -- [[User:Skilgannon|Skilgannon]]<br />
<br />
Ehh, the GUI shouldn't, not compared to many adaptive bots (particularly log targeting). Personally I always set 512MB in the rumble, and the only time I've had an out of memory problem with 512MB was when some particularly memory-heavy team (can't remember which one) was going. Personally I'd support defaulting to 512MB, at least for teams/melee, if [[Fnl]] is listening :-) -- [[User:Rednaxela|Rednaxela]]<br />
<br />
Can someone please zip a new update, i've unzipped the archives above and still get a ton of "Ignoring xxx..." message because they weren't download...thank you! (or even better someone start a new repository and put the zipped bots there...) --[[User:Starrynte|Starrynte]]<br />
<br />
== RoboRumbler ==<br />
I didn't know where to post this, but I guess the talk section is always good enough. I created an Java Application called [[Zyx/RoboRumbler|RoboRumbler]] to help controlling the resources [[RoboRumble]] uses. It's basically an application to let me work and run [[RoboRumble]] at the same time, I further explain it in it's page if anyone is interested. --[[User:Zyx|zyx]]<br />
<br />
Hmm, I'm curious about this. How does it account for the fact that RoboRumble is highly sensitive to the amount of CPU allocated to it? (i.e. other apps taking lots of CPU can make bots skip turns and potentially give very wrong results). If this limits the CPU allocated to RoboRumble, does it correctly make sure the constant for the time robots get per turn is increased suitably? ''(P.S. on the new wiki you can use <nowiki>--~~~~</nowiki> or the signature button to sign your messages with time/date easily. Personally I'd recommend it because it makes it possible to look back at conversations and know when they happened. :))'' --[[User:Rednaxela|Rednaxela]] 21:45, 26 November 2008 (UTC)<br />
<br />
Right now the application is not intended to work with CPU intensive applications, it basically runs them in the same way as they would normally do, but allows you to run then from time to time, and then forever by itself again and stuff like that. So you could be working in the machine, but not hogging the CPU yourself, you can set it to have a few battles and then sleep for 20 minutes. You could be writing some code(I did it to work on my thesis in the mean time), but not execute it until the [[RoboRumbler]] goes to sleep. Then you would have those 20 or any other amount of time to use the whole CPU when no rumble battles are running, so you could compile and test your application, and then, when the rumble is about to start again, you lower your activity. And when you are heading to your bed, set the sleep time to 0 and let it rumble without stop.<br />
<br />
Hopefully it will grow to a system that doesn't need for the user to be careful, but right now is the best I have. I was doing the same thing but manually, I ran the rumble battles while I was writing stuff, waited for it to finish so I could ran my application and then set the rumble again. But in no moment my idea was to really lower the CPU usage for [[RoboRumble]] during battles, but to have some deterministic break times when I could use the computer. (P.S. Thanks about the <nowiki>--~~~~</nowiki>, I saw it before in your post, but thought you wrote it yourself, and seemed like to much work) --[[User:Zyx|Zyx]] 23:44, 26 November 2008 (UTC)<br />
<br />
==stable rumble client==<br />
<br />
Are the stable rumble client 1.5.4 and, 1.6.0 or 1.6.0.1? someone have tested the new robocode version? --[[User:Lestofante|lestofante]] 15:44, 10 December 2008 (UTC)<br />
<br />
I know 1.6.1.4 is stable (some earlier 1.6.1.x versions were bad), with a minor aesthetic bug that it sometimes spams the "Round 31 initializing...." to stdout but that doesn't affect the battles or the uploading so it's good for RR. Additionally, as of 1.6.1.4 the ITERATE option works properly again, so external loop scripts shouldn't be needed. I plan to test 1.6.2 Beta 2 some time but haven't done that yet. --[[User:Rednaxela|Rednaxela]] 20:10, 10 December 2008 (UTC)<br />
<br />
==RUNONLY==<br />
I have RUNONLY=NANO in meleerumble, yet it still runs battles with tons of non-nano bots. 1) will this affect rankings improperly 2) how do you get it to run only nanos...as runonly is supposed to do (using version 1.6.0.1) --[[User:Starrynte|Starrynte]] 00:59, 3 April 2009 (UTC)<br />
<br />
* I've never tried these modes so don't know how well they work. I'm pretty sure RUNUNLY=SERVER is the only way to guarantee full pairings, since that's the mode where the client uses priority battles sent by the server. Also, I think the client considers nano pairings in melee to be any matchups between two nano bots, even if there are other sizes in the same battle -- which means you don't need a battle with 10 nanos in order to get meleenano results. That's why ntc.Opposite's nano results are up to 600+ already. --[[User:Darkcanuck|Darkcanuck]] 01:18, 3 April 2009 (UTC)<br />
<br />
==Questions from Positive==<br />
<br />
Hey, I'd like to contribute, but need some help. I've followed the instructions on this page (I used version 1.6.1.4). But what's the correct configuration for meleerumble.txt for Darkcanuck's server? Also: Can I safely quit the roborumble client when I need my CPU back? Is there something else usefull to know/do before running? :) --[[User:Positive|Positive]] 16:40, 17 July 2009 (UTC)<br />
<br />
I think you can just replace the domain with darkcanuck.net, but my full URLs are:<br />
* PARTICIPANTSURL=http://robowiki.net/w/index.php?title=RoboRumble/Participants/Melee<br />
* UPDATEBOTSURL=http://darkcanuck.net/rumble/RemoveOldParticipant<br />
* RESULTSURL=http://darkcanuck.net/rumble/UploadedResults<br />
Yes, run the client as much or as little as you like, of course. =) Hmm, one issue comes to mind: the bots using Robocode Repository ids will fail to download, I think. I fixed the URLs on the 1v1 list and some on the Melee list, but still lots of ids there. Running the 1v1 client to download bots first might get a lot of the missing ones. I'll try and get that fixed today.<br />
<br />
--[[User:Voidious|Voidious]] 16:58, 17 July 2009 (UTC)<br />
<br />
Hrm, well it seems like it should work, with Portia it did, or did you have to add it manually? I could make a script and change all lines with "ROBOTNAME,NUMBER" to "ROBOTNAME,http://www.robocoderepository.com/BotFiles/NUMBER/ROBOTNAME.JAR" --[[User:Positive|Positive]] 17:11, 17 July 2009 (UTC)<br />
<br />
Hmm, now I'm not sure, really. I don't think I grabbed Portia manually. Feel free to update the list yourself, if you want, I did exactly as you said using regular expression find/replace in my text editor (TextWrangler). I'll get to it later today if you haven't yet. --[[User:Voidious|Voidious]] 17:24, 17 July 2009 (UTC)<br />
<br />
Hmm, I tried it, and it's not that easy. For example, the pure converted form of TheArtOfWar changes from "tzu.TheArtOfWar 1.2,689" to "tzu.TheArtOfWar 1.2,http://www.robocoderepository.com/BotFiles/689/tzu.TheArtOfWar 1.2.jar". But I don't know what the actual download link is. (It's not "tzu.TheArtOfWar_1.2.jar" either). Any downside to just activating roborumble and seeing what happens? --[[User:Positive|Positive]] 17:54, 17 July 2009 (UTC)<br />
<br />
It seems TheArtOfWar was an exception, I'll replace the original with the new in a few moments. :) --[[User:Positive|Positive]] 18:06, 17 July 2009 (UTC)<br />
<br />
Cool. I'm not sure what's up with that, but I was thinking, "I swear I used that same format for the 1v1 list and it worked." =) Also, Darkcanuck was kind enough to post all his rumble bots here: [http://darkcanuck.net/rumble/robots/], so you can grab any missing ones. (I didn't mention before because it's not a great way to get all of them.)<br />
<br />
One of us should post an updated .zip of rumble bots as a base point for new RoboRumblers... there are a few old ones posted around the wiki, but I can never remember where. The hurdle with that is cleaning out all the multiple versions of certain bots before zipping.<br />
<br />
--[[User:Voidious|Voidious]] 18:14, 17 July 2009 (UTC)<br />
<br />
I found the .zip here: [[RoboRumble/Starting With RoboRumble]]. That zip is pretty complete, the message I got only showed a few missing:<br />
<br />
<pre><br />
Trying to download tripphippy.Alice 1.0<br />
Downloaded tripphippy.Alice 1.0 into ./robots/tripphippy.Alice_1.0.jar<br />
Trying to download voidious.Diamond 1.183b<br />
Downloaded voidious.Diamond 1.183b into ./robots/voidious.Diamond_1.183b.jar<br />
Trying to download voidious.micro.BlitzBat 1.04<br />
Downloaded voidious.micro.BlitzBat 1.04 into ./robots/voidious.micro.BlitzBat_1.<br />
04.jar<br />
Trying to download voidious.mini.BrokenSword 1.04<br />
Downloaded voidious.mini.BrokenSword 1.04 into ./robots/voidious.mini.BrokenSwor<br />
d_1.04.jar<br />
Trying to download zyx.mega.YersiniaPestis 1.1<br />
Downloaded zyx.mega.YersiniaPestis 1.1 into ./robots/zyx.mega.YersiniaPestis_1.1<br />
.jar<br />
Trying to download zyx.micro.Ant 1.1<br />
Downloaded zyx.micro.Ant 1.1 into ./robots/zyx.micro.Ant_1.1.jar<br />
Trying to download zyx.nano.Ant 1.1<br />
Downloaded zyx.nano.Ant 1.1 into ./robots/zyx.nano.Ant_1.1.jar<br />
Trying to download zyx.nano.BacillusComma 1.0<br />
Downloaded zyx.nano.BacillusComma 1.0 into ./robots/zyx.nano.BacillusComma_1.0.j<br />
ar<br />
Ignoring jwst.DAD.DarkAndDarker_1.1.jar: .\robots\jwst.DAD.DarkAndDarker_1.1.jar<br />
(Can't find file)<br />
Ignoring jwst.DAD.DarkAndDarker_1.1.jar: .\robots\jwst.DAD.DarkAndDarker_1.1.jar<br />
(Can't find file)<br />
Removing old participants from server ...<br />
Removing entry ... bzdp.BoxCar_1.0 from meleerumble<br />
FAIL. Function temporarily disabled. Please try again later.<br />
Removing entry ... bzdp.BoxCar_1.0 from minimeleerumble<br />
FAIL. Function temporarily disabled. Please try again later.<br />
Removing entry ... bzdp.BoxCar_1.0 from micromeleerumble<br />
FAIL. Function temporarily disabled. Please try again later.<br />
Preparing melee battles list ...<br />
No robocode.properties, using defaults.<br />
Building robot database.<br />
Executing melee battles ...</pre><br />
<br />
So only a few are actually missing at the moment. No idea how much old ones there are. Anyway [http://darkcanuck.net/rumble/Contributors the rumble server] has gotten 3 battles from me! Thanks for the help. :) --[[User:Positive|Positive]] 18:34, 17 July 2009 (UTC)<br />
<br />
Feel free to replace links in the participant lists to those on the rumble server (if they exist). I'm not planning to remove any of those bots, and will periodically copy new ones over from my client. --[[User:Darkcanuck|Darkcanuck]] 18:53, 17 July 2009 (UTC)<br />
<br />
I'll see if I can post new versions of the participants zipfiles for one-on-one and melee this weekend. Last time I had trouble getting it online as my webspace (20Mb) was full. --[[User:GrubbmGait|GrubbmGait]] 13:00, 18 July 2009 (UTC)<br />
<br />
: You may contact me or Voidious to put them on my or his webspace. I don't know how much Voidious has, but I have around 1.1GB free. &raquo; <span style="font-size:0.9em;color:darkgreen;">[[User:Nat|Nat]] | [[User_talk:Nat|Talk]]</span> &raquo; 14:33, 18 July 2009 (UTC)<br />
<br />
:: Just curious, isn't it possible to upload the zipfile to this wiki? It seems the right place to put it. A complete zip for one-on-one would be approx 18 Mb, for melee approx 8 Mb. Just need to bring up my rusty Perl knowledge so I don't have to sort out the current participants manually. --[[User:GrubbmGait|GrubbmGait]] 11:30, 19 July 2009 (UTC)<br />
<br />
::: You must have access to this server to do that. I don't know if you have it or not. Because the wiki only accept .png, .gif, .jpg and .jpeg files. I agree with you that the wiki is the right place to upload them; but if you can't, feel free to contact me, my email is on my user page. &raquo; <span style="font-size:0.9em;color:darkgreen;">[[User:Nat|Nat]] | [[User_talk:Nat|Talk]]</span> &raquo; 11:41, 19 July 2009 (UTC)<br />
<br />
:::: It's not possible for me, max download is 2Mb. Melee is 6.5Mb, full one-on-one 16.8Mb. I'll try to put it on my own space first. --[[User:GrubbmGait|GrubbmGait]] 12:51, 19 July 2009 (UTC)<br />
<br />
== Friendlier Starting? ==<br />
<br />
We've always had this problem, but now I'm the victim instead of the perpetrator! "Getting Started" really should be ... let's say three steps at the most: 1) Install robocode in a fresh directory. 2) Apply this patch (that takes care of config). 3) Download these bots (all in one file). And really, (2)'s config should be packaged w/ robocode as long as the rumble itself is. In the mean time, perhaps update the instructions to point the config files to the correct server? I followed them, and unless I missed it every time I read through them, it never says to change the URLs to something other than http://rumble.fervir.com/... What should they be? I tell ya - a guy just wants to help out his old community and has to go to all this trouble ... --[[User:Simonton|Simonton]]</div>Simontonhttp://robowiki.net/w/index.php?title=Talk:Komarious&diff=5818Talk:Komarious2009-04-30T06:41:00Z<p>Simonton: :)</p>
<hr />
<div>Hey Nat, thanks for the cleanup - I didn't know about the Navbox template for subpages (edit: oh, because you just created it - nice =)) or the auto-categorization for the Infobox. The two formatting things I wanted to keep were in the "special" part (because I want it more indented), and the nbsp's in the Infobox, because I hate when those break onto two lines. (If I could find a cleaner way of getting the indenting I wanted in the "what's special" part, that would be fine with me, though...) --[[User:Voidious|Voidious]] 18:17, 25 April 2009 (UTC)<br />
<br />
: Well, I don't see any difference between your table-style and normal style so I removed them. Now I noticed your special indentation. What about <nowiki>:*</nowiki>? I didn't know before that nbsp can handler those link break! Thanks! If you install ParserFunction extension, it can auto-category Mini/Micro/Nano bot from code size, too. &raquo; <span style="font-size:0.9em;color:darkgreen;">[[User:Nat|Nat]] | [[User_talk:Nat|Talk]]</span> &raquo; 18:51, 25 April 2009 (UTC)<br />
<br />
I dropped by the wiki for the first time in quite a long while - only to find you're back at it and trying to challenge my throne! (Which I must admit I was very surprised to see I still held.) [[User:Simonton|Simonton]]</div>Simontonhttp://robowiki.net/w/index.php?title=Talk:Darkcanuck/RRServer&diff=3325Talk:Darkcanuck/RRServer2008-10-11T03:30:25Z<p>Simonton: /* Bravo */</p>
<hr />
<div>Fire away...<br />
<br />
Just a suggestion for an additional check. I have never seen score a bot more than 8000 points, so this could be checked too. When examining the results that messed up the original roborumble rating beyond repair, I saw results of 20000 against 16000 (Thats what you get when running OneOnOne with MELEE=YES). For the time being I let my client running (unattended) for ABC's server, as I don't really have the time for bughunting. Your effort however seems promising. Good luck. -- [[GrubbmGait]]<br />
<br />
* Thanks! That's a good check, will be combining that with the survival >=35 (also your suggestion I think) once I rearrange the error handling and failure output to the client. Then I'll look into ELO... --[[Darkcanuck]]<br />
* Your checks have both been implemented. -- [[Darkcanuck]]<br />
<br />
Looking very nice! I have a couple questions and thoughts I thought I'll mention. So what is this "Ideal" column in the results mean? One thought I had about ratings, is perhaps it would be best to make the APS fill missing pairings with Glicko-based estimates? I'm thinking that would give the best long term stability/accuracy once pairings are complete while having something a more meaningful before pairings are complete before the pairings are complete. --[[User:Rednaxela|Rednaxela]] 01:18, 26 September 2008 (UTC)<br />
<br />
Thanks! I've just posted a bit more about ratings [[Darkcanuck/RRServer/Ratings | here]]. The "Ideal" column is my attempt to reverse calculate a rating based on a bot's APS. I just inverted the Glicko formula for "E" (expected probability) to yield a rating given if given E (i.e. APS) and a competitor's rating and RD. For the latter two I used the defaults (1500 and 350) so theoretically if the APS represents the score vs an average bot (and there's a uniform distribution?) then the rating might converge to the "ideal" value. But I have no idea if it works, just wanted to see how close it might be.<br />
I'm not sure you could fill in the pairings using Glicko + APS -- the reason systems like Glicko exist is to get around the problem of incomplete pairings, so the Glicko rating should be enough in itself. If it's accurate, that is -- we'll see once the ratings catch up to the pairings already submitted... -- [[User:Darkcanuck|Darkcanuck]] 03:39, 26 September 2008 (UTC)<br />
<br />
Ahh, I see. Thanks for the explanation. If the Glicko rating doesn't converge very very close to the "Ideal" then I'd say it alone might not be the best fit alone for Robocode due to how complete pairings are not hard to get. The reason I suggest using APS and filling missing pairings with Glicko-based percent estimates, is because my proposed method will be guaranteed to ''always'' converge to an exact APS ranking order when pairings are complete, and would quite surely be at least slightly better than APS when pairings are not complete. Perhaps I'm more picky than most, but I'd consider a hybrid necessary if "Glicko" doesn't in practice converge to "Ideal" to within an accuracy that preserves exact rankings with APS (which I think is very plain and simple the most fair when there are complete pairings). I suppose we'll see how accurately Glicko converges :) --[[User:Rednaxela|Rednaxela]] 04:25, 26 September 2008 (UTC)<br />
<br />
:Be careful about the "ideal" convergence concept! Keep in mind that I made this value up and it doesn't really have a statistical basis of any sort. I was just curious what a naive reversal with a single data point might produce, in order to get an idea of what neighbourhood DrussGT's rating might be in, for example. I also wanted to get a sense whether I had programmed the formulas correctly. I wonder though, if we're abusing these rating systems by using %score instead of absolute win/lose values (1/0)? Would the Glicko rating converge more rapidly to match the APS scale if I had chosen win/loss? I'm very curious, but no so much as to interrupt the current rebuild, which may take longer than I thought. -- [[User:Darkcanuck|Darkcanuck]] 04:54, 26 September 2008 (UTC)<br />
<br />
:Well, I'm not talking about the convergence to that "Ideal" column. I'm talking about convergence of the relative rankings as opposed to specific rating numbers. If the rankings, don't converge to exactly the same order as APS, then I think there's issue enough to justify a hybrid that uses APS, with ELO or Glicko to estimate missing pairings. --[[User:Rednaxela|Rednaxela]] 05:10, 26 September 2008 (UTC)<br />
<br />
:Gotcha. I suppose you could keep track of the rating (Elo or Glicko) and just use it to calculate expected scores for missing pairings. Then generate an estimated APS for full pairings. We'll have to see how well the ratings stabilize. I'm thinking I should have used Glicko-2 instead, since it includes a volatility rating to account for erratic (read problem bot) performance. -- [[User:Darkcanuck|Darkcanuck]] 06:22, 26 September 2008 (UTC)<br />
<br />
Started sending the results to your server, as long as you relay them to ABC's server. What is the delay btw? --[[User:GrubbmGait|GrubbmGait]] 10:08, 26 September 2008 (UTC)<br />
<br />
:Thanks for joining in! I have no plans to stop relaying results and have been doing so for almost a week now. If by "delay" you mean occasional slow connections, it's due to the [[Darkcanuck/RRServer/Design#Scoring_updates | scoring update]] and I've posted it on the [[Darkcanuck/RRServer/KnownIssues | known issues]] page. I have this process cranked up at the moment while I try to get the ratings to catch up, but it will get faster soon. :) -- [[User:Darkcanuck|Darkcanuck]] 15:25, 26 September 2008 (UTC)<br />
<br />
Great job with his server, you can always get the ranking/battles_* files from my server and sumbit them all into yours. I'm also experimenting with mySql atm. My SQL skills are a little rusty but it's all coming back pretty fast :).<br />
<br />
I also have a few doubts about the new ranting method. The first one is: why? From what I understand Glicko is an ELO extension for rankings where the match frequency is not uniform between participants, which is not the rumble's case? As an experiment it's very cool, but for me the "old" ELO method is time tested and proven to work great, and should be the default sorting method for the ranking table. --[[User:ABC|ABC]] 11:23, 26 September 2008 (UTC)<br />
<br />
: I also have some doubts about if Glicko will actually give better or much different results than ELO, however I'm not sure ELO is really the best default ranking system when full pairings are easiest to get. I suppose we'll see once your server gets to full pairings, but I'm strongly suspecting there will be some ranking deviations from the APS ranking, which I think is hard to argue is in any way biased. --[[User:Rednaxela|Rednaxela]] 13:26, 26 September 2008 (UTC)<br />
<br />
:I have doubts as well, but I wouldn't have known until I tried it. My major objection against Elo is the lack of a clear, published implementation. It was easier to implement Glicko than to sort through the RR server code. If someone can clarify this for me, sure I'll try it out. Why not? -- [[User:Darkcanuck|Darkcanuck]] 15:25, 26 September 2008 (UTC)<br />
<br />
== Bravo ==<br />
<br />
I just want to leave a note saying you're awesome. :) It's really nice having someone put effort into improving the rumble itself. Good work! --[[User:Simonton|Simonton]] 03:27, 11 October 2008 (UTC)<br />
<br />
Oh, and FNL, if you're reading this, that goes double for you :). --[[User:Simonton|Simonton]] 03:30, 11 October 2008 (UTC)</div>Simontonhttp://robowiki.net/w/index.php?title=Talk:Darkcanuck/RRServer&diff=3324Talk:Darkcanuck/RRServer2008-10-11T03:27:22Z<p>Simonton: New section: Bravo</p>
<hr />
<div>Fire away...<br />
<br />
Just a suggestion for an additional check. I have never seen score a bot more than 8000 points, so this could be checked too. When examining the results that messed up the original roborumble rating beyond repair, I saw results of 20000 against 16000 (Thats what you get when running OneOnOne with MELEE=YES). For the time being I let my client running (unattended) for ABC's server, as I don't really have the time for bughunting. Your effort however seems promising. Good luck. -- [[GrubbmGait]]<br />
<br />
* Thanks! That's a good check, will be combining that with the survival >=35 (also your suggestion I think) once I rearrange the error handling and failure output to the client. Then I'll look into ELO... --[[Darkcanuck]]<br />
* Your checks have both been implemented. -- [[Darkcanuck]]<br />
<br />
Looking very nice! I have a couple questions and thoughts I thought I'll mention. So what is this "Ideal" column in the results mean? One thought I had about ratings, is perhaps it would be best to make the APS fill missing pairings with Glicko-based estimates? I'm thinking that would give the best long term stability/accuracy once pairings are complete while having something a more meaningful before pairings are complete before the pairings are complete. --[[User:Rednaxela|Rednaxela]] 01:18, 26 September 2008 (UTC)<br />
<br />
Thanks! I've just posted a bit more about ratings [[Darkcanuck/RRServer/Ratings | here]]. The "Ideal" column is my attempt to reverse calculate a rating based on a bot's APS. I just inverted the Glicko formula for "E" (expected probability) to yield a rating given if given E (i.e. APS) and a competitor's rating and RD. For the latter two I used the defaults (1500 and 350) so theoretically if the APS represents the score vs an average bot (and there's a uniform distribution?) then the rating might converge to the "ideal" value. But I have no idea if it works, just wanted to see how close it might be.<br />
I'm not sure you could fill in the pairings using Glicko + APS -- the reason systems like Glicko exist is to get around the problem of incomplete pairings, so the Glicko rating should be enough in itself. If it's accurate, that is -- we'll see once the ratings catch up to the pairings already submitted... -- [[User:Darkcanuck|Darkcanuck]] 03:39, 26 September 2008 (UTC)<br />
<br />
Ahh, I see. Thanks for the explanation. If the Glicko rating doesn't converge very very close to the "Ideal" then I'd say it alone might not be the best fit alone for Robocode due to how complete pairings are not hard to get. The reason I suggest using APS and filling missing pairings with Glicko-based percent estimates, is because my proposed method will be guaranteed to ''always'' converge to an exact APS ranking order when pairings are complete, and would quite surely be at least slightly better than APS when pairings are not complete. Perhaps I'm more picky than most, but I'd consider a hybrid necessary if "Glicko" doesn't in practice converge to "Ideal" to within an accuracy that preserves exact rankings with APS (which I think is very plain and simple the most fair when there are complete pairings). I suppose we'll see how accurately Glicko converges :) --[[User:Rednaxela|Rednaxela]] 04:25, 26 September 2008 (UTC)<br />
<br />
:Be careful about the "ideal" convergence concept! Keep in mind that I made this value up and it doesn't really have a statistical basis of any sort. I was just curious what a naive reversal with a single data point might produce, in order to get an idea of what neighbourhood DrussGT's rating might be in, for example. I also wanted to get a sense whether I had programmed the formulas correctly. I wonder though, if we're abusing these rating systems by using %score instead of absolute win/lose values (1/0)? Would the Glicko rating converge more rapidly to match the APS scale if I had chosen win/loss? I'm very curious, but no so much as to interrupt the current rebuild, which may take longer than I thought. -- [[User:Darkcanuck|Darkcanuck]] 04:54, 26 September 2008 (UTC)<br />
<br />
:Well, I'm not talking about the convergence to that "Ideal" column. I'm talking about convergence of the relative rankings as opposed to specific rating numbers. If the rankings, don't converge to exactly the same order as APS, then I think there's issue enough to justify a hybrid that uses APS, with ELO or Glicko to estimate missing pairings. --[[User:Rednaxela|Rednaxela]] 05:10, 26 September 2008 (UTC)<br />
<br />
:Gotcha. I suppose you could keep track of the rating (Elo or Glicko) and just use it to calculate expected scores for missing pairings. Then generate an estimated APS for full pairings. We'll have to see how well the ratings stabilize. I'm thinking I should have used Glicko-2 instead, since it includes a volatility rating to account for erratic (read problem bot) performance. -- [[User:Darkcanuck|Darkcanuck]] 06:22, 26 September 2008 (UTC)<br />
<br />
Started sending the results to your server, as long as you relay them to ABC's server. What is the delay btw? --[[User:GrubbmGait|GrubbmGait]] 10:08, 26 September 2008 (UTC)<br />
<br />
:Thanks for joining in! I have no plans to stop relaying results and have been doing so for almost a week now. If by "delay" you mean occasional slow connections, it's due to the [[Darkcanuck/RRServer/Design#Scoring_updates | scoring update]] and I've posted it on the [[Darkcanuck/RRServer/KnownIssues | known issues]] page. I have this process cranked up at the moment while I try to get the ratings to catch up, but it will get faster soon. :) -- [[User:Darkcanuck|Darkcanuck]] 15:25, 26 September 2008 (UTC)<br />
<br />
Great job with his server, you can always get the ranking/battles_* files from my server and sumbit them all into yours. I'm also experimenting with mySql atm. My SQL skills are a little rusty but it's all coming back pretty fast :).<br />
<br />
I also have a few doubts about the new ranting method. The first one is: why? From what I understand Glicko is an ELO extension for rankings where the match frequency is not uniform between participants, which is not the rumble's case? As an experiment it's very cool, but for me the "old" ELO method is time tested and proven to work great, and should be the default sorting method for the ranking table. --[[User:ABC|ABC]] 11:23, 26 September 2008 (UTC)<br />
<br />
: I also have some doubts about if Glicko will actually give better or much different results than ELO, however I'm not sure ELO is really the best default ranking system when full pairings are easiest to get. I suppose we'll see once your server gets to full pairings, but I'm strongly suspecting there will be some ranking deviations from the APS ranking, which I think is hard to argue is in any way biased. --[[User:Rednaxela|Rednaxela]] 13:26, 26 September 2008 (UTC)<br />
<br />
:I have doubts as well, but I wouldn't have known until I tried it. My major objection against Elo is the lack of a clear, published implementation. It was easier to implement Glicko than to sort through the RR server code. If someone can clarify this for me, sure I'll try it out. Why not? -- [[User:Darkcanuck|Darkcanuck]] 15:25, 26 September 2008 (UTC)<br />
<br />
== Bravo ==<br />
<br />
I just want to leave a note saying you're awesome. :) It's really nice having someone put effort into improving the rumble itself. Good work! --[[User:Simonton|Simonton]] 03:27, 11 October 2008 (UTC)</div>Simontonhttp://robowiki.net/w/index.php?title=RoboResearch/Development&diff=3223RoboResearch/Development2008-10-07T17:59:58Z<p>Simonton: Remoting</p>
<hr />
<div>This page will keep the current design for the next phase(s) of [[RoboResearch]]. I'll keep this page as the "official" design; please use the discussion page to offer feedback and contribute new ideas. This page exists to solicit such input, so please don't be bashful!<br />
<br />
=== The GUI ===<br />
[[Image:RoboResearch.JPG]]<br />
<br />
This is the current development GUI for RoboResearch. In the top section you add and orginize which challenges will be run. All the buttons should be obvious except "Group". When you select multiple challenges and press group, they all get the same number in front of them (that's the group number). An effort will be made to complete the battles for all challenges in the same group at about the same time. As challenges complete, they will drop to the bottom of the list and, if they were the last in their group, all others' group numbers will decrement.<br />
<br />
In the bottom section you control what each of your concurrent battle-running threads does. The "Prefer Group" spinner means that if the stated group exists in the pane above, it will run battles from that group. If it does not, it will default back to running from group 1. So, for example, I could add the rumble as group 1 in the top section (once that functionality is available), then set my threads to prefer 1 and 2 as pictured above. One thread would then always run the rumble, and the other thread would run from challenges I add until they are all done, at which time it would default back to running the rumble.<br />
<br />
There will be a "Configure" button in the top section, too, which for the rumble could set things like MAX_BATTLES. After all bots in the rumble have that many battles, RoboResearch would consider that entry "done". You could add 2 rumble entries, one with unlimited battles and one with a max, to achieve things like "first run all bots up to 2000 battles, then run my challenges, then go back to the rumble again".<br />
<br />
'''What Works:'''<br />
* Adding challenges<br />
* Removing challenges<br />
* Adding threads<br />
* Starting, pausing and killing threads<br />
* The "Prefer Group" feature<br />
* Dynamically updating results for any item in the battle queue<br />
* Bulk thread operations<br />
* Re-organizing the queue<br />
* A button to copy from the results table into wiki format<br />
* Adding/removing bots from the results window of a challenge<br />
* Seeing scores from each season of a challenge<br />
* The "tied-for-best" scores for each reference bot are highlighted in the results window (currently defined as within two standard deviations of each other)<br />
<br />
'''To-Do:'''<br />
* Editing challenges in the queue<br />
* Adding "the rumble" as an option for the queue<br />
* More results options (TBD, see [[Talk:RoboResearch/Development#Showing_Results]])<br />
<br />
=== Running Networked ===<br />
<br />
The RoboResearch clients (the GUI and CLI) now interact with 3 distinct entities to accomplish their task: a BattleQueue, ScoreHistory and BotRepository. These are 3 interfaces, with current implementations that can run within the same virtual machine. Some of them take listeners in their arguments, for example a ResultsListener (defined by another interface) that receives any updates submitted to the ScoreHistory for a given challenge. The greatest hurdle to running distributed across the internet is writing proxies for these interfaces that will pass the requests from one machine to the next. Once we have something like that we can almost immediately run networked, with further efforts required to make fair battle queue policies and automatic uploading/downloading of required bots. Then comes icing like the ability to specify "I want to prefer battles submitted by Simonton" (just as a random, hypothetical example).<br />
<br />
Development work on the proxies has been started. Basically I'm creating my own remoting system. Is this necessary? Does the world need another remoting framework? Nope. But it's fun.</div>Simontonhttp://robowiki.net/w/index.php?title=User:Simonton/PFResearch&diff=3203User:Simonton/PFResearch2008-10-05T06:36:47Z<p>Simonton: 0095 details</p>
<hr />
<div>My next experiment: goto path surfing. <strike>It works by choosing (currently) 31 impact points on each wave, spread out across GF -1 to 1, then plotting the path through them with the least sum of the dangers.</strike> It currently works like this, which will become more sophisticated with time:<br />
* For each [[Wave]] choose 31 GuessFactors, spread out across GFs -1 to 1, being sure to include local minimum danger points.<br />
* To find the best path from a given point:<br />
** Find the next wave to strike that point.<br />
** Find the points on that wave that meet the 31 chosen GFs AND could be reached from this point along the path of maximum escape.<br />
** Recurse to find the danger of each of those points.<br />
** Choose the point with the least danger.<br />
** Add in the danger of this point, add this point to the best path so far, and return.<br />
So far there's very humble beginnings: <br />
<br />
See old results at [[/DCGTResearchArchive]]<br />
<br />
=== [[MovementChallenge2K7/ResultsFastLearning|MC2K7 Fast Learning Results]] ===<br />
{| border=1 cellspacing=0<br />
| '''Bot Name''' || '''Author''' || '''Type''' || '''HOF''' || '''SPL''' || '''GRG''' || '''Sub 1''' || '''WAY (Sub 2)''' || '''GR3''' || '''RKM''' || '''Sub 3''' || '''ASC''' || '''CC''' || '''CHK''' || '''Sub 4''' || '''Total''' || '''Comments'''<br />
|- <br />
| 0057 || [[Simonton]] || PF/DC || 99.56 || 88.14 || 86.88 || '''91.53''' || '''65.95''' || 62.77 || 75.40 || '''69.08''' || 34.95 || 42.30 || 40.09 || '''39.11''' || '''66.42''' || 75.0 seasons<br />
|- <br />
| 0058 || [[Simonton]] || PF/DC || 99.51 || 87.62 || 87.97 || '''91.70''' || '''64.39''' || 61.66 || 75.21 || '''68.44''' || 34.93 || 43.53 || 39.35 || '''39.27''' || '''65.95''' || 75.0 seasons<br />
|- <br />
| 0059 || [[Simonton]] || PF/DC || 99.53 || 88.25 || 87.34 || '''91.71''' || '''67.40''' || 63.42 || 76.11 || '''69.76''' || 35.03 || 42.28 || 40.35 || '''39.22''' || '''67.02''' || 75.0 seasons<br />
|- <br />
| 0060 || [[Simonton]] || PF/DC || 99.47 || 88.79 || 88.33 || '''92.20''' || '''67.67''' || 63.39 || 76.99 || '''70.19''' || 35.82 || 41.39 || 40.17 || '''39.13''' || '''67.30''' || 75.0 seasons<br />
|- <br />
| 0061 || [[Simonton]] || PF/DC || 99.80 || 88.45 || 89.72 || '''92.66''' || '''69.63''' || 63.29 || 76.61 || '''69.95''' || 34.52 || 41.29 || 41.34 || '''39.05''' || '''67.82''' || 75.0 seasons<br />
|- <br />
| 0062 || [[Simonton]] || PF/DC || 99.98 || 88.02 || 89.75 || '''92.59''' || '''68.40''' || 63.20 || 76.18 || '''69.69''' || 33.00 || 40.64 || 39.98 || '''37.88''' || '''67.14''' || 75.0 seasons<br />
|- <br />
| 0063 || [[Simonton]] || PF/DC || 99.97 || 88.59 || 89.93 || '''92.83''' || '''67.91''' || 63.30 || 77.67 || '''70.48''' || 33.43 || 40.42 || 40.10 || '''37.98''' || '''67.30''' || 75.0 seasons<br />
|- <br />
| 0064 || [[Simonton]] || PF/DC || 99.99 || 88.10 || 88.74 || '''92.28''' || '''68.93''' || 62.83 || 77.27 || '''70.05''' || 34.86 || 41.15 || 40.69 || '''38.90''' || '''67.54''' || 75.0 seasons<br />
|-<br />
| 0065 || [[Simonton]] || PF/DC || 99.96 || 87.89 || 88.98 || '''92.28''' || '''69.17''' || 62.83 || 77.79 || '''70.31''' || 34.00 || 42.49 || 41.87 || '''39.45''' || '''67.80''' || 75.0 seasons<br />
|-<br />
| 0066 || [[Simonton]] || PF/DC || 99.99 || 88.27 || 88.78 || '''92.34''' || '''69.28''' || 63.16 || 76.50 || '''69.83''' || 34.36 || 40.22 || 40.27 || '''38.28''' || '''67.43''' || 75.0 seasons<br />
|-<br />
| 0067 || [[Simonton]] || PF/DC || 99.98 || 88.00 || 89.35 || '''92.44''' || '''69.28''' || 63.19 || 78.40 || '''70.80''' || 34.96 || 41.76 || 42.00 || '''39.57''' || '''68.02''' || 75.0 seasons<br />
|-<br />
| 0068 || [[Simonton]] || PF/DC || 99.97 || 87.64 || 90.31 || '''92.64''' || '''68.70''' || 63.82 || 78.27 || '''71.04''' || 36.20 || 42.71 || 42.85 || '''40.59''' || '''68.24''' || 75.0 seasons<br />
|-<br />
| 0069 || [[Simonton]] || PF/DC || 99.96 || 87.72 || 91.49 || '''93.06''' || '''68.61''' || 63.41 || 79.12 || '''71.27''' || 33.84 || 41.48 || 43.23 || '''39.52''' || '''68.11''' || 75.0 seasons<br />
|-<br />
| 0070 || [[Simonton]] || PF/DC || 99.95 || 87.65 || 91.89 || '''93.17''' || '''70.09''' || 63.20 || 80.43 || '''71.82''' || 34.34 || 41.19 || 41.68 || '''39.07''' || '''68.53''' || 75.0 seasons<br />
|-<br />
| 0071 || [[Simonton]] || PF/DC || 99.98 || 87.82 || 92.07 || '''93.29''' || '''68.44''' || 63.15 || 80.22 || '''71.68''' || 33.99 || 41.64 || 42.41 || '''39.35''' || '''68.19''' || 75.0 seasons<br />
|-<br />
| 0072 || [[Simonton]] || PF/DC || 99.97 || 87.84 || 92.39 || '''93.40''' || '''69.47''' || 63.19 || 80.01 || '''71.60''' || 34.20 || 40.98 || 42.32 || '''39.17''' || '''68.41''' || 75.0 seasons<br />
|-<br />
| 0073 || [[Simonton]] || PF/DC || 99.95 || 88.02 || 92.08 || '''93.35''' || '''70.34''' || 63.02 || 79.78 || '''71.40''' || 34.01 || 40.56 || 41.05 || '''38.54''' || '''68.41''' || 75.0 seasons<br />
|-<br />
| 0074 || [[Simonton]] || PF/DC || 99.99 || 87.42 || 92.12 || '''93.18''' || '''68.73''' || 62.63 || 79.20 || '''70.91''' || 33.46 || 38.76 || 39.53 || '''37.25''' || '''67.52''' || 75.0 seasons<br />
|-<br />
| 0075 || [[Simonton]] || PF/DC || 99.98 || 87.05 || 91.08 || '''92.70''' || '''69.17''' || 62.68 || 80.06 || '''71.37''' || 34.59 || 40.23 || 40.72 || '''38.51''' || '''67.94''' || 75.0 seasons<br />
|-<br />
| 0076 || [[Simonton]] || PF/DC || 99.99 || 86.90 || 92.06 || '''92.99''' || '''70.13''' || 62.76 || 80.03 || '''71.40''' || 33.44 || 41.93 || 42.68 || '''39.35''' || '''68.47''' || 75.0 seasons<br />
|-<br />
| 0077 || [[Simonton]] || PF/DC || 99.98 || 86.60 || 91.84 || '''92.81''' || '''69.14''' || 62.55 || 79.25 || '''70.90''' || 33.34 || 40.77 || 41.81 || '''38.64''' || '''67.87''' || 75.0 seasons<br />
|-<br />
| 0078 || [[Simonton]] || PF/DC || 99.96 || 87.37 || 91.82 || '''93.05''' || '''69.68''' || 63.02 || 80.30 || '''71.66''' || 33.96 || 41.47 || 43.32 || '''39.58''' || '''68.49''' || 75.0 seasons<br />
|-<br />
| 0079 || [[Simonton]] || PF/DC || 99.96 || 87.66 || 92.62 || '''93.41''' || '''70.10''' || 65.94 || 81.85 || '''73.90''' || 34.38 || 40.75 || 42.97 || '''39.37''' || '''69.19''' || 75.0 seasons<br />
|-<br />
| 0080 || [[Simonton]] || PF/DC || 99.97 || 87.55 || 92.16 || '''93.23''' || '''70.04''' || 69.22 || 80.98 || '''75.10''' || 33.10 || 39.90 || 42.54 || '''38.51''' || '''69.22''' || 75.0 seasons<br />
|-<br />
| 0081 || [[Simonton]] || PF/DC || 99.98 || 87.37 || 91.78 || '''93.04''' || '''70.08''' || 69.40 || 81.99 || '''75.70''' || 35.65 || 41.95 || 42.91 || '''40.17''' || '''69.75''' || 75.0 seasons<br />
|-<br />
| 0082 || [[Simonton]] || PF/DC || 99.97 || 88.02 || 92.52 || '''93.50''' || '''69.83''' || 67.80 || 82.01 || '''74.90''' || 35.56 || 41.24 || 42.81 || '''39.87''' || '''69.53''' || 75.0 seasons<br />
|-<br />
| 82b || [[Simonton]] || PF/DC || 99.96 || 87.86 || 92.52 || '''93.44''' || '''70.30''' || 67.76 || 81.94 || '''74.85''' || 33.60 || 40.80 || 42.75 || '''39.05''' || '''69.41''' || 75.0 seasons<br />
|-<br />
| 82c || [[Simonton]] || PF/DC || 99.98 || 87.09 || 92.33 || '''93.13''' || '''71.30''' || 67.51 || 82.15 || '''74.83''' || 33.45 || 40.61 || 42.88 || '''38.98''' || '''69.56''' || 75.0 seasons<br />
|-<br />
| 0084 || [[Simonton]] || PF/DC || 99.92 || 87.32 || 92.39 || '''93.21''' || '''69.81''' || 67.46 || 82.08 || '''74.77''' || 34.36 || 41.55 || 42.37 || '''39.43''' || '''69.30''' || 75.0 seasons<br />
|-<br />
| 0085 || [[Simonton]] || PF/DC || 99.93 || 88.15 || 92.64 || '''93.57''' || '''70.06''' || 67.28 || 81.80 || '''74.54''' || 34.96 || 40.80 || 42.59 || '''39.45''' || '''69.41''' || 75.0 seasons<br />
|-<br />
| 0086 || [[Simonton]] || PF/DC || 99.89 || 87.55 || 92.36 || '''93.27''' || '''69.89''' || 67.07 || 81.95 || '''74.51''' || 33.36 || 41.08 || 42.12 || '''38.85''' || '''69.13''' || 75.0 seasons<br />
|-<br />
| 0087 || [[Simonton]] || PF/DC || 99.62 || 86.86 || 91.91 || '''92.80''' || '''69.29''' || 65.25 || 81.50 || '''73.37''' || 33.42 || 39.25 || 41.21 || '''37.96''' || '''68.35''' || 75.0 seasons<br />
|-<br />
| 0088 || [[Simonton]] || PF/DC || 99.83 || 87.78 || 92.50 || '''93.37''' || '''70.76''' || 67.08 || 82.42 || '''74.75''' || 32.76 || 41.34 || 42.13 || '''38.74''' || '''69.41''' || 327.0 seasons<br />
|-<br />
| 0089 || [[Simonton]] || PF/DC || 99.83 || 87.62 || 92.50 || '''93.31''' || '''70.49''' || 67.02 || 81.93 || '''74.48''' || 32.75 || 41.41 || 42.21 || '''38.79''' || '''69.27''' || 327.0 seasons<br />
|-<br />
| 0090 || [[Simonton]] || PF/DC || 99.80 || 87.37 || 92.58 || '''93.25''' || '''70.25''' || 67.03 || 82.14 || '''74.59''' || 32.80 || 41.13 || 41.96 || '''38.63''' || '''69.18''' || 327.0 seasons<br />
|-<br />
| 0091 || [[Simonton]] || PF/DC || 99.83 || 87.84 || 92.61 || '''93.43''' || '''70.74''' || 67.06 || 81.97 || '''74.52''' || 32.58 || 41.61 || 41.54 || '''38.58''' || '''69.32''' || 327.0 seasons<br />
|-<br />
| 0092 || [[Simonton]] || PF/DC || 99.82 || 87.61 || 92.66 || '''93.36''' || '''70.90''' || 67.00 || 81.90 || '''74.45''' || 32.52 || 41.21 || 41.62 || '''38.45''' || '''69.29''' || 327.0 seasons<br />
|-<br />
| 0095 || [[Simonton]] || PF/DC || 99.84 || 87.43 || 92.50 || '''93.26''' || '''70.80''' || 67.45 || 82.18 || '''74.82''' || 32.56 || 41.63 || 41.96 || '''38.72''' || '''69.40''' || 327.6 seasons<br />
|- <br />
| '''Bot Name''' || '''Author''' || '''Type''' || '''HOF''' || '''SPL''' || '''GRG''' || '''Sub 1''' || '''WAY (Sub 2)''' || '''GR3''' || '''RKM''' || '''Sub 3''' || '''ASC''' || '''CC''' || '''CHK''' || '''Sub 4''' || '''Total''' || '''Comments'''<br />
|- <br />
| [[DrussGT]] 1.1.4 || [[Skilgannon]] || WS-GT VCS || 99.70 || 87.77 || 92.74 || '''93.41''' || '''71.54''' || 71.51 || 81.64 || '''76.57''' || 43.10 || 49.21 || 47.69 || '''46.67''' || '''72.05''' || 100.0 seasons<br />
|- <br />
| [[Dookious]] 1.554 || [[Voidious]] || WS || 99,94 || 86,30 || 94,31 || '''93,52''' || '''69,07''' || 69,41 || 84,12 || '''76,76''' || 40,73 || 52,86 || 52,06 || '''48,55''' || '''71,97''' || 31 seasons <br />
|- <br />
| [[DrussGT]] w/ my "segments" || [[Skilgannon]] || WS-GT || 99.42 || 87.56 || 90.58 || '''92.52''' || '''65.73''' || 73.56 || 78.44 || '''76.00''' || 33.28 || 41.70 || 41.90 || '''38.96''' || '''68.30''' || 41.0 seasons<br />
|- <br />
| [[Firebird]] 0.1 || [[David Alves]] || DC WS || 99.88 || 87.01 || 86.72 || '''91.21''' || '''67.16''' || 64.53 || 77.10 || '''70.82''' || 30.02 || 42.54 || 42.16 || '''38.24''' || '''66.85''' || 100.0 seasons<br />
|}<br />
<br />
=== [[MovementChallenge2K7/Results|MC2K7 Results]] ===<br />
{| border=1 cellspacing=0<br />
|| '''Bot Name''' || '''Author''' || '''Type''' || '''HOF''' || '''SPL''' || '''GRG''' || '''Sub 1''' || '''WAY (Sub 2)''' || '''GR3''' || '''RKM''' || '''Sub 3''' || '''ASC''' || '''CC''' || '''CHK''' || '''Sub 4''' || '''Total''' || '''Comments'''<br />
|-<br />
|| 0057 || [[Simonton]] || PF/DC || 99.58 || 90.04 || 91.69 || '''93.77''' || '''72.55''' || 63.46 || 75.32 || '''69.39''' || 28.14 || 43.87 || 30.54 || '''34.18''' || '''67.47''' || 5.0 seasons<br />
|-<br />
|| 0058 || [[Simonton]] || PF/DC || 99.67 || 89.60 || 91.63 || '''93.63''' || '''73.33''' || 62.53 || 75.72 || '''69.13''' || 29.83 || 42.90 || 29.69 || '''34.14''' || '''67.56''' || 5.0 seasons<br />
|-<br />
|| 0059 || [[Simonton]] || PF/DC || 99.56 || 90.46 || 92.30 || '''94.11''' || '''73.40''' || 64.25 || 77.79 || '''71.02''' || 29.97 || 44.41 || 30.94 || '''35.11''' || '''68.41''' || 5.0 seasons<br />
|-<br />
|| 0061 || [[Simonton]] || PF/DC || 99.86 || 90.98 || 93.01 || '''94.61''' || '''75.32''' || 64.53 || 77.14 || '''70.84''' || 29.88 || 42.86 || 30.56 || '''34.43''' || '''68.80''' || 5.0 seasons<br />
|-<br />
|| 0062 || [[Simonton]] || PF/DC || 99.99 || 90.45 || 92.12 || '''94.19''' || '''74.25''' || 64.31 || 78.52 || '''71.41''' || 25.95 || 40.19 || 28.72 || '''31.62''' || '''67.87''' || 5.0 seasons<br />
|-<br />
|| 0063 || [[Simonton]] || PF/DC || 99.99 || 90.56 || 93.85 || '''94.80''' || '''75.04''' || 64.55 || 79.79 || '''72.17''' || 27.31 || 41.64 || 29.03 || '''32.66''' || '''68.67''' || 5.0 seasons<br />
|-<br />
|| 0064 || [[Simonton]] || PF/DC || 100.00 || 89.76 || 93.54 || '''94.43''' || '''74.98''' || 63.54 || 80.64 || '''72.09''' || 27.27 || 42.39 || 29.66 || '''33.11''' || '''68.65''' || 1.9 seasons<br />
|-<br />
| 0068 || [[Simonton]] || PF/DC || 99.98 || 89.41 || 94.20 || '''94.53''' || '''74.90''' || 64.79 || 82.13 || '''73.46''' || 29.51 || 45.83 || 33.12 || '''36.16''' || '''69.76''' || 5.0 seasons<br />
|-<br />
| 0069 || [[Simonton]] || PF/DC || 99.99 || 89.22 || 95.23 || '''94.81''' || '''73.19''' || 64.67 || 81.47 || '''73.07''' || 28.76 || 45.72 || 32.58 || '''35.69''' || '''69.19''' || 5.0 seasons<br />
|-<br />
| 0080 || [[Simonton]] || PF/DC || 99.98 || 90.49 || 96.99 || '''95.82''' || '''75.49''' || 70.00 || 86.15 || '''78.08''' || 28.51 || 43.80 || 32.91 || '''35.08''' || '''71.12''' || 5.0 seasons<br />
|-<br />
| 0082 || [[Simonton]] || PF/DC || 99.99 || 90.03 || 97.23 || '''95.75''' || '''75.81''' || 67.99 || 85.20 || '''76.60''' || 27.63 || 45.60 || 32.47 || '''35.24''' || '''70.85''' || 5.0 seasons<br />
|-<br />
| 0084 || [[Simonton]] || PF/DC || 100.00 || 90.66 || 97.21 || '''95.96''' || '''76.06''' || 68.01 || 85.46 || '''76.73''' || 27.38 || 45.29 || 32.79 || '''35.16''' || '''70.98''' || 5.0 seasons<br />
|-<br />
| 0085 || [[Simonton]] || PF/DC || 99.96 || 90.39 || 97.45 || '''95.94''' || '''75.76''' || 67.71 || 85.76 || '''76.73''' || 25.78 || 42.65 || 32.72 || '''33.72''' || '''70.54''' || 5.0 seasons<br />
|-<br />
| 0086 || [[Simonton]] || PF/DC || 99.97 || 90.34 || 97.47 || '''95.93''' || '''76.00''' || 67.23 || 85.51 || '''76.37''' || 28.07 || 43.36 || 32.72 || '''34.71''' || '''70.75''' || 5.0 seasons<br />
|-<br />
|| '''Bot Name''' || '''Author''' || '''Type''' || '''HOF''' || '''SPL''' || '''GRG''' || '''Sub 1''' || '''WAY (Sub 2)''' || '''GR3''' || '''RKM''' || '''Sub 3''' || '''ASC''' || '''CC''' || '''CHK''' || '''Sub 4''' || '''Total''' || '''Comments'''<br />
|-<br />
|| DrussGT 0.3.1 || [[Skilgannon]] || WS-GT || 99.87 || 89.16 || 96.42 || '''95.15''' || '''69.93''' || 66.81 || 86.20 || '''76.50''' || 24.34 || 52.48 || 37.66 || '''38.16''' || '''69.94''' || 1 season<br />
|-<br />
|| [[Dookious]] 1.554 || [[Voidious]] || WS/GF || 99.92 || 89.18 || 98.03 || '''95.71''' || '''72.86''' || 70.23 || 87.95 || '''79.09''' || 30.78 || 54.23 || 40.02 || '''41.67''' || '''72.33''' || 6 seasons<br />
|}<br />
<br />
=== Versions ===<br />
* '''0057:''' 0054 + Accelerates before pointing straight at its destination.<br />
* '''0058:''' Add 1% noise to wave dangers. I don't have high hopes for this, but am still very interested to see the results.<br />
* '''0059:''' 0057 + add back gunheat surfing when there are 0 or 1 other in-flight waves, except this time doing it correctly! (hopefully) Thanks for the tips, [[Rednaxela]]!<br />
* '''0060:''' Surf the gunheat wave no matter how many other waves are in-flight.<br />
* '''0061:''' Angle-based distancing (preferred 500), based off perpendicular from the line of the last destination to center of the next wave.<br />
* '''0062:''' Different danger calculation that accounts for closeness taking up more "bins".<br />
* '''0063:''' Add distance dimension.<br />
* '''0064:''' Add time-since-direction-change dimension.<br />
* '''0065:''' Switch the time-since to the almost-equivalent (but maybe importantly different) time-since-orientation-change.<br />
* '''0066:''' Use only lateral velocity dimension.<br />
* '''0067:''' Dimensions: Lateral velocity, forward wall distance, distance, time since orientation change<br />
* '''0068:''' Same dimensions as 67, but pieces the cluster together from smaller clusters using every combination of segments that include lateral velocity.<br />
* '''0069:''' Slightly different travel angle calculation, to (hopefully) smooth out the wall approach slightly. As a side effect, lessens the retreat angle when too close to the enemy (and increases attack angle when too far away).<br />
* '''0070:''' Bugfix to time-since-orientation change dimension (it was only working clockwise). 0067 + smoother angles of 0069.<br />
* '''0071:''' Add back splicing of smaller clusters from 0069.<br />
* '''0072:''' Using combinations of dimensions for weighting, instead of making separate clusters for each. An idea from [[Rednaxela]]<br />
* '''0073:''' Throw some more dimensions at it. Now: lateral velocity, retreating velocity, distance, forward wall distance, reverse wall distance, and time since orientation change.<br />
* '''0074:''' Use squared Euclidean distance between scans (formerly Manhattan).<br />
* '''0075:''' Add a time dimension (some kind of attempt at stat decay).<br />
* '''0076:''' Back to Manhattan scan distance.<br />
* '''0077:''' Promote forward & backward wall distance to be in every combination of dimensions (along with lateral velocity and time).<br />
* '''0078:''' A stab at dynamic weighting of dimensions. Back to only lat. vel. and time being included in every combination of dimensions.<br />
* '''0079:''' Bugfix in the travel angle calculation introduced in 0069 (and present since). Also accidentally changed the behavior when no waves are in the air (getting ahead of myself).<br />
* '''0080:''' My distancing code was not behaving as I thought all this time (since introduced in 0048). Now it works as I intended. Also changed be behavior when no waves are in the air, tweaked against [[GrubbmThree]].<br />
* '''0081:''' Vibrate instead of standing still, to get a boost in acceleration 1/2 the time.<br />
* '''0082:''' Reduce the retreat angle, to be 1/2 way between 0079 & 0080.<br />
* '''0083:''' 0082. No change. Just running it again to see how much difference there is in the scores after 75 seasons.<br />
* '''0084:''' Bugfix: starting in 0079 there was a bug that ruined precise prediction when there was enough time standing still to delay turning toward the next destination. I ''think'' the end result of this bug was to reduce escape angle in such a situation.<br />
* '''0085:''' Surf 41 points per wave, down from 61. This seems to be enough to put a decent gun on top with pretty few skipped turns :).<br />
* '''0086:''' Surf 31 points per wave.<br />
* '''0087:''' Surf 21 points per wave.<br />
* '''0088:''' Settle on 31 points per wave. Calculate travel angle based of the most recently fired enemy wave, instead of the one currently being surfed. ''Run on a normal CPU constant!!''<br />
* '''0089:''' Rolling depth for dynamic weighting: was it 5 or 20? (changed from 10)<br />
* '''0090:''' Rolling depth for dynamic weighting: was it 5 or 20?<br />
* '''0091:''' No dynamic weighting.<br />
* '''0095:''' Mostly refactoring. Also better handling of waves during collisions, and can no longer get "trapped" in the middle of the field by a rambot (by continually trying to orbit one direction only to find the other bot in the way).</div>Simontonhttp://robowiki.net/w/index.php?title=User:Simonton/PFResearch&diff=3202User:Simonton/PFResearch2008-10-05T05:58:11Z<p>Simonton: Sketchy details</p>
<hr />
<div>My next experiment: goto path surfing. <strike>It works by choosing (currently) 31 impact points on each wave, spread out across GF -1 to 1, then plotting the path through them with the least sum of the dangers.</strike> It currently works like this, which will become more sophisticated with time:<br />
* For each [[Wave]] choose 31 GuessFactors, spread out across GFs -1 to 1, being sure to include local minimum danger points.<br />
* To find the best path from a given point:<br />
** Find the next wave to strike that point.<br />
** Find the points on that wave that meet the 31 chosen GFs AND could be reached from this point along the path of maximum escape.<br />
** Recurse to find the danger of each of those points.<br />
** Choose the point with the least danger.<br />
** Add in the danger of this point, add this point to the best path so far, and return.<br />
So far there's very humble beginnings: <br />
<br />
See old results at [[/DCGTResearchArchive]]<br />
<br />
=== [[MovementChallenge2K7/ResultsFastLearning|MC2K7 Fast Learning Results]] ===<br />
{| border=1 cellspacing=0<br />
| '''Bot Name''' || '''Author''' || '''Type''' || '''HOF''' || '''SPL''' || '''GRG''' || '''Sub 1''' || '''WAY (Sub 2)''' || '''GR3''' || '''RKM''' || '''Sub 3''' || '''ASC''' || '''CC''' || '''CHK''' || '''Sub 4''' || '''Total''' || '''Comments'''<br />
|- <br />
| 0057 || [[Simonton]] || PF/DC || 99.56 || 88.14 || 86.88 || '''91.53''' || '''65.95''' || 62.77 || 75.40 || '''69.08''' || 34.95 || 42.30 || 40.09 || '''39.11''' || '''66.42''' || 75.0 seasons<br />
|- <br />
| 0058 || [[Simonton]] || PF/DC || 99.51 || 87.62 || 87.97 || '''91.70''' || '''64.39''' || 61.66 || 75.21 || '''68.44''' || 34.93 || 43.53 || 39.35 || '''39.27''' || '''65.95''' || 75.0 seasons<br />
|- <br />
| 0059 || [[Simonton]] || PF/DC || 99.53 || 88.25 || 87.34 || '''91.71''' || '''67.40''' || 63.42 || 76.11 || '''69.76''' || 35.03 || 42.28 || 40.35 || '''39.22''' || '''67.02''' || 75.0 seasons<br />
|- <br />
| 0060 || [[Simonton]] || PF/DC || 99.47 || 88.79 || 88.33 || '''92.20''' || '''67.67''' || 63.39 || 76.99 || '''70.19''' || 35.82 || 41.39 || 40.17 || '''39.13''' || '''67.30''' || 75.0 seasons<br />
|- <br />
| 0061 || [[Simonton]] || PF/DC || 99.80 || 88.45 || 89.72 || '''92.66''' || '''69.63''' || 63.29 || 76.61 || '''69.95''' || 34.52 || 41.29 || 41.34 || '''39.05''' || '''67.82''' || 75.0 seasons<br />
|- <br />
| 0062 || [[Simonton]] || PF/DC || 99.98 || 88.02 || 89.75 || '''92.59''' || '''68.40''' || 63.20 || 76.18 || '''69.69''' || 33.00 || 40.64 || 39.98 || '''37.88''' || '''67.14''' || 75.0 seasons<br />
|- <br />
| 0063 || [[Simonton]] || PF/DC || 99.97 || 88.59 || 89.93 || '''92.83''' || '''67.91''' || 63.30 || 77.67 || '''70.48''' || 33.43 || 40.42 || 40.10 || '''37.98''' || '''67.30''' || 75.0 seasons<br />
|- <br />
| 0064 || [[Simonton]] || PF/DC || 99.99 || 88.10 || 88.74 || '''92.28''' || '''68.93''' || 62.83 || 77.27 || '''70.05''' || 34.86 || 41.15 || 40.69 || '''38.90''' || '''67.54''' || 75.0 seasons<br />
|-<br />
| 0065 || [[Simonton]] || PF/DC || 99.96 || 87.89 || 88.98 || '''92.28''' || '''69.17''' || 62.83 || 77.79 || '''70.31''' || 34.00 || 42.49 || 41.87 || '''39.45''' || '''67.80''' || 75.0 seasons<br />
|-<br />
| 0066 || [[Simonton]] || PF/DC || 99.99 || 88.27 || 88.78 || '''92.34''' || '''69.28''' || 63.16 || 76.50 || '''69.83''' || 34.36 || 40.22 || 40.27 || '''38.28''' || '''67.43''' || 75.0 seasons<br />
|-<br />
| 0067 || [[Simonton]] || PF/DC || 99.98 || 88.00 || 89.35 || '''92.44''' || '''69.28''' || 63.19 || 78.40 || '''70.80''' || 34.96 || 41.76 || 42.00 || '''39.57''' || '''68.02''' || 75.0 seasons<br />
|-<br />
| 0068 || [[Simonton]] || PF/DC || 99.97 || 87.64 || 90.31 || '''92.64''' || '''68.70''' || 63.82 || 78.27 || '''71.04''' || 36.20 || 42.71 || 42.85 || '''40.59''' || '''68.24''' || 75.0 seasons<br />
|-<br />
| 0069 || [[Simonton]] || PF/DC || 99.96 || 87.72 || 91.49 || '''93.06''' || '''68.61''' || 63.41 || 79.12 || '''71.27''' || 33.84 || 41.48 || 43.23 || '''39.52''' || '''68.11''' || 75.0 seasons<br />
|-<br />
| 0070 || [[Simonton]] || PF/DC || 99.95 || 87.65 || 91.89 || '''93.17''' || '''70.09''' || 63.20 || 80.43 || '''71.82''' || 34.34 || 41.19 || 41.68 || '''39.07''' || '''68.53''' || 75.0 seasons<br />
|-<br />
| 0071 || [[Simonton]] || PF/DC || 99.98 || 87.82 || 92.07 || '''93.29''' || '''68.44''' || 63.15 || 80.22 || '''71.68''' || 33.99 || 41.64 || 42.41 || '''39.35''' || '''68.19''' || 75.0 seasons<br />
|-<br />
| 0072 || [[Simonton]] || PF/DC || 99.97 || 87.84 || 92.39 || '''93.40''' || '''69.47''' || 63.19 || 80.01 || '''71.60''' || 34.20 || 40.98 || 42.32 || '''39.17''' || '''68.41''' || 75.0 seasons<br />
|-<br />
| 0073 || [[Simonton]] || PF/DC || 99.95 || 88.02 || 92.08 || '''93.35''' || '''70.34''' || 63.02 || 79.78 || '''71.40''' || 34.01 || 40.56 || 41.05 || '''38.54''' || '''68.41''' || 75.0 seasons<br />
|-<br />
| 0074 || [[Simonton]] || PF/DC || 99.99 || 87.42 || 92.12 || '''93.18''' || '''68.73''' || 62.63 || 79.20 || '''70.91''' || 33.46 || 38.76 || 39.53 || '''37.25''' || '''67.52''' || 75.0 seasons<br />
|-<br />
| 0075 || [[Simonton]] || PF/DC || 99.98 || 87.05 || 91.08 || '''92.70''' || '''69.17''' || 62.68 || 80.06 || '''71.37''' || 34.59 || 40.23 || 40.72 || '''38.51''' || '''67.94''' || 75.0 seasons<br />
|-<br />
| 0076 || [[Simonton]] || PF/DC || 99.99 || 86.90 || 92.06 || '''92.99''' || '''70.13''' || 62.76 || 80.03 || '''71.40''' || 33.44 || 41.93 || 42.68 || '''39.35''' || '''68.47''' || 75.0 seasons<br />
|-<br />
| 0077 || [[Simonton]] || PF/DC || 99.98 || 86.60 || 91.84 || '''92.81''' || '''69.14''' || 62.55 || 79.25 || '''70.90''' || 33.34 || 40.77 || 41.81 || '''38.64''' || '''67.87''' || 75.0 seasons<br />
|-<br />
| 0078 || [[Simonton]] || PF/DC || 99.96 || 87.37 || 91.82 || '''93.05''' || '''69.68''' || 63.02 || 80.30 || '''71.66''' || 33.96 || 41.47 || 43.32 || '''39.58''' || '''68.49''' || 75.0 seasons<br />
|-<br />
| 0079 || [[Simonton]] || PF/DC || 99.96 || 87.66 || 92.62 || '''93.41''' || '''70.10''' || 65.94 || 81.85 || '''73.90''' || 34.38 || 40.75 || 42.97 || '''39.37''' || '''69.19''' || 75.0 seasons<br />
|-<br />
| 0080 || [[Simonton]] || PF/DC || 99.97 || 87.55 || 92.16 || '''93.23''' || '''70.04''' || 69.22 || 80.98 || '''75.10''' || 33.10 || 39.90 || 42.54 || '''38.51''' || '''69.22''' || 75.0 seasons<br />
|-<br />
| 0081 || [[Simonton]] || PF/DC || 99.98 || 87.37 || 91.78 || '''93.04''' || '''70.08''' || 69.40 || 81.99 || '''75.70''' || 35.65 || 41.95 || 42.91 || '''40.17''' || '''69.75''' || 75.0 seasons<br />
|-<br />
| 0082 || [[Simonton]] || PF/DC || 99.97 || 88.02 || 92.52 || '''93.50''' || '''69.83''' || 67.80 || 82.01 || '''74.90''' || 35.56 || 41.24 || 42.81 || '''39.87''' || '''69.53''' || 75.0 seasons<br />
|-<br />
| 82b || [[Simonton]] || PF/DC || 99.96 || 87.86 || 92.52 || '''93.44''' || '''70.30''' || 67.76 || 81.94 || '''74.85''' || 33.60 || 40.80 || 42.75 || '''39.05''' || '''69.41''' || 75.0 seasons<br />
|-<br />
| 82c || [[Simonton]] || PF/DC || 99.98 || 87.09 || 92.33 || '''93.13''' || '''71.30''' || 67.51 || 82.15 || '''74.83''' || 33.45 || 40.61 || 42.88 || '''38.98''' || '''69.56''' || 75.0 seasons<br />
|-<br />
| 0084 || [[Simonton]] || PF/DC || 99.92 || 87.32 || 92.39 || '''93.21''' || '''69.81''' || 67.46 || 82.08 || '''74.77''' || 34.36 || 41.55 || 42.37 || '''39.43''' || '''69.30''' || 75.0 seasons<br />
|-<br />
| 0085 || [[Simonton]] || PF/DC || 99.93 || 88.15 || 92.64 || '''93.57''' || '''70.06''' || 67.28 || 81.80 || '''74.54''' || 34.96 || 40.80 || 42.59 || '''39.45''' || '''69.41''' || 75.0 seasons<br />
|-<br />
| 0086 || [[Simonton]] || PF/DC || 99.89 || 87.55 || 92.36 || '''93.27''' || '''69.89''' || 67.07 || 81.95 || '''74.51''' || 33.36 || 41.08 || 42.12 || '''38.85''' || '''69.13''' || 75.0 seasons<br />
|-<br />
| 0087 || [[Simonton]] || PF/DC || 99.62 || 86.86 || 91.91 || '''92.80''' || '''69.29''' || 65.25 || 81.50 || '''73.37''' || 33.42 || 39.25 || 41.21 || '''37.96''' || '''68.35''' || 75.0 seasons<br />
|-<br />
| 0088 || [[Simonton]] || PF/DC || 99.83 || 87.78 || 92.50 || '''93.37''' || '''70.76''' || 67.08 || 82.42 || '''74.75''' || 32.76 || 41.34 || 42.13 || '''38.74''' || '''69.41''' || 327.0 seasons<br />
|-<br />
| 0089 || [[Simonton]] || PF/DC || 99.83 || 87.62 || 92.50 || '''93.31''' || '''70.49''' || 67.02 || 81.93 || '''74.48''' || 32.75 || 41.41 || 42.21 || '''38.79''' || '''69.27''' || 327.0 seasons<br />
|-<br />
| 0090 || [[Simonton]] || PF/DC || 99.80 || 87.37 || 92.58 || '''93.25''' || '''70.25''' || 67.03 || 82.14 || '''74.59''' || 32.80 || 41.13 || 41.96 || '''38.63''' || '''69.18''' || 327.0 seasons<br />
|-<br />
| 0091 || [[Simonton]] || PF/DC || 99.83 || 87.84 || 92.61 || '''93.43''' || '''70.74''' || 67.06 || 81.97 || '''74.52''' || 32.58 || 41.61 || 41.54 || '''38.58''' || '''69.32''' || 327.0 seasons<br />
|-<br />
| 0092 || [[Simonton]] || PF/DC || 99.82 || 87.61 || 92.66 || '''93.36''' || '''70.90''' || 67.00 || 81.90 || '''74.45''' || 32.52 || 41.21 || 41.62 || '''38.45''' || '''69.29''' || 327.0 seasons<br />
|-<br />
| 0095 || [[Simonton]] || PF/DC || 99.84 || 87.43 || 92.50 || '''93.26''' || '''70.80''' || 67.45 || 82.18 || '''74.82''' || 32.56 || 41.63 || 41.96 || '''38.72''' || '''69.40''' || 327.6 seasons<br />
|- <br />
| '''Bot Name''' || '''Author''' || '''Type''' || '''HOF''' || '''SPL''' || '''GRG''' || '''Sub 1''' || '''WAY (Sub 2)''' || '''GR3''' || '''RKM''' || '''Sub 3''' || '''ASC''' || '''CC''' || '''CHK''' || '''Sub 4''' || '''Total''' || '''Comments'''<br />
|- <br />
| [[DrussGT]] 1.1.4 || [[Skilgannon]] || WS-GT VCS || 99.70 || 87.77 || 92.74 || '''93.41''' || '''71.54''' || 71.51 || 81.64 || '''76.57''' || 43.10 || 49.21 || 47.69 || '''46.67''' || '''72.05''' || 100.0 seasons<br />
|- <br />
| [[Dookious]] 1.554 || [[Voidious]] || WS || 99,94 || 86,30 || 94,31 || '''93,52''' || '''69,07''' || 69,41 || 84,12 || '''76,76''' || 40,73 || 52,86 || 52,06 || '''48,55''' || '''71,97''' || 31 seasons <br />
|- <br />
| [[DrussGT]] w/ my "segments" || [[Skilgannon]] || WS-GT || 99.42 || 87.56 || 90.58 || '''92.52''' || '''65.73''' || 73.56 || 78.44 || '''76.00''' || 33.28 || 41.70 || 41.90 || '''38.96''' || '''68.30''' || 41.0 seasons<br />
|- <br />
| [[Firebird]] 0.1 || [[David Alves]] || DC WS || 99.88 || 87.01 || 86.72 || '''91.21''' || '''67.16''' || 64.53 || 77.10 || '''70.82''' || 30.02 || 42.54 || 42.16 || '''38.24''' || '''66.85''' || 100.0 seasons<br />
|}<br />
<br />
=== [[MovementChallenge2K7/Results|MC2K7 Results]] ===<br />
{| border=1 cellspacing=0<br />
|| '''Bot Name''' || '''Author''' || '''Type''' || '''HOF''' || '''SPL''' || '''GRG''' || '''Sub 1''' || '''WAY (Sub 2)''' || '''GR3''' || '''RKM''' || '''Sub 3''' || '''ASC''' || '''CC''' || '''CHK''' || '''Sub 4''' || '''Total''' || '''Comments'''<br />
|-<br />
|| 0057 || [[Simonton]] || PF/DC || 99.58 || 90.04 || 91.69 || '''93.77''' || '''72.55''' || 63.46 || 75.32 || '''69.39''' || 28.14 || 43.87 || 30.54 || '''34.18''' || '''67.47''' || 5.0 seasons<br />
|-<br />
|| 0058 || [[Simonton]] || PF/DC || 99.67 || 89.60 || 91.63 || '''93.63''' || '''73.33''' || 62.53 || 75.72 || '''69.13''' || 29.83 || 42.90 || 29.69 || '''34.14''' || '''67.56''' || 5.0 seasons<br />
|-<br />
|| 0059 || [[Simonton]] || PF/DC || 99.56 || 90.46 || 92.30 || '''94.11''' || '''73.40''' || 64.25 || 77.79 || '''71.02''' || 29.97 || 44.41 || 30.94 || '''35.11''' || '''68.41''' || 5.0 seasons<br />
|-<br />
|| 0061 || [[Simonton]] || PF/DC || 99.86 || 90.98 || 93.01 || '''94.61''' || '''75.32''' || 64.53 || 77.14 || '''70.84''' || 29.88 || 42.86 || 30.56 || '''34.43''' || '''68.80''' || 5.0 seasons<br />
|-<br />
|| 0062 || [[Simonton]] || PF/DC || 99.99 || 90.45 || 92.12 || '''94.19''' || '''74.25''' || 64.31 || 78.52 || '''71.41''' || 25.95 || 40.19 || 28.72 || '''31.62''' || '''67.87''' || 5.0 seasons<br />
|-<br />
|| 0063 || [[Simonton]] || PF/DC || 99.99 || 90.56 || 93.85 || '''94.80''' || '''75.04''' || 64.55 || 79.79 || '''72.17''' || 27.31 || 41.64 || 29.03 || '''32.66''' || '''68.67''' || 5.0 seasons<br />
|-<br />
|| 0064 || [[Simonton]] || PF/DC || 100.00 || 89.76 || 93.54 || '''94.43''' || '''74.98''' || 63.54 || 80.64 || '''72.09''' || 27.27 || 42.39 || 29.66 || '''33.11''' || '''68.65''' || 1.9 seasons<br />
|-<br />
| 0068 || [[Simonton]] || PF/DC || 99.98 || 89.41 || 94.20 || '''94.53''' || '''74.90''' || 64.79 || 82.13 || '''73.46''' || 29.51 || 45.83 || 33.12 || '''36.16''' || '''69.76''' || 5.0 seasons<br />
|-<br />
| 0069 || [[Simonton]] || PF/DC || 99.99 || 89.22 || 95.23 || '''94.81''' || '''73.19''' || 64.67 || 81.47 || '''73.07''' || 28.76 || 45.72 || 32.58 || '''35.69''' || '''69.19''' || 5.0 seasons<br />
|-<br />
| 0080 || [[Simonton]] || PF/DC || 99.98 || 90.49 || 96.99 || '''95.82''' || '''75.49''' || 70.00 || 86.15 || '''78.08''' || 28.51 || 43.80 || 32.91 || '''35.08''' || '''71.12''' || 5.0 seasons<br />
|-<br />
| 0082 || [[Simonton]] || PF/DC || 99.99 || 90.03 || 97.23 || '''95.75''' || '''75.81''' || 67.99 || 85.20 || '''76.60''' || 27.63 || 45.60 || 32.47 || '''35.24''' || '''70.85''' || 5.0 seasons<br />
|-<br />
| 0084 || [[Simonton]] || PF/DC || 100.00 || 90.66 || 97.21 || '''95.96''' || '''76.06''' || 68.01 || 85.46 || '''76.73''' || 27.38 || 45.29 || 32.79 || '''35.16''' || '''70.98''' || 5.0 seasons<br />
|-<br />
| 0085 || [[Simonton]] || PF/DC || 99.96 || 90.39 || 97.45 || '''95.94''' || '''75.76''' || 67.71 || 85.76 || '''76.73''' || 25.78 || 42.65 || 32.72 || '''33.72''' || '''70.54''' || 5.0 seasons<br />
|-<br />
| 0086 || [[Simonton]] || PF/DC || 99.97 || 90.34 || 97.47 || '''95.93''' || '''76.00''' || 67.23 || 85.51 || '''76.37''' || 28.07 || 43.36 || 32.72 || '''34.71''' || '''70.75''' || 5.0 seasons<br />
|-<br />
|| '''Bot Name''' || '''Author''' || '''Type''' || '''HOF''' || '''SPL''' || '''GRG''' || '''Sub 1''' || '''WAY (Sub 2)''' || '''GR3''' || '''RKM''' || '''Sub 3''' || '''ASC''' || '''CC''' || '''CHK''' || '''Sub 4''' || '''Total''' || '''Comments'''<br />
|-<br />
|| DrussGT 0.3.1 || [[Skilgannon]] || WS-GT || 99.87 || 89.16 || 96.42 || '''95.15''' || '''69.93''' || 66.81 || 86.20 || '''76.50''' || 24.34 || 52.48 || 37.66 || '''38.16''' || '''69.94''' || 1 season<br />
|-<br />
|| [[Dookious]] 1.554 || [[Voidious]] || WS/GF || 99.92 || 89.18 || 98.03 || '''95.71''' || '''72.86''' || 70.23 || 87.95 || '''79.09''' || 30.78 || 54.23 || 40.02 || '''41.67''' || '''72.33''' || 6 seasons<br />
|}<br />
<br />
=== Versions ===<br />
* '''0057:''' 0054 + Accelerates before pointing straight at its destination.<br />
* '''0058:''' Add 1% noise to wave dangers. I don't have high hopes for this, but am still very interested to see the results.<br />
* '''0059:''' 0057 + add back gunheat surfing when there are 0 or 1 other in-flight waves, except this time doing it correctly! (hopefully) Thanks for the tips, [[Rednaxela]]!<br />
* '''0060:''' Surf the gunheat wave no matter how many other waves are in-flight.<br />
* '''0061:''' Angle-based distancing (preferred 500), based off perpendicular from the line of the last destination to center of the next wave.<br />
* '''0062:''' Different danger calculation that accounts for closeness taking up more "bins".<br />
* '''0063:''' Add distance dimension.<br />
* '''0064:''' Add time-since-direction-change dimension.<br />
* '''0065:''' Switch the time-since to the almost-equivalent (but maybe importantly different) time-since-orientation-change.<br />
* '''0066:''' Use only lateral velocity dimension.<br />
* '''0067:''' Dimensions: Lateral velocity, forward wall distance, distance, time since orientation change<br />
* '''0068:''' Same dimensions as 67, but pieces the cluster together from smaller clusters using every combination of segments that include lateral velocity.<br />
* '''0069:''' Slightly different travel angle calculation, to (hopefully) smooth out the wall approach slightly. As a side effect, lessens the retreat angle when too close to the enemy (and increases attack angle when too far away).<br />
* '''0070:''' Bugfix to time-since-orientation change dimension (it was only working clockwise). 0067 + smoother angles of 0069.<br />
* '''0071:''' Add back splicing of smaller clusters from 0069.<br />
* '''0072:''' Using combinations of dimensions for weighting, instead of making separate clusters for each. An idea from [[Rednaxela]]<br />
* '''0073:''' Throw some more dimensions at it. Now: lateral velocity, retreating velocity, distance, forward wall distance, reverse wall distance, and time since orientation change.<br />
* '''0074:''' Use squared Euclidean distance between scans (formerly Manhattan).<br />
* '''0075:''' Add a time dimension (some kind of attempt at stat decay).<br />
* '''0076:''' Back to Manhattan scan distance.<br />
* '''0077:''' Promote forward & backward wall distance to be in every combination of dimensions (along with lateral velocity and time).<br />
* '''0078:''' A stab at dynamic weighting of dimensions. Back to only lat. vel. and time being included in every combination of dimensions.<br />
* '''0079:''' Bugfix in the travel angle calculation introduced in 0069 (and present since). Also accidentally changed the behavior when no waves are in the air (getting ahead of myself).<br />
* '''0080:''' My distancing code was not behaving as I thought all this time (since introduced in 0048). Now it works as I intended. Also changed be behavior when no waves are in the air, tweaked against [[GrubbmThree]].<br />
* '''0081:''' Vibrate instead of standing still, to get a boost in acceleration 1/2 the time.<br />
* '''0082:''' Reduce the retreat angle, to be 1/2 way between 0079 & 0080.<br />
* '''0083:''' 0082. No change. Just running it again to see how much difference there is in the scores after 75 seasons.<br />
* '''0084:''' Bugfix: starting in 0079 there was a bug that ruined precise prediction when there was enough time standing still to delay turning toward the next destination. I ''think'' the end result of this bug was to reduce escape angle in such a situation.<br />
* '''0085:''' Surf 41 points per wave, down from 61. This seems to be enough to put a decent gun on top with pretty few skipped turns :).<br />
* '''0086:''' Surf 31 points per wave.<br />
* '''0087:''' Surf 21 points per wave.<br />
* '''0088:''' Settle on 31 points per wave. Calculate travel angle based of the most recently fired enemy wave, instead of the one currently being surfed. ''Run on a normal CPU constant!!''<br />
* '''0089:''' Rolling depth for dynamic weighting: was it 5 or 20? (changed from 10)<br />
* '''0090:''' Rolling depth for dynamic weighting: was it 5 or 20?<br />
* '''0091:''' No dynamic weighting.<br />
* '''0092:''' Mostly refactoring, but a couple small "improvements" (more details when I have my notes).</div>Simontonhttp://robowiki.net/w/index.php?title=User:Simonton/PFResearch&diff=3201User:Simonton/PFResearch2008-10-05T05:54:29Z<p>Simonton: Some scores</p>
<hr />
<div>My next experiment: goto path surfing. <strike>It works by choosing (currently) 31 impact points on each wave, spread out across GF -1 to 1, then plotting the path through them with the least sum of the dangers.</strike> It currently works like this, which will become more sophisticated with time:<br />
* For each [[Wave]] choose 31 GuessFactors, spread out across GFs -1 to 1, being sure to include local minimum danger points.<br />
* To find the best path from a given point:<br />
** Find the next wave to strike that point.<br />
** Find the points on that wave that meet the 31 chosen GFs AND could be reached from this point along the path of maximum escape.<br />
** Recurse to find the danger of each of those points.<br />
** Choose the point with the least danger.<br />
** Add in the danger of this point, add this point to the best path so far, and return.<br />
So far there's very humble beginnings: <br />
<br />
See old results at [[/DCGTResearchArchive]]<br />
<br />
=== [[MovementChallenge2K7/ResultsFastLearning|MC2K7 Fast Learning Results]] ===<br />
{| border=1 cellspacing=0<br />
| '''Bot Name''' || '''Author''' || '''Type''' || '''HOF''' || '''SPL''' || '''GRG''' || '''Sub 1''' || '''WAY (Sub 2)''' || '''GR3''' || '''RKM''' || '''Sub 3''' || '''ASC''' || '''CC''' || '''CHK''' || '''Sub 4''' || '''Total''' || '''Comments'''<br />
|- <br />
| 0057 || [[Simonton]] || PF/DC || 99.56 || 88.14 || 86.88 || '''91.53''' || '''65.95''' || 62.77 || 75.40 || '''69.08''' || 34.95 || 42.30 || 40.09 || '''39.11''' || '''66.42''' || 75.0 seasons<br />
|- <br />
| 0058 || [[Simonton]] || PF/DC || 99.51 || 87.62 || 87.97 || '''91.70''' || '''64.39''' || 61.66 || 75.21 || '''68.44''' || 34.93 || 43.53 || 39.35 || '''39.27''' || '''65.95''' || 75.0 seasons<br />
|- <br />
| 0059 || [[Simonton]] || PF/DC || 99.53 || 88.25 || 87.34 || '''91.71''' || '''67.40''' || 63.42 || 76.11 || '''69.76''' || 35.03 || 42.28 || 40.35 || '''39.22''' || '''67.02''' || 75.0 seasons<br />
|- <br />
| 0060 || [[Simonton]] || PF/DC || 99.47 || 88.79 || 88.33 || '''92.20''' || '''67.67''' || 63.39 || 76.99 || '''70.19''' || 35.82 || 41.39 || 40.17 || '''39.13''' || '''67.30''' || 75.0 seasons<br />
|- <br />
| 0061 || [[Simonton]] || PF/DC || 99.80 || 88.45 || 89.72 || '''92.66''' || '''69.63''' || 63.29 || 76.61 || '''69.95''' || 34.52 || 41.29 || 41.34 || '''39.05''' || '''67.82''' || 75.0 seasons<br />
|- <br />
| 0062 || [[Simonton]] || PF/DC || 99.98 || 88.02 || 89.75 || '''92.59''' || '''68.40''' || 63.20 || 76.18 || '''69.69''' || 33.00 || 40.64 || 39.98 || '''37.88''' || '''67.14''' || 75.0 seasons<br />
|- <br />
| 0063 || [[Simonton]] || PF/DC || 99.97 || 88.59 || 89.93 || '''92.83''' || '''67.91''' || 63.30 || 77.67 || '''70.48''' || 33.43 || 40.42 || 40.10 || '''37.98''' || '''67.30''' || 75.0 seasons<br />
|- <br />
| 0064 || [[Simonton]] || PF/DC || 99.99 || 88.10 || 88.74 || '''92.28''' || '''68.93''' || 62.83 || 77.27 || '''70.05''' || 34.86 || 41.15 || 40.69 || '''38.90''' || '''67.54''' || 75.0 seasons<br />
|-<br />
| 0065 || [[Simonton]] || PF/DC || 99.96 || 87.89 || 88.98 || '''92.28''' || '''69.17''' || 62.83 || 77.79 || '''70.31''' || 34.00 || 42.49 || 41.87 || '''39.45''' || '''67.80''' || 75.0 seasons<br />
|-<br />
| 0066 || [[Simonton]] || PF/DC || 99.99 || 88.27 || 88.78 || '''92.34''' || '''69.28''' || 63.16 || 76.50 || '''69.83''' || 34.36 || 40.22 || 40.27 || '''38.28''' || '''67.43''' || 75.0 seasons<br />
|-<br />
| 0067 || [[Simonton]] || PF/DC || 99.98 || 88.00 || 89.35 || '''92.44''' || '''69.28''' || 63.19 || 78.40 || '''70.80''' || 34.96 || 41.76 || 42.00 || '''39.57''' || '''68.02''' || 75.0 seasons<br />
|-<br />
| 0068 || [[Simonton]] || PF/DC || 99.97 || 87.64 || 90.31 || '''92.64''' || '''68.70''' || 63.82 || 78.27 || '''71.04''' || 36.20 || 42.71 || 42.85 || '''40.59''' || '''68.24''' || 75.0 seasons<br />
|-<br />
| 0069 || [[Simonton]] || PF/DC || 99.96 || 87.72 || 91.49 || '''93.06''' || '''68.61''' || 63.41 || 79.12 || '''71.27''' || 33.84 || 41.48 || 43.23 || '''39.52''' || '''68.11''' || 75.0 seasons<br />
|-<br />
| 0070 || [[Simonton]] || PF/DC || 99.95 || 87.65 || 91.89 || '''93.17''' || '''70.09''' || 63.20 || 80.43 || '''71.82''' || 34.34 || 41.19 || 41.68 || '''39.07''' || '''68.53''' || 75.0 seasons<br />
|-<br />
| 0071 || [[Simonton]] || PF/DC || 99.98 || 87.82 || 92.07 || '''93.29''' || '''68.44''' || 63.15 || 80.22 || '''71.68''' || 33.99 || 41.64 || 42.41 || '''39.35''' || '''68.19''' || 75.0 seasons<br />
|-<br />
| 0072 || [[Simonton]] || PF/DC || 99.97 || 87.84 || 92.39 || '''93.40''' || '''69.47''' || 63.19 || 80.01 || '''71.60''' || 34.20 || 40.98 || 42.32 || '''39.17''' || '''68.41''' || 75.0 seasons<br />
|-<br />
| 0073 || [[Simonton]] || PF/DC || 99.95 || 88.02 || 92.08 || '''93.35''' || '''70.34''' || 63.02 || 79.78 || '''71.40''' || 34.01 || 40.56 || 41.05 || '''38.54''' || '''68.41''' || 75.0 seasons<br />
|-<br />
| 0074 || [[Simonton]] || PF/DC || 99.99 || 87.42 || 92.12 || '''93.18''' || '''68.73''' || 62.63 || 79.20 || '''70.91''' || 33.46 || 38.76 || 39.53 || '''37.25''' || '''67.52''' || 75.0 seasons<br />
|-<br />
| 0075 || [[Simonton]] || PF/DC || 99.98 || 87.05 || 91.08 || '''92.70''' || '''69.17''' || 62.68 || 80.06 || '''71.37''' || 34.59 || 40.23 || 40.72 || '''38.51''' || '''67.94''' || 75.0 seasons<br />
|-<br />
| 0076 || [[Simonton]] || PF/DC || 99.99 || 86.90 || 92.06 || '''92.99''' || '''70.13''' || 62.76 || 80.03 || '''71.40''' || 33.44 || 41.93 || 42.68 || '''39.35''' || '''68.47''' || 75.0 seasons<br />
|-<br />
| 0077 || [[Simonton]] || PF/DC || 99.98 || 86.60 || 91.84 || '''92.81''' || '''69.14''' || 62.55 || 79.25 || '''70.90''' || 33.34 || 40.77 || 41.81 || '''38.64''' || '''67.87''' || 75.0 seasons<br />
|-<br />
| 0078 || [[Simonton]] || PF/DC || 99.96 || 87.37 || 91.82 || '''93.05''' || '''69.68''' || 63.02 || 80.30 || '''71.66''' || 33.96 || 41.47 || 43.32 || '''39.58''' || '''68.49''' || 75.0 seasons<br />
|-<br />
| 0079 || [[Simonton]] || PF/DC || 99.96 || 87.66 || 92.62 || '''93.41''' || '''70.10''' || 65.94 || 81.85 || '''73.90''' || 34.38 || 40.75 || 42.97 || '''39.37''' || '''69.19''' || 75.0 seasons<br />
|-<br />
| 0080 || [[Simonton]] || PF/DC || 99.97 || 87.55 || 92.16 || '''93.23''' || '''70.04''' || 69.22 || 80.98 || '''75.10''' || 33.10 || 39.90 || 42.54 || '''38.51''' || '''69.22''' || 75.0 seasons<br />
|-<br />
| 0081 || [[Simonton]] || PF/DC || 99.98 || 87.37 || 91.78 || '''93.04''' || '''70.08''' || 69.40 || 81.99 || '''75.70''' || 35.65 || 41.95 || 42.91 || '''40.17''' || '''69.75''' || 75.0 seasons<br />
|-<br />
| 0082 || [[Simonton]] || PF/DC || 99.97 || 88.02 || 92.52 || '''93.50''' || '''69.83''' || 67.80 || 82.01 || '''74.90''' || 35.56 || 41.24 || 42.81 || '''39.87''' || '''69.53''' || 75.0 seasons<br />
|-<br />
| 82b || [[Simonton]] || PF/DC || 99.96 || 87.86 || 92.52 || '''93.44''' || '''70.30''' || 67.76 || 81.94 || '''74.85''' || 33.60 || 40.80 || 42.75 || '''39.05''' || '''69.41''' || 75.0 seasons<br />
|-<br />
| 82c || [[Simonton]] || PF/DC || 99.98 || 87.09 || 92.33 || '''93.13''' || '''71.30''' || 67.51 || 82.15 || '''74.83''' || 33.45 || 40.61 || 42.88 || '''38.98''' || '''69.56''' || 75.0 seasons<br />
|-<br />
| 0084 || [[Simonton]] || PF/DC || 99.92 || 87.32 || 92.39 || '''93.21''' || '''69.81''' || 67.46 || 82.08 || '''74.77''' || 34.36 || 41.55 || 42.37 || '''39.43''' || '''69.30''' || 75.0 seasons<br />
|-<br />
| 0085 || [[Simonton]] || PF/DC || 99.93 || 88.15 || 92.64 || '''93.57''' || '''70.06''' || 67.28 || 81.80 || '''74.54''' || 34.96 || 40.80 || 42.59 || '''39.45''' || '''69.41''' || 75.0 seasons<br />
|-<br />
| 0086 || [[Simonton]] || PF/DC || 99.89 || 87.55 || 92.36 || '''93.27''' || '''69.89''' || 67.07 || 81.95 || '''74.51''' || 33.36 || 41.08 || 42.12 || '''38.85''' || '''69.13''' || 75.0 seasons<br />
|-<br />
| 0087 || [[Simonton]] || PF/DC || 99.62 || 86.86 || 91.91 || '''92.80''' || '''69.29''' || 65.25 || 81.50 || '''73.37''' || 33.42 || 39.25 || 41.21 || '''37.96''' || '''68.35''' || 75.0 seasons<br />
|-<br />
| 0088 || [[Simonton]] || PF/DC || 99.83 || 87.78 || 92.50 || '''93.37''' || '''70.76''' || 67.08 || 82.42 || '''74.75''' || 32.76 || 41.34 || 42.13 || '''38.74''' || '''69.41''' || 327.0 seasons<br />
|-<br />
| 0089 || [[Simonton]] || PF/DC || 99.83 || 87.62 || 92.50 || '''93.31''' || '''70.49''' || 67.02 || 81.93 || '''74.48''' || 32.75 || 41.41 || 42.21 || '''38.79''' || '''69.27''' || 327.0 seasons<br />
|-<br />
| 0090 || [[Simonton]] || PF/DC || 99.80 || 87.37 || 92.58 || '''93.25''' || '''70.25''' || 67.03 || 82.14 || '''74.59''' || 32.80 || 41.13 || 41.96 || '''38.63''' || '''69.18''' || 327.0 seasons<br />
|-<br />
| 0091 || [[Simonton]] || PF/DC || 99.83 || 87.84 || 92.61 || '''93.43''' || '''70.74''' || 67.06 || 81.97 || '''74.52''' || 32.58 || 41.61 || 41.54 || '''38.58''' || '''69.32''' || 327.0 seasons<br />
|-<br />
| 0092 || [[Simonton]] || PF/DC || 99.82 || 87.61 || 92.66 || '''93.36''' || '''70.90''' || 67.00 || 81.90 || '''74.45''' || 32.52 || 41.21 || 41.62 || '''38.45''' || '''69.29''' || 327.0 seasons<br />
|-<br />
| 0095 || [[Simonton]] || PF/DC || 99.84 || 87.43 || 92.50 || '''93.26''' || '''70.80''' || 67.45 || 82.18 || '''74.82''' || 32.56 || 41.63 || 41.96 || '''38.72''' || '''69.40''' || 327.6 seasons<br />
|- <br />
| '''Bot Name''' || '''Author''' || '''Type''' || '''HOF''' || '''SPL''' || '''GRG''' || '''Sub 1''' || '''WAY (Sub 2)''' || '''GR3''' || '''RKM''' || '''Sub 3''' || '''ASC''' || '''CC''' || '''CHK''' || '''Sub 4''' || '''Total''' || '''Comments'''<br />
|- <br />
| [[DrussGT]] 1.1.4 || [[Skilgannon]] || WS-GT VCS || 99.70 || 87.77 || 92.74 || '''93.41''' || '''71.54''' || 71.51 || 81.64 || '''76.57''' || 43.10 || 49.21 || 47.69 || '''46.67''' || '''72.05''' || 100.0 seasons<br />
|- <br />
| [[Dookious]] 1.554 || [[Voidious]] || WS || 99,94 || 86,30 || 94,31 || '''93,52''' || '''69,07''' || 69,41 || 84,12 || '''76,76''' || 40,73 || 52,86 || 52,06 || '''48,55''' || '''71,97''' || 31 seasons <br />
|- <br />
| [[DrussGT]] w/ my "segments" || [[Skilgannon]] || WS-GT || 99.42 || 87.56 || 90.58 || '''92.52''' || '''65.73''' || 73.56 || 78.44 || '''76.00''' || 33.28 || 41.70 || 41.90 || '''38.96''' || '''68.30''' || 41.0 seasons<br />
|- <br />
| [[Firebird]] 0.1 || [[David Alves]] || DC WS || 99.88 || 87.01 || 86.72 || '''91.21''' || '''67.16''' || 64.53 || 77.10 || '''70.82''' || 30.02 || 42.54 || 42.16 || '''38.24''' || '''66.85''' || 100.0 seasons<br />
|}<br />
<br />
=== [[MovementChallenge2K7/Results|MC2K7 Results]] ===<br />
{| border=1 cellspacing=0<br />
|| '''Bot Name''' || '''Author''' || '''Type''' || '''HOF''' || '''SPL''' || '''GRG''' || '''Sub 1''' || '''WAY (Sub 2)''' || '''GR3''' || '''RKM''' || '''Sub 3''' || '''ASC''' || '''CC''' || '''CHK''' || '''Sub 4''' || '''Total''' || '''Comments'''<br />
|-<br />
|| 0057 || [[Simonton]] || PF/DC || 99.58 || 90.04 || 91.69 || '''93.77''' || '''72.55''' || 63.46 || 75.32 || '''69.39''' || 28.14 || 43.87 || 30.54 || '''34.18''' || '''67.47''' || 5.0 seasons<br />
|-<br />
|| 0058 || [[Simonton]] || PF/DC || 99.67 || 89.60 || 91.63 || '''93.63''' || '''73.33''' || 62.53 || 75.72 || '''69.13''' || 29.83 || 42.90 || 29.69 || '''34.14''' || '''67.56''' || 5.0 seasons<br />
|-<br />
|| 0059 || [[Simonton]] || PF/DC || 99.56 || 90.46 || 92.30 || '''94.11''' || '''73.40''' || 64.25 || 77.79 || '''71.02''' || 29.97 || 44.41 || 30.94 || '''35.11''' || '''68.41''' || 5.0 seasons<br />
|-<br />
|| 0061 || [[Simonton]] || PF/DC || 99.86 || 90.98 || 93.01 || '''94.61''' || '''75.32''' || 64.53 || 77.14 || '''70.84''' || 29.88 || 42.86 || 30.56 || '''34.43''' || '''68.80''' || 5.0 seasons<br />
|-<br />
|| 0062 || [[Simonton]] || PF/DC || 99.99 || 90.45 || 92.12 || '''94.19''' || '''74.25''' || 64.31 || 78.52 || '''71.41''' || 25.95 || 40.19 || 28.72 || '''31.62''' || '''67.87''' || 5.0 seasons<br />
|-<br />
|| 0063 || [[Simonton]] || PF/DC || 99.99 || 90.56 || 93.85 || '''94.80''' || '''75.04''' || 64.55 || 79.79 || '''72.17''' || 27.31 || 41.64 || 29.03 || '''32.66''' || '''68.67''' || 5.0 seasons<br />
|-<br />
|| 0064 || [[Simonton]] || PF/DC || 100.00 || 89.76 || 93.54 || '''94.43''' || '''74.98''' || 63.54 || 80.64 || '''72.09''' || 27.27 || 42.39 || 29.66 || '''33.11''' || '''68.65''' || 1.9 seasons<br />
|-<br />
| 0068 || [[Simonton]] || PF/DC || 99.98 || 89.41 || 94.20 || '''94.53''' || '''74.90''' || 64.79 || 82.13 || '''73.46''' || 29.51 || 45.83 || 33.12 || '''36.16''' || '''69.76''' || 5.0 seasons<br />
|-<br />
| 0069 || [[Simonton]] || PF/DC || 99.99 || 89.22 || 95.23 || '''94.81''' || '''73.19''' || 64.67 || 81.47 || '''73.07''' || 28.76 || 45.72 || 32.58 || '''35.69''' || '''69.19''' || 5.0 seasons<br />
|-<br />
| 0080 || [[Simonton]] || PF/DC || 99.98 || 90.49 || 96.99 || '''95.82''' || '''75.49''' || 70.00 || 86.15 || '''78.08''' || 28.51 || 43.80 || 32.91 || '''35.08''' || '''71.12''' || 5.0 seasons<br />
|-<br />
| 0082 || [[Simonton]] || PF/DC || 99.99 || 90.03 || 97.23 || '''95.75''' || '''75.81''' || 67.99 || 85.20 || '''76.60''' || 27.63 || 45.60 || 32.47 || '''35.24''' || '''70.85''' || 5.0 seasons<br />
|-<br />
| 0084 || [[Simonton]] || PF/DC || 100.00 || 90.66 || 97.21 || '''95.96''' || '''76.06''' || 68.01 || 85.46 || '''76.73''' || 27.38 || 45.29 || 32.79 || '''35.16''' || '''70.98''' || 5.0 seasons<br />
|-<br />
| 0085 || [[Simonton]] || PF/DC || 99.96 || 90.39 || 97.45 || '''95.94''' || '''75.76''' || 67.71 || 85.76 || '''76.73''' || 25.78 || 42.65 || 32.72 || '''33.72''' || '''70.54''' || 5.0 seasons<br />
|-<br />
| 0086 || [[Simonton]] || PF/DC || 99.97 || 90.34 || 97.47 || '''95.93''' || '''76.00''' || 67.23 || 85.51 || '''76.37''' || 28.07 || 43.36 || 32.72 || '''34.71''' || '''70.75''' || 5.0 seasons<br />
|-<br />
|| '''Bot Name''' || '''Author''' || '''Type''' || '''HOF''' || '''SPL''' || '''GRG''' || '''Sub 1''' || '''WAY (Sub 2)''' || '''GR3''' || '''RKM''' || '''Sub 3''' || '''ASC''' || '''CC''' || '''CHK''' || '''Sub 4''' || '''Total''' || '''Comments'''<br />
|-<br />
|| DrussGT 0.3.1 || [[Skilgannon]] || WS-GT || 99.87 || 89.16 || 96.42 || '''95.15''' || '''69.93''' || 66.81 || 86.20 || '''76.50''' || 24.34 || 52.48 || 37.66 || '''38.16''' || '''69.94''' || 1 season<br />
|-<br />
|| [[Dookious]] 1.554 || [[Voidious]] || WS/GF || 99.92 || 89.18 || 98.03 || '''95.71''' || '''72.86''' || 70.23 || 87.95 || '''79.09''' || 30.78 || 54.23 || 40.02 || '''41.67''' || '''72.33''' || 6 seasons<br />
|}<br />
<br />
=== Versions ===<br />
* '''0057:''' 0054 + Accelerates before pointing straight at its destination.<br />
* '''0058:''' Add 1% noise to wave dangers. I don't have high hopes for this, but am still very interested to see the results.<br />
* '''0059:''' 0057 + add back gunheat surfing when there are 0 or 1 other in-flight waves, except this time doing it correctly! (hopefully) Thanks for the tips, [[Rednaxela]]!<br />
* '''0060:''' Surf the gunheat wave no matter how many other waves are in-flight.<br />
* '''0061:''' Angle-based distancing (preferred 500), based off perpendicular from the line of the last destination to center of the next wave.<br />
* '''0062:''' Different danger calculation that accounts for closeness taking up more "bins".<br />
* '''0063:''' Add distance dimension.<br />
* '''0064:''' Add time-since-direction-change dimension.<br />
* '''0065:''' Switch the time-since to the almost-equivalent (but maybe importantly different) time-since-orientation-change.<br />
* '''0066:''' Use only lateral velocity dimension.<br />
* '''0067:''' Dimensions: Lateral velocity, forward wall distance, distance, time since orientation change<br />
* '''0068:''' Same dimensions as 67, but pieces the cluster together from smaller clusters using every combination of segments that include lateral velocity.<br />
* '''0069:''' Slightly different travel angle calculation, to (hopefully) smooth out the wall approach slightly. As a side effect, lessens the retreat angle when too close to the enemy (and increases attack angle when too far away).<br />
* '''0070:''' Bugfix to time-since-orientation change dimension (it was only working clockwise). 0067 + smoother angles of 0069.<br />
* '''0071:''' Add back splicing of smaller clusters from 0069.<br />
* '''0072:''' Using combinations of dimensions for weighting, instead of making separate clusters for each. An idea from [[Rednaxela]]<br />
* '''0073:''' Throw some more dimensions at it. Now: lateral velocity, retreating velocity, distance, forward wall distance, reverse wall distance, and time since orientation change.<br />
* '''0074:''' Use squared Euclidean distance between scans (formerly Manhattan).<br />
* '''0075:''' Add a time dimension (some kind of attempt at stat decay).<br />
* '''0076:''' Back to Manhattan scan distance.<br />
* '''0077:''' Promote forward & backward wall distance to be in every combination of dimensions (along with lateral velocity and time).<br />
* '''0078:''' A stab at dynamic weighting of dimensions. Back to only lat. vel. and time being included in every combination of dimensions.<br />
* '''0079:''' Bugfix in the travel angle calculation introduced in 0069 (and present since). Also accidentally changed the behavior when no waves are in the air (getting ahead of myself).<br />
* '''0080:''' My distancing code was not behaving as I thought all this time (since introduced in 0048). Now it works as I intended. Also changed be behavior when no waves are in the air, tweaked against [[GrubbmThree]].<br />
* '''0081:''' Vibrate instead of standing still, to get a boost in acceleration 1/2 the time.<br />
* '''0082:''' Reduce the retreat angle, to be 1/2 way between 0079 & 0080.<br />
* '''0083:''' 0082. No change. Just running it again to see how much difference there is in the scores after 75 seasons.<br />
* '''0084:''' Bugfix: starting in 0079 there was a bug that ruined precise prediction when there was enough time standing still to delay turning toward the next destination. I ''think'' the end result of this bug was to reduce escape angle in such a situation.<br />
* '''0085:''' Surf 41 points per wave, down from 61. This seems to be enough to put a decent gun on top with pretty few skipped turns :).<br />
* '''0086:''' Surf 31 points per wave.<br />
* '''0087:''' Surf 21 points per wave.<br />
* '''0088:''' Settle on 31 points per wave. Calculate travel angle based of the most recently fired enemy wave, instead of the one currently being surfed. ''Run on a normal CPU constant!!''</div>Simontonhttp://robowiki.net/w/index.php?title=Talk:RoboResearch/Development&diff=3199Talk:RoboResearch/Development2008-10-03T16:45:53Z<p>Simonton: Confidence Intervals</p>
<hr />
<div>== Showing Results ==<br />
<br />
I have already talked with some robocoders about how they would like to see results in the RoboResearch GUI. So far the best design I've come up with (merging ideas from [[Synapse]], [[Rednaxela]], [[Voidious]] and [[Chase-san]]) would open a separate window for each challenge+challenger. It would have a table that shows live-feed results like the summary on wiki pages. That window could be expanded to show a second table underneath the first, with the scores for each season. The top table could also be expanded to include a row for each version of the challenger in the database. Whichever version is selected in the top table is the one whose seasons would be displayed in the lower table. Can I get any feedback or new ideas? --[[User:Simonton|Simonton]] 05:35, 21 September 2008 (UTC)<br />
<br />
Well, apparently everyone either liked the idea or doesn't care enough to offer alternative input. The above idea has been implemented with a slight difference: the seasons are displayed in a separate window, at a button push. This means they do not change with as you select different version - instead you can open the seasons for each version in its own window. --[[User:Simonton|Simonton]] 15:29, 1 October 2008 (UTC)<br />
<br />
I would like to add some statistics to the results windows. Firstly I would like to highlight the top score among versions in the results table (or make it italic or underlined, or whatever). But to make that more useful I'd like to calculate the standard deviation of each score, then highlight any that are "close enough" to be tied for the top score. Then I'd like to do the same thing but only within those scores you select. I do it for my own benefit, but I hope candy like this makes you want to update RoboResearch and reap the benefits of my labor :). At some point I'll make a zip file and put it on sourceforge for everyone, so you don't have to deal with SVN. --[[User:Simonton|Simonton]] 15:38, 1 October 2008 (UTC)<br />
<br />
I'd be in the former group, I didn't see anything I didn't like =) Thanks for all this work you're putting into it. If I update will I lose all the season's I've already run? I'm not that familiar with the database system you're using... -- [[User:Skilgannon|Skilgannon]] 16:47, 1 October 2008 (UTC)<br />
<br />
You will not loose any data by updating. However I have lost data when closing down my database process before, so I recommend periodic backups of the database directory (and due to the way it works, I recommend not deleting a backup until you're sure a more recent one actually has all your data). If you had any scripts that you modified from those in SVN, they may get updated or deleted (run.bat and run.cfg come to mind). Note that SVN is not as up-to-date as the features listed on the wiki; I'm currently without internet at home, so I only get to commit on the weekends. While I'm posting again let me ask, does anyone have any pointers about how to calculate which scores are "close enough to be tied". I'm sure it's not hard, but I might as well ask for pointers instead of doing the statistics research myself :). --[[User:Simonton|Simonton]] 17:26, 1 October 2008 (UTC)<br />
<br />
* The scores are "close enough to be tied" if result1 +- margin_of_error1 and result2 +- margin_of_error2 overlap. The more they overlap the closer they are to tied, tied% = overlap/(2*min(margin_of_error1, margin_of_error2))*100 -- [[User:Skilgannon|Skilgannon]] 20:06, 1 October 2008 (UTC)<br />
* Makes sense, but how does one calculate "margin_of_error"? Some percentage of a standard deviation? If so, what precentage? And what about long-learning challenges where there really isn't enough data to get a good stardard deviation (e.g. at one season s.d. is zero)? --[[User:Simonton|Simonton]] 20:34, 1 October 2008 (UTC)<br />
* Once there are enough seasons run, I believe a number proportional to the standard deviations would make sense. If we assume the scores are roughly in a [http://en.wikipedia.org/wiki/Normal_distribution normal distribution], then once there is enough data for accurate calculation of standard deviation it's not hard to state criteria like "how wide is the region in which 90% of scores are expected to fall", in which case it would be 1.64485 standard deviations (see the table of confidence intervals [http://en.wikipedia.org/wiki/Normal_distribution#Standard_deviation_and_confidence_intervals here]). One very important factor however, is that as the number of seasons increases, the "margin of error" of the AVERAGE should decrease proportionally, therefore I believe the most statistically sound thing to use for a "margin_of_error" would be, something like "1.64485 standard deviations, divided by the number of seasons", or if we want a more stringent confidence interval of 95% or something, then 1.95996 instead of 1.64485, but either way, something of that form would be most statistically sound I believe. --[[User:Rednaxela|Rednaxela]] 22:27, 1 October 2008 (UTC)<br />
* '''Update:''' Actually I'll revise that. If [http://en.wikipedia.org/wiki/Confidence_interval#Confidence_intervals_in_measurement this] is correct, we should divide by the square root of the number of seasons, rather than the number of seasons. That will give error in the average score to whatever confidence interval we specify. --[[User:Rednaxela|Rednaxela]] 23:49, 1 October 2008 (UTC)<br />
* I've done my research on confidence intervals. The simplest explanation I found is [http://www.stat.psu.edu/~resources/ClassNotes/ljs_19/index.htm here]. Basically, we can assume the actual mean (given infinite battles) will be within <tt>t * stdDev / sqrt(numBattles)</tt>, where <tt>t</tt> is taken from a [http://www.union.edu/PUBLIC/BIODEPT/t.html t table] (<tt>numBattles - 1</tt> in the rows, <tt>1 - confidenceLevel</tt> in the columns). But I'm having trouble deciding how to use this information to answer the question, "Am I 95% confident that version A scores better than version B?" I'm not convinced the answer is the same as, "Are their confidence intervals disjoint?" Does anyone have (or can anyone find) any insight? --[[User:Simonton|Simonton]] 16:45, 3 October 2008 (UTC)<br />
<br />
Nice work on this lately! I just got Subclipse working again here and downloaded the latest version, however am having one problem: Trying to start the gui causes the following error:<br />
<code><pre>Exception in thread "main" java.sql.SQLException: socket creation error<br />
at org.hsqldb.jdbc.Util.sqlException(Unknown Source)<br />
at org.hsqldb.jdbc.jdbcConnection.<init>(Unknown Source)<br />
at org.hsqldb.jdbcDriver.getConnection(Unknown Source)<br />
at org.hsqldb.jdbcDriver.connect(Unknown Source)<br />
at java.sql.DriverManager.getConnection(DriverManager.java:620)<br />
at java.sql.DriverManager.getConnection(DriverManager.java:200)<br />
at roboResearch.engine.Database.<init>(Database.java:65)<br />
at roboResearch.GUI.<init>(GUI.java:44)<br />
at roboResearch.GUI.main(GUI.java:25)</pre></code>--[[User:Rednaxela|Rednaxela]] 18:22, 1 October 2008 (UTC)<br />
<br />
Now how is it you compliment the latest work when you can't even use it? ;) You need to run the database in a separate process (until I update SVN this weekend). I ''think'' that's your problem. Instructions for that are in ... umm ... I think it gives you the command to run if you try executing TUI with no command line args ... or invalid args ... or something like that. --[[User:Simonton|Simonton]] 18:33, 1 October 2008 (UTC)<br />
<br />
Ah nice, it work now. By the way, one issue I just noticed, is it doesn't like if very much when you browser for a bot outside of that robocode_bots directory ;) --[[User:Rednaxela|Rednaxela]] 18:41, 1 October 2008 (UTC)<br />
<br />
== Networking Proxies ==<br />
<br />
I know how to use raw TCP/IP streams to write the proxies required to implement a networked RoboResearch, but I'm not sure that's the "best" solution. I know how to use [http://www.springframework.org/ Spring] to make remote method calls, but it does not allow callbacks for things like listeners. Does anybody know of some other technology that would be appropriate to support the kind of remote communication necessary? I think I've heard [http://java.sun.com/javase/technologies/core/basic/rmi/index.jsp RMI] can do callbacks, so that might be one possibility. [http://java.sun.com/products/jms/ JMS] might be another. I'm just not familiar enough with any of these to know their strengths and limitations. Something that supports file transfer for uploading/downloading bots would be ideal. Any thoughts/recommendations/input? --[[User:Simonton|Simonton]] 16:38, 25 September 2008 (UTC)<br />
<br />
== Statistics ==<br />
<br />
I just had an idea for an 'automatic' mode for choosing battles, which is potentially both quicker and more accurate than just running lots of seasons. It involves running the bot that has the highest margin of error the most, and running the bots that have lower margins of errors for less seasons. Of course, several seasons will have to be run initially to determine which bots have higher margins of error. From here, after every battle the future opponents are sorted in order of margin of error (descending) and the bot at the top is run next. Thus, instead of specifying how many seasons should be run, one could specify the required margin of error. --[[User:Skilgannon|Skilgannon]] 11:58, 2 October 2008 (UTC)<br />
<br />
Sounds like a good way to do things, and would give a more accurate overall challenge score quicker, except one possible consideration is that the desired margin of error for every enemy isn't unnecessarily the same. For example, for a strong surfer, HOF scored tend to be in the 99.90+ range. For it, the necessary margin of error to tell the difference between versions, would be considerably smaller than the necessary margin of error for other bots. One thought I had, is that perhaps to set "goal" margins for each bot, should be done by comparing previous versions, looking at what the typical score difference between recent versions was. Or perhaps it would be better to only allow manual configuration of the margin of error for each bot? --[[User:Rednaxela|Rednaxela]] 13:39, 2 October 2008 (UTC)<br />
<br />
I think this is an excellent idea. As for specifying a different margin of error for each reference bot, I don't ever see myself using such a feature. For example against HoF I don't really care if I can score 99.99 instead of 99.95 - it's all the same to me. --[[User:Simonton|Simonton]] 19:17, 2 October 2008 (UTC)</div>Simontonhttp://robowiki.net/w/index.php?title=RoboResearch/Development&diff=3198RoboResearch/Development2008-10-03T14:39:30Z<p>Simonton: Slick</p>
<hr />
<div>This page will keep the current design for the next phase(s) of [[RoboResearch]]. I'll keep this page as the "official" design; please use the discussion page to offer feedback and contribute new ideas. This page exists to solicit such input, so please don't be bashful!<br />
<br />
=== The GUI ===<br />
[[Image:RoboResearch.JPG]]<br />
<br />
This is the current development GUI for RoboResearch. In the top section you add and orginize which challenges will be run. All the buttons should be obvious except "Group". When you select multiple challenges and press group, they all get the same number in front of them (that's the group number). An effort will be made to complete the battles for all challenges in the same group at about the same time. As challenges complete, they will drop to the bottom of the list and, if they were the last in their group, all others' group numbers will decrement.<br />
<br />
In the bottom section you control what each of your concurrent battle-running threads does. The "Prefer Group" spinner means that if the stated group exists in the pane above, it will run battles from that group. If it does not, it will default back to running from group 1. So, for example, I could add the rumble as group 1 in the top section (once that functionality is available), then set my threads to prefer 1 and 2 as pictured above. One thread would then always run the rumble, and the other thread would run from challenges I add until they are all done, at which time it would default back to running the rumble.<br />
<br />
There will be a "Configure" button in the top section, too, which for the rumble could set things like MAX_BATTLES. After all bots in the rumble have that many battles, RoboResearch would consider that entry "done". You could add 2 rumble entries, one with unlimited battles and one with a max, to achieve things like "first run all bots up to 2000 battles, then run my challenges, then go back to the rumble again".<br />
<br />
'''What Works:'''<br />
* Adding challenges<br />
* Removing challenges<br />
* Adding threads<br />
* Starting, pausing and killing threads<br />
* The "Prefer Group" feature<br />
* Dynamically updating results for any item in the battle queue<br />
* Bulk thread operations<br />
* Re-organizing the queue<br />
* A button to copy from the results table into wiki format<br />
* Adding/removing bots from the results window of a challenge<br />
* Seeing scores from each season of a challenge<br />
* The "tied-for-best" scores for each reference bot are highlighted in the results window (currently defined as within two standard deviations of each other)<br />
<br />
'''To-Do:'''<br />
* Editing challenges in the queue<br />
* Adding "the rumble" as an option for the queue<br />
* More results options (TBD, see [[Talk:RoboResearch/Development#Showing_Results]])<br />
<br />
=== Running Networked ===<br />
<br />
The RoboResearch clients (the GUI and TUI) now interact with 3 distinct entities to accomplish their task: a BattleQueue, ScoreHistory and BotRepository. These are 3 interfaces, with current implementations that can run within the same virtual machine. Some of them take listeners in their arguments, for example a ResultsListener (defined by another interface) that receives any updates submitted to the ScoreHistory for a given challenge. The greatest hurdle to running distributed across the internet is writing proxies for these interfaces that will pass the requests from one machine to the next. Once we have something like that we can almost immediately run networked, with further efforts required to make fair battle queue policies and automatic uploading/downloading of required bots. Then comes icing like the ability to specify "I want to prefer battles submitted by Simonton" (just as a random, hypothetical example).</div>Simontonhttp://robowiki.net/w/index.php?title=Talk:RoboResearch/Development&diff=3192Talk:RoboResearch/Development2008-10-02T19:17:37Z<p>Simonton: I like it.</p>
<hr />
<div>== Showing Results ==<br />
<br />
I have already talked with some robocoders about how they would like to see results in the RoboResearch GUI. So far the best design I've come up with (merging ideas from [[Synapse]], [[Rednaxela]], [[Voidious]] and [[Chase-san]]) would open a separate window for each challenge+challenger. It would have a table that shows live-feed results like the summary on wiki pages. That window could be expanded to show a second table underneath the first, with the scores for each season. The top table could also be expanded to include a row for each version of the challenger in the database. Whichever version is selected in the top table is the one whose seasons would be displayed in the lower table. Can I get any feedback or new ideas? --[[User:Simonton|Simonton]] 05:35, 21 September 2008 (UTC)<br />
<br />
Well, apparently everyone either liked the idea or doesn't care enough to offer alternative input. The above idea has been implemented with a slight difference: the seasons are displayed in a separate window, at a button push. This means they do not change with as you select different version - instead you can open the seasons for each version in its own window. --[[User:Simonton|Simonton]] 15:29, 1 October 2008 (UTC)<br />
<br />
I would like to add some statistics to the results windows. Firstly I would like to highlight the top score among versions in the results table (or make it italic or underlined, or whatever). But to make that more useful I'd like to calculate the standard deviation of each score, then highlight any that are "close enough" to be tied for the top score. Then I'd like to do the same thing but only within those scores you select. I do it for my own benefit, but I hope candy like this makes you want to update RoboResearch and reap the benefits of my labor :). At some point I'll make a zip file and put it on sourceforge for everyone, so you don't have to deal with SVN. --[[User:Simonton|Simonton]] 15:38, 1 October 2008 (UTC)<br />
<br />
I'd be in the former group, I didn't see anything I didn't like =) Thanks for all this work you're putting into it. If I update will I lose all the season's I've already run? I'm not that familiar with the database system you're using... -- [[User:Skilgannon|Skilgannon]] 16:47, 1 October 2008 (UTC)<br />
<br />
You will not loose any data by updating. However I have lost data when closing down my database process before, so I recommend periodic backups of the database directory (and due to the way it works, I recommend not deleting a backup until you're sure a more recent one actually has all your data). If you had any scripts that you modified from those in SVN, they may get updated or deleted (run.bat and run.cfg come to mind). Note that SVN is not as up-to-date as the features listed on the wiki; I'm currently without internet at home, so I only get to commit on the weekends. While I'm posting again let me ask, does anyone have any pointers about how to calculate which scores are "close enough to be tied". I'm sure it's not hard, but I might as well ask for pointers instead of doing the statistics research myself :). --[[User:Simonton|Simonton]] 17:26, 1 October 2008 (UTC)<br />
<br />
* The scores are "close enough to be tied" if result1 +- margin_of_error1 and result2 +- margin_of_error2 overlap. The more they overlap the closer they are to tied, tied% = overlap/(2*min(margin_of_error1, margin_of_error2))*100 -- [[User:Skilgannon|Skilgannon]] 20:06, 1 October 2008 (UTC)<br />
* Makes sense, but how does one calculate "margin_of_error"? Some percentage of a standard deviation? If so, what precentage? And what about long-learning challenges where there really isn't enough data to get a good stardard deviation (e.g. at one season s.d. is zero)? --[[User:Simonton|Simonton]] 20:34, 1 October 2008 (UTC)<br />
** Once there are enough seasons run, I believe a number proportional to the standard deviations would make sense. If we assume the scores are roughly in a [http://en.wikipedia.org/wiki/Normal_distribution normal distribution], then once there is enough data for accurate calculation of standard deviation it's not hard to state criteria like "how wide is the region in which 90% of scores are expected to fall", in which case it would be 1.64485 standard deviations (see the table of confidence intervals [http://en.wikipedia.org/wiki/Normal_distribution#Standard_deviation_and_confidence_intervals here]). One very important factor however, is that as the number of seasons increases, the "margin of error" of the AVERAGE should decrease proportionally, therefore I believe the most statistically sound thing to use for a "margin_of_error" would be, something like "1.64485 standard deviations, divided by the number of seasons", or if we want a more stringent confidence interval of 95% or something, then 1.95996 instead of 1.64485, but either way, something of that form would be most statistically sound I believe. --[[User:Rednaxela|Rednaxela]] 22:27, 1 October 2008 (UTC)<br />
** '''Update:''' Actually I'll revise that. If [http://en.wikipedia.org/wiki/Confidence_interval#Confidence_intervals_in_measurement this] is correct, we should divide by the square root of the number of seasons, rather than the number of seasons. That will give error in the average score to whatever confidence interval we specify. --[[User:Rednaxela|Rednaxela]] 23:49, 1 October 2008 (UTC)<br />
<br />
Nice work on this lately! I just got Subclipse working again here and downloaded the latest version, however am having one problem: Trying to start the gui causes the following error:<br />
<code><pre>Exception in thread "main" java.sql.SQLException: socket creation error<br />
at org.hsqldb.jdbc.Util.sqlException(Unknown Source)<br />
at org.hsqldb.jdbc.jdbcConnection.<init>(Unknown Source)<br />
at org.hsqldb.jdbcDriver.getConnection(Unknown Source)<br />
at org.hsqldb.jdbcDriver.connect(Unknown Source)<br />
at java.sql.DriverManager.getConnection(DriverManager.java:620)<br />
at java.sql.DriverManager.getConnection(DriverManager.java:200)<br />
at roboResearch.engine.Database.<init>(Database.java:65)<br />
at roboResearch.GUI.<init>(GUI.java:44)<br />
at roboResearch.GUI.main(GUI.java:25)</pre></code>--[[User:Rednaxela|Rednaxela]] 18:22, 1 October 2008 (UTC)<br />
<br />
Now how is it you compliment the latest work when you can't even use it? ;) You need to run the database in a separate process (until I update SVN this weekend). I ''think'' that's your problem. Instructions for that are in ... umm ... I think it gives you the command to run if you try executing TUI with no command line args ... or invalid args ... or something like that. --[[User:Simonton|Simonton]] 18:33, 1 October 2008 (UTC)<br />
<br />
Ah nice, it work now. By the way, one issue I just noticed, is it doesn't like if very much when you browser for a bot outside of that robocode_bots directory ;) --[[User:Rednaxela|Rednaxela]] 18:41, 1 October 2008 (UTC)<br />
<br />
== Networking Proxies ==<br />
<br />
I know how to use raw TCP/IP streams to write the proxies required to implement a networked RoboResearch, but I'm not sure that's the "best" solution. I know how to use [http://www.springframework.org/ Spring] to make remote method calls, but it does not allow callbacks for things like listeners. Does anybody know of some other technology that would be appropriate to support the kind of remote communication necessary? I think I've heard [http://java.sun.com/javase/technologies/core/basic/rmi/index.jsp RMI] can do callbacks, so that might be one possibility. [http://java.sun.com/products/jms/ JMS] might be another. I'm just not familiar enough with any of these to know their strengths and limitations. Something that supports file transfer for uploading/downloading bots would be ideal. Any thoughts/recommendations/input? --[[User:Simonton|Simonton]] 16:38, 25 September 2008 (UTC)<br />
<br />
== Statistics ==<br />
<br />
I just had an idea for an 'automatic' mode for choosing battles, which is potentially both quicker and more accurate than just running lots of seasons. It involves running the bot that has the highest margin of error the most, and running the bots that have lower margins of errors for less seasons. Of course, several seasons will have to be run initially to determine which bots have higher margins of error. From here, after every battle the future opponents are sorted in order of margin of error (descending) and the bot at the top is run next. Thus, instead of specifying how many seasons should be run, one could specify the required margin of error. --[[User:Skilgannon|Skilgannon]] 11:58, 2 October 2008 (UTC)<br />
<br />
Sounds like a good way to do things, and would give a more accurate overall challenge score quicker, except one possible consideration is that the desired margin of error for every enemy isn't unnecessarily the same. For example, for a strong surfer, HOF scored tend to be in the 99.90+ range. For it, the necessary margin of error to tell the difference between versions, would be considerably smaller than the necessary margin of error for other bots. One thought I had, is that perhaps to set "goal" margins for each bot, should be done by comparing previous versions, looking at what the typical score difference between recent versions was. Or perhaps it would be better to only allow manual configuration of the margin of error for each bot? --[[User:Rednaxela|Rednaxela]] 13:39, 2 October 2008 (UTC)<br />
<br />
I think this is an excellent idea. As for specifying a different margin of error for each reference bot, I don't ever see myself using such a feature. For example against HoF I don't really care if I can score 99.99 instead of 99.95 - it's all the same to me. --[[User:Simonton|Simonton]] 19:17, 2 October 2008 (UTC)</div>Simontonhttp://robowiki.net/w/index.php?title=Talk:RoboResearch/Development&diff=3184Talk:RoboResearch/Development2008-10-01T20:34:53Z<p>Simonton: Margin of Error</p>
<hr />
<div>== Showing Results ==<br />
<br />
I have already talked with some robocoders about how they would like to see results in the RoboResearch GUI. So far the best design I've come up with (merging ideas from [[Synapse]], [[Rednaxela]], [[Voidious]] and [[Chase-san]]) would open a separate window for each challenge+challenger. It would have a table that shows live-feed results like the summary on wiki pages. That window could be expanded to show a second table underneath the first, with the scores for each season. The top table could also be expanded to include a row for each version of the challenger in the database. Whichever version is selected in the top table is the one whose seasons would be displayed in the lower table. Can I get any feedback or new ideas? --[[User:Simonton|Simonton]] 05:35, 21 September 2008 (UTC)<br />
<br />
Well, apparently everyone either liked the idea or doesn't care enough to offer alternative input. The above idea has been implemented with a slight difference: the seasons are displayed in a separate window, at a button push. This means they do not change with as you select different version - instead you can open the seasons for each version in its own window. --[[User:Simonton|Simonton]] 15:29, 1 October 2008 (UTC)<br />
<br />
I would like to add some statistics to the results windows. Firstly I would like to highlight the top score among versions in the results table (or make it italic or underlined, or whatever). But to make that more useful I'd like to calculate the standard deviation of each score, then highlight any that are "close enough" to be tied for the top score. Then I'd like to do the same thing but only within those scores you select. I do it for my own benefit, but I hope candy like this makes you want to update RoboResearch and reap the benefits of my labor :). At some point I'll make a zip file and put it on sourceforge for everyone, so you don't have to deal with SVN. --[[User:Simonton|Simonton]] 15:38, 1 October 2008 (UTC)<br />
<br />
I'd be in the former group, I didn't see anything I didn't like =) Thanks for all this work you're putting into it. If I update will I lose all the season's I've already run? I'm not that familiar with the database system you're using... -- [[User:Skilgannon|Skilgannon]] 16:47, 1 October 2008 (UTC)<br />
<br />
You will not loose any data by updating. However I have lost data when closing down my database process before, so I recommend periodic backups of the database directory (and due to the way it works, I recommend not deleting a backup until you're sure a more recent one actually has all your data). If you had any scripts that you modified from those in SVN, they may get updated or deleted (run.bat and run.cfg come to mind). Note that SVN is not as up-to-date as the features listed on the wiki; I'm currently without internet at home, so I only get to commit on the weekends. While I'm posting again let me ask, does anyone have any pointers about how to calculate which scores are "close enough to be tied". I'm sure it's not hard, but I might as well ask for pointers instead of doing the statistics research myself :). --[[User:Simonton|Simonton]] 17:26, 1 October 2008 (UTC)<br />
<br />
* The scores are "close enough to be tied" if result1 +- margin_of_error1 and result2 +- margin_of_error2 overlap. The more they overlap the closer they are to tied, tied% = overlap/(2*min(margin_of_error1, margin_of_error2))*100 -- [[User:Skilgannon|Skilgannon]] 20:06, 1 October 2008 (UTC)<br />
* Makes sense, but how does one calculate "margin_of_error"? Some percentage of a standard deviation? If so, what precentage? And what about long-learning challenges where there really isn't enough data to get a good stardard deviation (e.g. at one season s.d. is zero)? --[[User:Simonton|Simonton]] 20:34, 1 October 2008 (UTC)<br />
<br />
Nice work on this lately! I just got Subclipse working again here and downloaded the latest version, however am having one problem: Trying to start the gui causes the following error:<br />
<code><pre>Exception in thread "main" java.sql.SQLException: socket creation error<br />
at org.hsqldb.jdbc.Util.sqlException(Unknown Source)<br />
at org.hsqldb.jdbc.jdbcConnection.<init>(Unknown Source)<br />
at org.hsqldb.jdbcDriver.getConnection(Unknown Source)<br />
at org.hsqldb.jdbcDriver.connect(Unknown Source)<br />
at java.sql.DriverManager.getConnection(DriverManager.java:620)<br />
at java.sql.DriverManager.getConnection(DriverManager.java:200)<br />
at roboResearch.engine.Database.<init>(Database.java:65)<br />
at roboResearch.GUI.<init>(GUI.java:44)<br />
at roboResearch.GUI.main(GUI.java:25)</pre></code>--[[User:Rednaxela|Rednaxela]] 18:22, 1 October 2008 (UTC)<br />
<br />
Now how is it you compliment the latest work when you can't even use it? ;) You need to run the database in a separate process (until I update SVN this weekend). I ''think'' that's your problem. Instructions for that are in ... umm ... I think it gives you the command to run if you try executing TUI with no command line args ... or invalid args ... or something like that. --[[User:Simonton|Simonton]] 18:33, 1 October 2008 (UTC)<br />
<br />
Ah nice, it work now. By the way, one issue I just noticed, is it doesn't like if very much when you browser for a bot outside of that robocode_bots directory ;) --[[User:Rednaxela|Rednaxela]] 18:41, 1 October 2008 (UTC)<br />
<br />
== Networking Proxies ==<br />
<br />
I know how to use raw TCP/IP streams to write the proxies required to implement a networked RoboResearch, but I'm not sure that's the "best" solution. I know how to use [http://www.springframework.org/ Spring] to make remote method calls, but it does not allow callbacks for things like listeners. Does anybody know of some other technology that would be appropriate to support the kind of remote communication necessary? I think I've heard [http://java.sun.com/javase/technologies/core/basic/rmi/index.jsp RMI] can do callbacks, so that might be one possibility. [http://java.sun.com/products/jms/ JMS] might be another. I'm just not familiar enough with any of these to know their strengths and limitations. Something that supports file transfer for uploading/downloading bots would be ideal. Any thoughts/recommendations/input? --[[User:Simonton|Simonton]] 16:38, 25 September 2008 (UTC)</div>Simontonhttp://robowiki.net/w/index.php?title=Talk:RoboResearch/Development&diff=3180Talk:RoboResearch/Development2008-10-01T18:33:17Z<p>Simonton: Separate Database Process</p>
<hr />
<div>== Showing Results ==<br />
<br />
I have already talked with some robocoders about how they would like to see results in the RoboResearch GUI. So far the best design I've come up with (merging ideas from [[Synapse]], [[Rednaxela]], [[Voidious]] and [[Chase-san]]) would open a separate window for each challenge+challenger. It would have a table that shows live-feed results like the summary on wiki pages. That window could be expanded to show a second table underneath the first, with the scores for each season. The top table could also be expanded to include a row for each version of the challenger in the database. Whichever version is selected in the top table is the one whose seasons would be displayed in the lower table. Can I get any feedback or new ideas? --[[User:Simonton|Simonton]] 05:35, 21 September 2008 (UTC)<br />
<br />
Well, apparently everyone either liked the idea or doesn't care enough to offer alternative input. The above idea has been implemented with a slight difference: the seasons are displayed in a separate window, at a button push. This means they do not change with as you select different version - instead you can open the seasons for each version in its own window. --[[User:Simonton|Simonton]] 15:29, 1 October 2008 (UTC)<br />
<br />
I would like to add some statistics to the results windows. Firstly I would like to highlight the top score among versions in the results table (or make it italic or underlined, or whatever). But to make that more useful I'd like to calculate the standard deviation of each score, then highlight any that are "close enough" to be tied for the top score. Then I'd like to do the same thing but only within those scores you select. I do it for my own benefit, but I hope candy like this makes you want to update RoboResearch and reap the benefits of my labor :). At some point I'll make a zip file and put it on sourceforge for everyone, so you don't have to deal with SVN. --[[User:Simonton|Simonton]] 15:38, 1 October 2008 (UTC)<br />
<br />
I'd be in the former group, I didn't see anything I didn't like =) Thanks for all this work you're putting into it. If I update will I lose all the season's I've already run? I'm not that familiar with the database system you're using... -- [[User:Skilgannon|Skilgannon]] 16:47, 1 October 2008 (UTC)<br />
<br />
You will not loose any data by updating. However I have lost data when closing down my database process before, so I recommend periodic backups of the database directory (and due to the way it works, I recommend not deleting a backup until you're sure a more recent one actually has all your data). If you had any scripts that you modified from those in SVN, they may get updated or deleted (run.bat and run.cfg come to mind). Note that SVN is not as up-to-date as the features listed on the wiki; I'm currently without internet at home, so I only get to commit on the weekends. While I'm posting again let me ask, does anyone have any pointers about how to calculate which scores are "close enough to be tied". I'm sure it's not hard, but I might as well ask for pointers instead of doing the statistics research myself :). --[[User:Simonton|Simonton]] 17:26, 1 October 2008 (UTC)<br />
<br />
Nice work on this lately! I just got Subclipse working again here and downloaded the latest version, however am having one problem: Trying to start the gui causes the following error:<br />
<code><pre>Exception in thread "main" java.sql.SQLException: socket creation error<br />
at org.hsqldb.jdbc.Util.sqlException(Unknown Source)<br />
at org.hsqldb.jdbc.jdbcConnection.<init>(Unknown Source)<br />
at org.hsqldb.jdbcDriver.getConnection(Unknown Source)<br />
at org.hsqldb.jdbcDriver.connect(Unknown Source)<br />
at java.sql.DriverManager.getConnection(DriverManager.java:620)<br />
at java.sql.DriverManager.getConnection(DriverManager.java:200)<br />
at roboResearch.engine.Database.<init>(Database.java:65)<br />
at roboResearch.GUI.<init>(GUI.java:44)<br />
at roboResearch.GUI.main(GUI.java:25)</pre></code>--[[User:Rednaxela|Rednaxela]] 18:22, 1 October 2008 (UTC)<br />
<br />
Now how is it you compliment the latest work when you can't even use it? ;) You need to run the database in a separate process (until I update SVN this weekend). I ''think'' that's your problem. Instructions for that are in ... umm ... I think it gives you the command to run if you try executing TUI with no command line args ... or invalid args ... or something like that. --[[User:Simonton|Simonton]] 18:33, 1 October 2008 (UTC)<br />
<br />
== Networking Proxies ==<br />
<br />
I know how to use raw TCP/IP streams to write the proxies required to implement a networked RoboResearch, but I'm not sure that's the "best" solution. I know how to use [http://www.springframework.org/ Spring] to make remote method calls, but it does not allow callbacks for things like listeners. Does anybody know of some other technology that would be appropriate to support the kind of remote communication necessary? I think I've heard [http://java.sun.com/javase/technologies/core/basic/rmi/index.jsp RMI] can do callbacks, so that might be one possibility. [http://java.sun.com/products/jms/ JMS] might be another. I'm just not familiar enough with any of these to know their strengths and limitations. Something that supports file transfer for uploading/downloading bots would be ideal. Any thoughts/recommendations/input? --[[User:Simonton|Simonton]] 16:38, 25 September 2008 (UTC)</div>Simontonhttp://robowiki.net/w/index.php?title=Talk:RoboResearch/Development&diff=3178Talk:RoboResearch/Development2008-10-01T17:26:20Z<p>Simonton: Data preservation</p>
<hr />
<div>== Showing Results ==<br />
<br />
I have already talked with some robocoders about how they would like to see results in the RoboResearch GUI. So far the best design I've come up with (merging ideas from [[Synapse]], [[Rednaxela]], [[Voidious]] and [[Chase-san]]) would open a separate window for each challenge+challenger. It would have a table that shows live-feed results like the summary on wiki pages. That window could be expanded to show a second table underneath the first, with the scores for each season. The top table could also be expanded to include a row for each version of the challenger in the database. Whichever version is selected in the top table is the one whose seasons would be displayed in the lower table. Can I get any feedback or new ideas? --[[User:Simonton|Simonton]] 05:35, 21 September 2008 (UTC)<br />
<br />
Well, apparently everyone either liked the idea or doesn't care enough to offer alternative input. The above idea has been implemented with a slight difference: the seasons are displayed in a separate window, at a button push. This means they do not change with as you select different version - instead you can open the seasons for each version in its own window. --[[User:Simonton|Simonton]] 15:29, 1 October 2008 (UTC)<br />
<br />
I would like to add some statistics to the results windows. Firstly I would like to highlight the top score among versions in the results table (or make it italic or underlined, or whatever). But to make that more useful I'd like to calculate the standard deviation of each score, then highlight any that are "close enough" to be tied for the top score. Then I'd like to do the same thing but only within those scores you select. I do it for my own benefit, but I hope candy like this makes you want to update RoboResearch and reap the benefits of my labor :). At some point I'll make a zip file and put it on sourceforge for everyone, so you don't have to deal with SVN. --[[User:Simonton|Simonton]] 15:38, 1 October 2008 (UTC)<br />
<br />
I'd be in the former group, I didn't see anything I didn't like =) Thanks for all this work you're putting into it. If I update will I lose all the season's I've already run? I'm not that familiar with the database system you're using... -- [[User:Skilgannon|Skilgannon]] 16:47, 1 October 2008 (UTC)<br />
<br />
You will not loose any data by updating. However I have lost data when closing down my database process before, so I recommend periodic backups of the database directory (and due to the way it works, I recommend not deleting a backup until you're sure a more recent one actually has all your data). If you had any scripts that you modified from those in SVN, they may get updated or deleted (run.bat and run.cfg come to mind). Note that SVN is not as up-to-date as the features listed on the wiki; I'm currently without internet at home, so I only get to commit on the weekends. While I'm posting again let me ask, does anyone have any pointers about how to calculate which scores are "close enough to be tied". I'm sure it's not hard, but I might as well ask for pointers instead of doing the statistics research myself :). --[[User:Simonton|Simonton]] 17:26, 1 October 2008 (UTC)<br />
<br />
== Networking Proxies ==<br />
<br />
I know how to use raw TCP/IP streams to write the proxies required to implement a networked RoboResearch, but I'm not sure that's the "best" solution. I know how to use [http://www.springframework.org/ Spring] to make remote method calls, but it does not allow callbacks for things like listeners. Does anybody know of some other technology that would be appropriate to support the kind of remote communication necessary? I think I've heard [http://java.sun.com/javase/technologies/core/basic/rmi/index.jsp RMI] can do callbacks, so that might be one possibility. [http://java.sun.com/products/jms/ JMS] might be another. I'm just not familiar enough with any of these to know their strengths and limitations. Something that supports file transfer for uploading/downloading bots would be ideal. Any thoughts/recommendations/input? --[[User:Simonton|Simonton]] 16:38, 25 September 2008 (UTC)</div>Simontonhttp://robowiki.net/w/index.php?title=Talk:RoboResearch/Development&diff=3176Talk:RoboResearch/Development2008-10-01T15:38:35Z<p>Simonton: Statistics</p>
<hr />
<div>== Showing Results ==<br />
<br />
I have already talked with some robocoders about how they would like to see results in the RoboResearch GUI. So far the best design I've come up with (merging ideas from [[Synapse]], [[Rednaxela]], [[Voidious]] and [[Chase-san]]) would open a separate window for each challenge+challenger. It would have a table that shows live-feed results like the summary on wiki pages. That window could be expanded to show a second table underneath the first, with the scores for each season. The top table could also be expanded to include a row for each version of the challenger in the database. Whichever version is selected in the top table is the one whose seasons would be displayed in the lower table. Can I get any feedback or new ideas? --[[User:Simonton|Simonton]] 05:35, 21 September 2008 (UTC)<br />
<br />
Well, apparently everyone either liked the idea or doesn't care enough to offer alternative input. The above idea has been implemented with a slight difference: the seasons are displayed in a separate window, at a button push. This they are not linked to whichever version is selected, either. --[[User:Simonton|Simonton]] 15:29, 1 October 2008 (UTC)<br />
<br />
I would like to add some statistics to the results windows. Firstly I would like to highlight the top score among versions in the results table (or make it italic or underlined, or whatever). But to make that more useful I'd like to calculate the standard deviation of each score, then highlight any that are "close enough" to be tied for the top score. Then I'd like to do the same thing but only within those scores you select. I do it for my own benefit, but I hope candy like this makes you want to update RoboResearch and reap the benefits of my labor :). At some point I'll make a zip file and put it on sourceforge for everyone, so you don't have to deal with SVN. --[[User:Simonton|Simonton]] 15:38, 1 October 2008 (UTC)<br />
<br />
== Networking Proxies ==<br />
<br />
I know how to use raw TCP/IP streams to write the proxies required to implement a networked RoboResearch, but I'm not sure that's the "best" solution. I know how to use [http://www.springframework.org/ Spring] to make remote method calls, but it does not allow callbacks for things like listeners. Does anybody know of some other technology that would be appropriate to support the kind of remote communication necessary? I think I've heard [http://java.sun.com/javase/technologies/core/basic/rmi/index.jsp RMI] can do callbacks, so that might be one possibility. [http://java.sun.com/products/jms/ JMS] might be another. I'm just not familiar enough with any of these to know their strengths and limitations. Something that supports file transfer for uploading/downloading bots would be ideal. Any thoughts/recommendations/input? --[[User:Simonton|Simonton]] 16:38, 25 September 2008 (UTC)</div>Simontonhttp://robowiki.net/w/index.php?title=Talk:RoboResearch/Development&diff=3175Talk:RoboResearch/Development2008-10-01T15:29:09Z<p>Simonton: Done.</p>
<hr />
<div>== Showing Results ==<br />
<br />
I have already talked with some robocoders about how they would like to see results in the RoboResearch GUI. So far the best design I've come up with (merging ideas from [[Synapse]], [[Rednaxela]], [[Voidious]] and [[Chase-san]]) would open a separate window for each challenge+challenger. It would have a table that shows live-feed results like the summary on wiki pages. That window could be expanded to show a second table underneath the first, with the scores for each season. The top table could also be expanded to include a row for each version of the challenger in the database. Whichever version is selected in the top table is the one whose seasons would be displayed in the lower table. Can I get any feedback or new ideas? --[[User:Simonton|Simonton]] 05:35, 21 September 2008 (UTC)<br />
<br />
Well, apparently everyone either liked the idea or doesn't care enough to offer alternative input. The above idea has been implemented with a slight difference: the seasons are displayed in a separate window, at a button push. This they are not linked to whichever version is selected, either. --[[User:Simonton|Simonton]] 15:29, 1 October 2008 (UTC)<br />
<br />
== Networking Proxies ==<br />
<br />
I know how to use raw TCP/IP streams to write the proxies required to implement a networked RoboResearch, but I'm not sure that's the "best" solution. I know how to use [http://www.springframework.org/ Spring] to make remote method calls, but it does not allow callbacks for things like listeners. Does anybody know of some other technology that would be appropriate to support the kind of remote communication necessary? I think I've heard [http://java.sun.com/javase/technologies/core/basic/rmi/index.jsp RMI] can do callbacks, so that might be one possibility. [http://java.sun.com/products/jms/ JMS] might be another. I'm just not familiar enough with any of these to know their strengths and limitations. Something that supports file transfer for uploading/downloading bots would be ideal. Any thoughts/recommendations/input? --[[User:Simonton|Simonton]] 16:38, 25 September 2008 (UTC)</div>Simontonhttp://robowiki.net/w/index.php?title=RoboResearch/Development&diff=3174RoboResearch/Development2008-10-01T15:24:49Z<p>Simonton: typo</p>
<hr />
<div>This page will keep the current design for the next phase(s) of [[RoboResearch]]. I'll keep this page as the "official" design; please use the discussion page to offer feedback and contribute new ideas. This page exists to solicit such input, so please don't be bashful!<br />
<br />
=== The GUI ===<br />
[[Image:RoboResearch.JPG]]<br />
<br />
This is the current development GUI for RoboResearch. In the top section you add and orginize which challenges will be run. All the buttons should be obvious except "Group". When you select multiple challenges and press group, they all get the same number in front of them (that's the group number). An effort will be made to complete the battles for all challenges in the same group at about the same time. As challenges complete, they will drop to the bottom of the list and, if they were the last in their group, all others' group numbers will decrement.<br />
<br />
In the bottom section you control what each of your concurrent battle-running threads does. The "Prefer Group" spinner means that if the stated group exists in the pane above, it will run battles from that group. If it does not, it will default back to running from group 1. So, for example, I could add the rumble as group 1 in the top section (once that functionality is available), then set my threads to prefer 1 and 2 as pictured above. One thread would then always run the rumble, and the other thread would run from challenges I add until they are all done, at which time it would default back to running the rumble.<br />
<br />
There will be a "Configure" button in the top section, too, which for the rumble could set things like MAX_BATTLES. After all bots in the rumble have that many battles, RoboResearch would consider that entry "done". You could add 2 rumble entries, one with unlimited battles and one with a max, to achieve things like "first run all bots up to 2000 battles, then run my challenges, then go back to the rumble again".<br />
<br />
'''What Works:'''<br />
* Adding challenges<br />
* Removing challenges<br />
* Adding threads<br />
* Starting, pausing and killing threads<br />
* The "Prefer Group" feature<br />
* Dynamically updating results for any item in the battle queue<br />
* Bulk thread operations<br />
* Re-organizing the queue<br />
* A button to copy from the results table into wiki format<br />
* Displaying all versions of a bot in the results window for a given challenge<br />
* Seeing scores from each season of a challenge<br />
<br />
'''To-Do:'''<br />
* Editing challenges in the queue<br />
* Adding "the rumble" as an option for the queue<br />
* More results options (TBD, see [[Talk:RoboResearch/Development#Showing_Results]])<br />
<br />
=== Running Networked ===<br />
<br />
The RoboResearch clients (the GUI and TUI) now interact with 3 distinct entities to accomplish their task: a BattleQueue, ScoreHistory and BotRepository. These are 3 interfaces, with current implementations that can run within the same virtual machine. Some of them take listeners in their arguments, for example a ResultsListener (defined by another interface) that receives any updates submitted to the ScoreHistory for a given challenge. The greatest hurdle to running distributed across the internet is writing proxies for these interfaces that will pass the requests from one machine to the next. Once we have something like that we can almost immediately run networked, with further efforts required to make fair battle queue policies and automatic uploading/downloading of required bots. Then comes icing like the ability to specify "I want to prefer battles submitted by Simonton" (just as a random, hypothetical example).</div>Simontonhttp://robowiki.net/w/index.php?title=RoboResearch/Development&diff=3173RoboResearch/Development2008-10-01T15:24:31Z<p>Simonton: Small update</p>
<hr />
<div>This page will keep the current design for the next phase(s) of [[RoboResearch]]. I'll keep this page as the "official" design; please use the discussion page to offer feedback and contribute new ideas. This page exists to solicit such input, so please don't be bashful!<br />
<br />
=== The GUI ===<br />
[[Image:RoboResearch.JPG]]<br />
<br />
This is the current development GUI for RoboResearch. In the top section you add and orginize which challenges will be run. All the buttons should be obvious except "Group". When you select multiple challenges and press group, they all get the same number in front of them (that's the group number). An effort will be made to complete the battles for all challenges in the same group at about the same time. As challenges complete, they will drop to the bottom of the list and, if they were the last in their group, all others' group numbers will decrement.<br />
<br />
In the bottom section you control what each of your concurrent battle-running threads does. The "Prefer Group" spinner means that if the stated group exists in the pane above, it will run battles from that group. If it does not, it will default back to running from group 1. So, for example, I could add the rumble as group 1 in the top section (once that functionality is available), then set my threads to prefer 1 and 2 as pictured above. One thread would then always run the rumble, and the other thread would run from challenges I add until they are all done, at which time it would default back to running the rumble.<br />
<br />
There will be a "Configure" button in the top section, too, which for the rumble could set things like MAX_BATTLES. After all bots in the rumble have that many battles, RoboResearch would consider that entry "done". You could add 2 rumble entries, one with unlimited battles and one with a max, to achieve things like "first run all bots up to 2000 battles, then run my challenges, then go back to the rumble again".<br />
<br />
'''What Works:'''<br />
* Adding challenges<br />
* Removing challenges<br />
* Adding threads<br />
* Starting, pausing and killing threads<br />
* The "Prefer Group" feature<br />
* Dynamically updating results for any item in the battle queue<br />
* Bulk thread operations<br />
* Re-organizing the queue<br />
* A button to copy from the results table into wiki format<br />
* Displaying all versions of a bot in the results window for a given challenge<br />
* Seeing scores from each seasons of a challenge<br />
<br />
'''To-Do:'''<br />
* Editing challenges in the queue<br />
* Adding "the rumble" as an option for the queue<br />
* More results options (TBD, see [[Talk:RoboResearch/Development#Showing_Results]])<br />
<br />
=== Running Networked ===<br />
<br />
The RoboResearch clients (the GUI and TUI) now interact with 3 distinct entities to accomplish their task: a BattleQueue, ScoreHistory and BotRepository. These are 3 interfaces, with current implementations that can run within the same virtual machine. Some of them take listeners in their arguments, for example a ResultsListener (defined by another interface) that receives any updates submitted to the ScoreHistory for a given challenge. The greatest hurdle to running distributed across the internet is writing proxies for these interfaces that will pass the requests from one machine to the next. Once we have something like that we can almost immediately run networked, with further efforts required to make fair battle queue policies and automatic uploading/downloading of required bots. Then comes icing like the ability to specify "I want to prefer battles submitted by Simonton" (just as a random, hypothetical example).</div>Simontonhttp://robowiki.net/w/index.php?title=RoboResearch/Development&diff=3144RoboResearch/Development2008-09-30T19:21:40Z<p>Simonton: Checking a couple more things off.</p>
<hr />
<div>This page will keep the current design for the next phase(s) of [[RoboResearch]]. I'll keep this page as the "official" design; please use the discussion page to offer feedback and contribute new ideas. This page exists to solicit such input, so please don't be bashful!<br />
<br />
=== The GUI ===<br />
[[Image:RoboResearch.JPG]]<br />
<br />
This is the current development GUI for RoboResearch. In the top section you add and orginize which challenges will be run. All the buttons should be obvious except "Group". When you select multiple challenges and press group, they all get the same number in front of them (that's the group number). An effort will be made to complete the battles for all challenges in the same group at about the same time. As challenges complete, they will drop to the bottom of the list and, if they were the last in their group, all others' group numbers will decrement.<br />
<br />
In the bottom section you control what each of your concurrent battle-running threads does. The "Prefer Group" spinner means that if the stated group exists in the pane above, it will run battles from that group. If it does not, it will default back to running from group 1. So, for example, I could add the rumble as group 1 in the top section (once that functionality is available), then set my threads to prefer 1 and 2 as pictured above. One thread would then always run the rumble, and the other thread would run from challenges I add until they are all done, at which time it would default back to running the rumble.<br />
<br />
There will be a "Configure" button in the top section, too, which for the rumble could set things like MAX_BATTLES. After all bots in the rumble have that many battles, RoboResearch would consider that entry "done". You could add 2 rumble entries, one with unlimited battles and one with a max, to achieve things like "first run all bots up to 2000 battles, then run my challenges, then go back to the rumble again".<br />
<br />
'''What Works:'''<br />
* Adding challenges<br />
* Removing challenges<br />
* Adding threads<br />
* Starting, pausing and killing threads<br />
* The "Prefer Group" feature<br />
* Dynamically updating results for any item in the battle queue<br />
* Bulk thread operations<br />
* Re-organizing the queue<br />
* A button to copy from the results table into wiki format<br />
* Displaying all versions of a bot in the results window for a given challenge<br />
<br />
'''To-Do:'''<br />
* Editing challenges in the queue<br />
* Adding "the rumble" as an option for the queue<br />
* More results options (TBD, see [[Talk:RoboResearch/Development#Showing_Results]])<br />
<br />
=== Running Networked ===<br />
<br />
The RoboResearch clients (the GUI and TUI) now interact with 3 distinct entities to accomplish their task: a BattleQueue, ScoreHistory and BotRepository. These are 3 interfaces, with current implementations that can run within the same virtual machine. Some of them take listeners in their arguments, for example a ResultsListener (defined by another interface) that receives any updates submitted to the ScoreHistory for a given challenge. The greatest hurdle to running distributed across the internet is writing proxies for these interfaces that will pass the requests from one machine to the next. Once we have something like that we can almost immediately run networked, with further efforts required to make fair battle queue policies and automatic uploading/downloading of required bots. Then comes icing like the ability to specify "I want to prefer battles submitted by Simonton" (just as a random, hypothetical example).</div>Simontonhttp://robowiki.net/w/index.php?title=Talk:Darkcanuck/RRServer/KnownIssues&diff=3135Talk:Darkcanuck/RRServer/KnownIssues2008-09-27T22:49:11Z<p>Simonton: Survival count should total 35</p>
<hr />
<div>== Survival count should total 35 ==<br />
<br />
I want to confirm what has already been mentioned: survival count should not necessarily total 35. It appears that when bots die on the same tick, they both get credited with a first place finish. --[[User:Simonton|Simonton]] 22:49, 27 September 2008 (UTC)</div>Simontonhttp://robowiki.net/w/index.php?title=Talk:Darkcanuck/RRServer/Roadmap&diff=3134Talk:Darkcanuck/RRServer/Roadmap2008-09-27T22:28:16Z<p>Simonton: New section: Speeeed</p>
<hr />
<div>== Why Re-Create Battles? ==<br />
<br />
I think "delete all my battles & re-load all battles from [[ABC]]'s server" should definitely be on the list of next steps. It might even encourage my contribution to world peace. --[[User:Simonton|Simonton]] 16:46, 26 September 2008 (UTC)<br />
<br />
:I didn't realize that all battles were available on the old server architecture. For some reason, I thought it only kept summaries, but if I can import all that data, that would be great! I won't be deleting any battles from the new server though -- almost all of the data submitted has also been relayed to ABC's server, so his server should be a superset of the two. For an import I would just pull in all of ABC's data (plus the Elo rankings, it would be nice not to have to recalculate those) and there's a duplicate checker which would throw away duplicated results (bot, challenger, timestamp + user IP determine uniqueness). But if you want to contribute to both, just upload your results to mine and they'll also be relayed to ABC's. And keep your "remove old" and "ratings" URLs pointed at ABC's server if you want to flesh out the pairings over there, my clients will keep the pairings here in line. -- [[User:Darkcanuck|Darkcanuck]] 17:01, 26 September 2008 (UTC)<br />
<br />
:The old server never deletes battles, it keeps a (huge) log of all of them. That's actually what led to the first file corruption problems, disk space usage can grow a lot when you leave it running for years. Keep that in mind when you design your battles table, it can easily grow into the millions of rows. BTW, in my server I did a backup/reset of that log somewhere around 100 battles per bot, you should download the battles_* files form the backup dir and append the ones in the main dir. --[[User:ABC|ABC]] 17:22, 26 September 2008 (UTC)<br />
<br />
:Cool. I had a look at those files, it should be straightforward to create an import script, the format is simple. But weren't there some issues with bad results early on? Did you remove all of them by hand, or do I need to filter them out? Also need to figure out how to keep the two systems relatively in sync. Duplicate checker or not, if all that data gets imported and we want to import some updates later on, it might crush the server to keep having to re-import a 40MB battle log.<br />
:Storage space is something I've kept in mind. I've tried to keep the battle results limited to fixed-width binary fields and have some more space-saving plans in the works. Should be much more compact in a database than in plain text files. But I'll probably periodically archive retired bots' results to keep the table lean & mean. -- [[User:Darkcanuck|Darkcanuck]] 18:24, 27 September 2008 (UTC)<br />
<br />
:I removed all of the bad results (and some good ones in the process), those files are clean. The battle timestamp field should be enough for avoiding a full re-import. We should also discuss what to do about the future, do we merge efforts or keep 2 separate servers running? --[[User:ABC|ABC]] 18:53, 27 September 2008 (UTC)<br />
<br />
:: I'll give my perspective as somewhat of a bystander: I think it would be really cool to have a RR server both with some of the features [[User:Darkcanuck|Darkcanuck]] has been working on at the same time as some of the features [[User:ABC|ABC]] has been working on (real neat graphs!). That said, I'd prefer to sitck with having ABC's separate server until this new codebase has proven itself stable. I'd also be tempted to say that I would try to help with a merged effort, however currently I don't think I have time to devote to that, due to a combination of coursework and addiction to working on my next bot. --[[User:Rednaxela|Rednaxela]] 19:20, 27 September 2008 (UTC)<br />
<br />
:If I had known you were going to enhance the old server code when you set up the temporary server, I might not have started this. :) But I think merging the two efforts is better in the long-term, it doesn't make sense to have different rumble servers all over the place. In the meantime, you could try relaying your results over to my server -- if we both check the referrer field (I'm sending "http://darkcanuck.net/rumble") we can avoid endless relay loops.<br />
:My new problem, much to my chagrin, is that the relay wasn't working 100%. Which means I have results that you don't. It's fixed now (and slower, yay) and the relay confirmation is now also sent to the client. I've disabled relaying for melee because it's far too slow and I don't think you're set up for melee? -- [[User:Darkcanuck|Darkcanuck]] 19:32, 27 September 2008 (UTC)<br />
<br />
:: I'm guessing that each time your server gets a result, it uploads it to [[User:ABC|ABC]]'s server and then only once it gets a confirmation from there it sends the confirmation back to the client? How about going multi-threaded, and for each result start a new thread that uploads the result to ABC and then terminates if it is successful? You can send confirmation to the client immediately and the client can immediately upload the next result. This should be significantly quicker. While we're on the topic of multi-threaded, I always wondered why the client didn't do this, ie. simply upload the result after every battle in a separate thread. Another option would be to zip the results into one file and upload them all together at the end of each iteration. --[[User:Skilgannon|Skilgannon]] 22:09, 27 September 2008 (UTC)<br />
<br />
== Speeeed ==<br />
<br />
You just made a comment about this, but let me reiterate it. Submitting results is really slow. I just did some timings: it took 7:42 to run 30 battles, and then 2:28 to upload the results. That's alomst 25% of the time uploading results. The solution is in the use of threads, but really it would be best for those threads to be on the client side, to avoid overwhelming the server. However, nobody has been working on the client, so that's why I bring it up here. Any thoughts, ideas? --[[User:Simonton|Simonton]] 22:28, 27 September 2008 (UTC)</div>Simontonhttp://robowiki.net/w/index.php?title=Talk:Darkcanuck/RRServer/Ratings&diff=3119Talk:Darkcanuck/RRServer/Ratings2008-09-26T18:28:51Z<p>Simonton: Picky, picky</p>
<hr />
<div>== Battles per Pairing ==<br />
<br />
I just wanted to comment on the statement, "It's uncertain how well it works with less battles or incomplete pairings." My experiment with the MC2K7 shows that separate runs of 75 battles can still show more than 1% variation for a given pairing. This affects any scoring system, and is a fact that we have to live with. The reliability of output can only be as good as input, no matter how fancy the interpolation is for incomplete pairings. The hope is that the variance will become a wash when seen over 600+ pairings. --[[User:Simonton|Simonton]] 15:25, 26 September 2008 (UTC)<br />
<br />
I think [[David Alves]] commented that targeting challenge scores also varied by almost 1% at 15 seasons, so I agree there's lots of evidence that more battles per pairing are needed, which would take a very, very long time in a 600+ competitor environment. You're right that as the number of competitors increases, variabilities cancel each other out. But at the same time, the bigger the competition, the more risk of a "black swan" competitor whose scores are ''all'' skewed in one direction. -- [[User:Darkcanuck|Darkcanuck]] 15:31, 26 September 2008 (UTC)<br />
<br />
After scratching some things down on paper which are mostly intuition rather than statistics, I believe the odds of having such a "black swan" are either exactly the same or reduced by increasing the number of bots. --[[User:Simonton|Simonton]] 16:05, 26 September 2008 (UTC)<br />
<br />
Well, if there are 3 bots, the chance of one getting lucky against both others is 1/4th, multiply by 3 bots, and the chance of a "black swan" in 3 bots is 75% I believe. With 4 bots, the chance of one getting lucky against against all others is 1/8th, multiply by 4 bots, and the chance of a black swan is 50%. For 5 bots... it is 31.25% chance of a black swan. For 650 bots with one pairing each, the chance of a bot having above average score in every pairing is about 1 to 2.78*10^193. So if we presume getting lucky is anything above the mean score and there's a 50% chance of that in any pairing, and that a "black swan" is only when ''all'' pairings are lucky, then the chance of a black swan sharply decreases as the number of bots becomes larger. Of course perhaps what would be more useful than simply chance of there being a bot with ''all'' pairings lucky, would be the chance of luck making the score 1% different. I could calculate this, but only if I had a number of what the "standard deviation" of the percent score of an average robocode battle is. --[[User:Rednaxela|Rednaxela]] 16:28, 26 September 2008 (UTC)<br />
<br />
:My intuitive hypothesis remains unshaken, but I don't have any numbers to prove it. But I can't argue with something to the power of 193. :) I'll look into adding standard deviation to some of the tables. What would be most useful, within a pairing, across all pairings, or across all final scores? -- [[User:Darkcanuck|Darkcanuck]] 16:43, 26 September 2008 (UTC)<br />
<br />
Ah, now that you put the statistics that way I can see how to do it. With 3 bots each has 2 pairings, so the chance of both coin flips being "lucky" is indeed 25%. However, the chance of at least 1 of those bots hitting its 25% is <code>(1 - 75%^3) ~= 57.8%</code>. Generalized, this formula is <code>1 - (1 - .5^(bots - 1))^bots</code>. If you graph that you can see it reduces to pretty much zero pretty quickly. --[[User:Simonton|Simonton]] 17:18, 26 September 2008 (UTC)<br />
<br />
:Oh right, I got slightly mixed up and was multiplying by 3 when I should have been working with powers. --[[User:Rednaxela|Rednaxela]] 17:35, 26 September 2008 (UTC)<br />
<br />
:You've got an extra leading paren, but that makes sense to me. Nothing to worry about! -- [[User:Darkcanuck|Darkcanuck]] 18:05, 26 September 2008 (UTC)</div>Simontonhttp://robowiki.net/w/index.php?title=Talk:Darkcanuck/RRServer/Ratings&diff=3115Talk:Darkcanuck/RRServer/Ratings2008-09-26T17:18:33Z<p>Simonton: Better Statistics :P</p>
<hr />
<div>== Battles per Pairing ==<br />
<br />
I just wanted to comment on the statement, "It's uncertain how well it works with less battles or incomplete pairings." My experiment with the MC2K7 shows that separate runs of 75 battles can still show more than 1% variation for a given pairing. This affects any scoring system, and is a fact that we have to live with. The reliability of output can only be as good as input, no matter how fancy the interpolation is for incomplete pairings. The hope is that the variance will become a wash when seen over 600+ pairings. --[[User:Simonton|Simonton]] 15:25, 26 September 2008 (UTC)<br />
<br />
I think [[David Alves]] commented that targeting challenge scores also varied by almost 1% at 15 seasons, so I agree there's lots of evidence that more battles per pairing are needed, which would take a very, very long time in a 600+ competitor environment. You're right that as the number of competitors increases, variabilities cancel each other out. But at the same time, the bigger the competition, the more risk of a "black swan" competitor whose scores are ''all'' skewed in one direction. -- [[User:Darkcanuck|Darkcanuck]] 15:31, 26 September 2008 (UTC)<br />
<br />
After scratching some things down on paper which are mostly intuition rather than statistics, I believe the odds of having such a "black swan" are either exactly the same or reduced by increasing the number of bots. --[[User:Simonton|Simonton]] 16:05, 26 September 2008 (UTC)<br />
<br />
Well, if there are 3 bots, the chance of one getting lucky against both others is 1/4th, multiply by 3 bots, and the chance of a "black swan" in 3 bots is 75% I believe. With 4 bots, the chance of one getting lucky against against all others is 1/8th, multiply by 4 bots, and the chance of a black swan is 50%. For 5 bots... it is 31.25% chance of a black swan. For 650 bots with one pairing each, the chance of a bot having above average score in every pairing is about 1 to 2.78*10^193. So if we presume getting lucky is anything above the mean score and there's a 50% chance of that in any pairing, and that a "black swan" is only when ''all'' pairings are lucky, then the chance of a black swan sharply decreases as the number of bots becomes larger. Of course perhaps what would be more useful than simply chance of there being a bot with ''all'' pairings lucky, would be the chance of luck making the score 1% different. I could calculate this, but only if I had a number of what the "standard deviation" of the percent score of an average robocode battle is. --[[User:Rednaxela|Rednaxela]] 16:28, 26 September 2008 (UTC)<br />
<br />
:My intuitive hypothesis remains unshaken, but I don't have any numbers to prove it. But I can't argue with something to the power of 193. :) I'll look into adding standard deviation to some of the tables. What would be most useful, within a pairing, across all pairings, or across all final scores? -- [[User:Darkcanuck|Darkcanuck]] 16:43, 26 September 2008 (UTC)<br />
<br />
Ah, now that you put the statistics that way I can see how to do it. With 3 bots each has 2 pairings, so the chance of both coin flips being "lucky" is indeed 25%. However, the chance of at least 1 of those bots hitting its 25% is <code>(1 - 75%^3) ~= 57.8%</code>. Generalized, this formula is <code>(1 - (1 - .5^(bots - 1))^bots</code>. If you graph that you can see it reduces to pretty much zero pretty quickly. --[[User:Simonton|Simonton]] 17:18, 26 September 2008 (UTC)</div>Simontonhttp://robowiki.net/w/index.php?title=Talk:Darkcanuck/RRServer/Roadmap&diff=3111Talk:Darkcanuck/RRServer/Roadmap2008-09-26T16:46:18Z<p>Simonton: Why Re-Create Battles?</p>
<hr />
<div>== Why Re-Create Battles? ==<br />
<br />
I think "delete all my battles & re-load all battles from [[ABC]]'s server" should definitely be on the list of next steps. It might even encourage my contribution to world peace. --[[User:Simonton|Simonton]] 16:46, 26 September 2008 (UTC)</div>Simontonhttp://robowiki.net/w/index.php?title=Talk:Darkcanuck/RRServer/Ratings&diff=3105Talk:Darkcanuck/RRServer/Ratings2008-09-26T16:05:20Z<p>Simonton: Dark Elegance</p>
<hr />
<div>== Battles per Pairing ==<br />
<br />
I just wanted to comment on the statement, "It's uncertain how well it works with less battles or incomplete pairings." My experiment with the MC2K7 shows that separate runs of 75 battles can still show more than 1% variation for a given pairing. This affects any scoring system, and is a fact that we have to live with. The reliability of output can only be as good as input, no matter how fancy the interpolation is for incomplete pairings. The hope is that the variance will become a wash when seen over 600+ pairings. --[[User:Simonton|Simonton]] 15:25, 26 September 2008 (UTC)<br />
<br />
I think [[David Alves]] commented that targeting challenge scores also varied by almost 1% at 15 seasons, so I agree there's lots of evidence that more battles per pairing are needed, which would take a very, very long time in a 600+ competitor environment. You're right that as the number of competitors increases, variabilities cancel each other out. But at the same time, the bigger the competition, the more risk of a "black swan" competitor whose scores are ''all'' skewed in one direction. -- [[User:Darkcanuck|Darkcanuck]] 15:31, 26 September 2008 (UTC)<br />
<br />
After scratching some things down on paper which are mostly intuition rather than statistics, I believe the odds of having such a "black swan" are either exactly the same or reduced by increasing the number of bots. --[[User:Simonton|Simonton]] 16:05, 26 September 2008 (UTC)</div>Simontonhttp://robowiki.net/w/index.php?title=RoboResearch/Development&diff=3101RoboResearch/Development2008-09-26T15:27:52Z<p>Simonton: A little more progress</p>
<hr />
<div>This page will keep the current design for the next phase(s) of [[RoboResearch]]. I'll keep this page as the "official" design; please use the discussion page to offer feedback and contribute new ideas. This page exists to solicit such input, so please don't be bashful!<br />
<br />
=== The GUI ===<br />
[[Image:RoboResearch.JPG]]<br />
<br />
This is the current development GUI for RoboResearch. In the top section you add and orginize which challenges will be run. All the buttons should be obvious except "Group". When you select multiple challenges and press group, they all get the same number in front of them (that's the group number). An effort will be made to complete the battles for all challenges in the same group at about the same time. As challenges complete, they will drop to the bottom of the list and, if they were the last in their group, all others' group numbers will decrement.<br />
<br />
In the bottom section you control what each of your concurrent battle-running threads does. The "Prefer Group" spinner means that if the stated group exists in the pane above, it will run battles from that group. If it does not, it will default back to running from group 1. So, for example, I could add the rumble as group 1 in the top section (once that functionality is available), then set my threads to prefer 1 and 2 as pictured above. One thread would then always run the rumble, and the other thread would run from challenges I add until they are all done, at which time it would default back to running the rumble.<br />
<br />
There will be a "Configure" button in the top section, too, which for the rumble could set things like MAX_BATTLES. After all bots in the rumble have that many battles, RoboResearch would consider that entry "done". You could add 2 rumble entries, one with unlimited battles and one with a max, to achieve things like "first run all bots up to 2000 battles, then run my challenges, then go back to the rumble again".<br />
<br />
'''What Works:'''<br />
* Adding challenges<br />
* Removing challenges<br />
* Adding threads<br />
* Starting, pausing and killing threads<br />
* The "Prefer Group" feature<br />
* Dynamically updating results for any item in the battle queue<br />
* Bulk thread operations<br />
* Re-organizing the queue<br />
<br />
'''To-Do:'''<br />
* Editing challenges in the queue<br />
* Adding "the rumble" as an option for the queue<br />
* More results options (TBD, see [[Talk:RoboResearch/Development#Showing_Results]])<br />
* A button to copy from the results table into wiki format<br />
<br />
=== Running Networked ===<br />
<br />
The RoboResearch clients (the GUI and TUI) now interact with 3 distinct entities to accomplish their task: a BattleQueue, ScoreHistory and BotRepository. These are 3 interfaces, with current implementations that can run within the same virtual machine. Some of them take listeners in their arguments, for example a ResultsListener (defined by another interface) that receives any updates submitted to the ScoreHistory for a given challenge. The greatest hurdle to running distributed across the internet is writing proxies for these interfaces that will pass the requests from one machine to the next. Once we have something like that we can almost immediately run networked, with further efforts required to make fair battle queue policies and automatic uploading/downloading of required bots. Then comes icing like the ability to specify "I want to prefer battles submitted by Simonton" (just as a random, hypothetical example).</div>Simontonhttp://robowiki.net/w/index.php?title=Talk:Darkcanuck/RRServer/Ratings&diff=3099Talk:Darkcanuck/RRServer/Ratings2008-09-26T15:25:42Z<p>Simonton: Battles per Pairing</p>
<hr />
<div>== Battles per Pairing ==<br />
<br />
I just wanted to comment on the statement, "It's uncertain how well it works with less battles or incomplete pairings." My experiment with the MC2K7 shows that separate runs of 75 battles can still show more than 1% variation for a given pairing. This affects any scoring system, and is a fact that we have to live with. The reliability of output can only be as good as input, no matter how fancy the interpolation is for incomplete pairings. The hope is that the variance will become a wash when seen over 600+ pairings. --[[User:Simonton|Simonton]] 15:25, 26 September 2008 (UTC)</div>Simontonhttp://robowiki.net/w/index.php?title=Talk:RoboResearch/Development&diff=3049Talk:RoboResearch/Development2008-09-25T16:43:01Z<p>Simonton: That was not supposed to be a minor edit ...</p>
<hr />
<div>== Showing Results ==<br />
<br />
I have already talked with some robocoders about how they would like to see results in the RoboResearch GUI. So far the best design I've come up with (merging ideas from [[Synapse]], [[Rednaxela]], [[Voidious]] and [[Chase-san]]) would open a separate window for each challenge+challenger. It would have a table that shows live-feed results like the summary on wiki pages. That window could be expanded to show a second table underneath the first, with the scores for each season. The top table could also be expanded to include a row for each version of the challenger in the database. Whichever version is selected in the top table is the one whose seasons would be displayed in the lower table. Can I get any feedback or new ideas? --[[User:Simonton|Simonton]] 05:35, 21 September 2008 (UTC)<br />
<br />
== Networking Proxies ==<br />
<br />
I know how to use raw TCP/IP streams to write the proxies required to implement a networked RoboResearch, but I'm not sure that's the "best" solution. I know how to use [http://www.springframework.org/ Spring] to make remote method calls, but it does not allow callbacks for things like listeners. Does anybody know of some other technology that would be appropriate to support the kind of remote communication necessary? I think I've heard [http://java.sun.com/javase/technologies/core/basic/rmi/index.jsp RMI] can do callbacks, so that might be one possibility. [http://java.sun.com/products/jms/ JMS] might be another. I'm just not familiar enough with any of these to know their strengths and limitations. Something that supports file transfer for uploading/downloading bots would be ideal. Any thoughts/recommendations/input? --[[User:Simonton|Simonton]] 16:38, 25 September 2008 (UTC)</div>Simontonhttp://robowiki.net/w/index.php?title=Talk:RoboResearch/Development&diff=3048Talk:RoboResearch/Development2008-09-25T16:38:19Z<p>Simonton: New section: Networking Proxies</p>
<hr />
<div>== Showing Results ==<br />
<br />
I have already talked with some robocoders about how they would like to see results in the RoboResearch GUI. So far the best design I've come up with (merging ideas from [[Synapse]], [[Rednaxela]], [[Voidious]] and [[Chase-san]]) would open a separate window for each challenge+challenger. It would have a table that shows live-feed results like the summary on wiki pages. That window could be expanded to show a second table underneath the first, with the scores for each season. The top table could also be expanded to include a row for each version of the challenger in the database. Whichever version is selected in the top table is the one whose seasons would be displayed in the lower table. Can I get any feedback or new ideas? --[[User:Simonton|Simonton]] 05:35, 21 September 2008 (UTC)<br />
<br />
== Networking Proxies ==<br />
<br />
I know how to use raw TCP/IP streams to write the proxies required to implement a networked RoboResearch, but I'm not sure that's the "best" solution. I know how to use [http://www.springframework.org/ Spring] to make remote method calls, but it does not allow callbacks for things like listeners. Does anybody know of some other technology that would be appropriate to support the kind of remote communication necessary? I think I've heard [http://java.sun.com/javase/technologies/core/basic/rmi/index.jsp RMI] can do callbacks, so that might be one possibility. [http://java.sun.com/products/jms/ JMS] might be another. I'm just not familiar enough with any of these to know their strengths and limitations. Any thoughts/recommendations/input? --[[User:Simonton|Simonton]] 16:38, 25 September 2008 (UTC)</div>Simontonhttp://robowiki.net/w/index.php?title=RoboResearch/Development&diff=3047RoboResearch/Development2008-09-25T16:30:33Z<p>Simonton: Networking Progress</p>
<hr />
<div>This page will keep the current design for the next phase(s) of [[RoboResearch]]. I'll keep this page as the "official" design; please use the discussion page to offer feedback and contribute new ideas. This page exists to solicit such input, so please don't be bashful!<br />
<br />
=== The GUI ===<br />
[[Image:RoboResearch.JPG]]<br />
<br />
This is the current development GUI for RoboResearch. In the top section you add and orginize which challenges will be run. All the buttons should be obvious except "Group". When you select multiple challenges and press group, they all get the same number in front of them (that's the group number). An effort will be made to complete the battles for all challenges in the same group at about the same time. As challenges complete, they will drop to the bottom of the list and, if they were the last in their group, all others' group numbers will decrement.<br />
<br />
In the bottom section you control what each of your concurrent battle-running threads does. The "Prefer Group" spinner means that if the stated group exists in the pane above, it will run battles from that group. If it does not, it will default back to running from group 1. So, for example, I could add the rumble as group 1 in the top section (once that functionality is available), then set my threads to prefer 1 and 2 as pictured above. One thread would then always run the rumble, and the other thread would run from challenges I add until they are all done, at which time it would default back to running the rumble.<br />
<br />
There will be a "Configure" button in the top section, too, which for the rumble could set things like MAX_BATTLES. After all bots in the rumble have that many battles, RoboResearch would consider that entry "done". You could add 2 rumble entries, one with unlimited battles and one with a max, to achieve things like "first run all bots up to 2000 battles, then run my challenges, then go back to the rumble again".<br />
<br />
What works:<br />
* Adding challenges<br />
* Removing challenges<br />
* Adding threads<br />
* Starting, pausing and killing threads<br />
* The "Prefer Group" feature<br />
* Dynamically updating results for any item in the battle queue<br />
<br />
To-Do:<br />
* Editing challenges in the queue<br />
* Re-organizing the queue<br />
* Bulk thread operations<br />
* Adding "the rumble" as an option for the queue<br />
* More results options (TBD, see [[Talk:RoboResearch/Development#Showing_Results]])<br />
* Ctrl+C should copy from the results table into wiki format<br />
<br />
=== Running Networked ===<br />
<br />
The RoboResearch clients (the GUI and TUI) now interact with 3 distinct entities to accomplish their task: a BattleQueue, ScoreHistory and BotRepository. These are 3 interfaces, with current implementations that can run within the same virtual machine. Some of them take listeners in their arguments, for example a ResultsListener (defined by another interface) that receives any updates submitted to the ScoreHistory for a given challenge. The greatest hurdle to running distributed across the internet is writing proxies for these interfaces that will pass the requests from one machine to the next. Once we have something like that we can almost immediately run networked, with further efforts required to make fair battle queue policies and automatic uploading/downloading of required bots. Then comes icing like the ability to specify "I want to prefer battles submitted by Simonton" (just as a random, hypothetical example).</div>Simontonhttp://robowiki.net/w/index.php?title=RoboResearch/Development&diff=3046RoboResearch/Development2008-09-25T16:13:58Z<p>Simonton: Dynamic Results are Here</p>
<hr />
<div>This page will keep the current design for the next phase(s) of [[RoboResearch]]. I'll keep this page as the "official" design; please use the discussion page to offer feedback and contribute new ideas. This page exists to solicit such input, so please don't be bashful!<br />
<br />
=== The GUI ===<br />
[[Image:RoboResearch.JPG]]<br />
<br />
This is the current development GUI for RoboResearch. In the top section you add and orginize which challenges will be run. All the buttons should be obvious except "Group". When you select multiple challenges and press group, they all get the same number in front of them (that's the group number). An effort will be made to complete the battles for all challenges in the same group at about the same time. As challenges complete, they will drop to the bottom of the list and, if they were the last in their group, all others' group numbers will decrement.<br />
<br />
In the bottom section you control what each of your concurrent battle-running threads does. The "Prefer Group" spinner means that if the stated group exists in the pane above, it will run battles from that group. If it does not, it will default back to running from group 1. So, for example, I could add the rumble as group 1 in the top section (once that functionality is available), then set my threads to prefer 1 and 2 as pictured above. One thread would then always run the rumble, and the other thread would run from challenges I add until they are all done, at which time it would default back to running the rumble.<br />
<br />
There will be a "Configure" button in the top section, too, which for the rumble could set things like MAX_BATTLES. After all bots in the rumble have that many battles, RoboResearch would consider that entry "done". You could add 2 rumble entries, one with unlimited battles and one with a max, to achieve things like "first run all bots up to 2000 battles, then run my challenges, then go back to the rumble again".<br />
<br />
What works:<br />
* Adding challenges<br />
* Removing challenges<br />
* Adding threads<br />
* Starting, pausing and killing threads<br />
* The "Prefer Group" feature<br />
* Dynamically updating results for any item in the battle queue<br />
<br />
To-Do:<br />
* Editing challenges in the queue<br />
* Re-organizing the queue<br />
* Bulk thread operations<br />
* Adding "the rumble" as an option for the queue<br />
* More results options (TBD, see [[Talk:RoboResearch/Development#Showing_Results]])<br />
* Ctrl+C should copy from the results table into wiki format<br />
<br />
=== Running Networked ===</div>Simontonhttp://robowiki.net/w/index.php?title=Talk:Watermelon/Development&diff=3045Talk:Watermelon/Development2008-09-25T16:11:55Z<p>Simonton: Hooray!</p>
<hr />
<div>== Hooray! ==<br />
<br />
Glad to see you consider your bot worthy of version tracking now! It's fun to watch people's progress. --[[User:Simonton|Simonton]] 16:11, 25 September 2008 (UTC)</div>Simontonhttp://robowiki.net/w/index.php?title=Talk:RoboRumble/Reported_Problems&diff=3040Talk:RoboRumble/Reported Problems2008-09-23T20:15:13Z<p>Simonton: The lights go on.</p>
<hr />
<div>== Repeated Battles ==<br />
<br />
Not sure if this is the best place to put this, but here it is. My roborumble client would keep getting hung up running the same bot over & over, regardless of how many battles it already had or how many other bots were below the <tt>BATTLES_PER_BOT</tt> limit I set. I think I took care of the problem by deleting files between between runs of the rumble. This is my <tt>roborumble.bat</tt> file now:<br />
<pre><nowiki><br />
:TOP<br />
java -Xmx256M -Dsun.io.useCanonCaches=false -cp libs/robocode.jar;libs/codesize.jar;libs/roborumble.jar roborumble.RoboRumbleAtHome ./roborumble/roborumble.txt<br />
del roborumble\temp\battles*<br />
del roborumble\temp\priority*<br />
GOTO TOP<br />
</nowiki></pre><br />
I think the priority battles file was the culprit, but I'm leaving the other line in for good measure. --[[User:Simonton|Simonton]] 16:35, 22 September 2008 (UTC)<br />
<br />
Woah, I certainly see the results of these stuck pairings... such as Drifter vs Okami over 200 times, and similar for Fermat vs Okami. It sure feels unusual seeing over 100 battles in any pairing in RR, but at least we know those pairings are accurate haha. --[[User:Rednaxela|Rednaxela]] 19:22, 22 September 2008 (UTC)<br />
<br />
As for accuracy, below is the impact of battles on the score. This is 0.7*old + 0.3*new. For first battle you can also read 'all battles till now'. This means that 2 new battles will reduce the influence of the previous ones to 50%.<br />
<pre><br />
1 2 3 4 5<br />
first 100<br />
second 70 30<br />
third 49 21 30<br />
fourth 35 14 21 30<br />
fifth 25 10 14 21 30<br />
</pre> --[[User:GrubbmGait|GrubbmGait]] 23:52, 22 September 2008 (UTC)<br />
<br />
Sorry, Grub, I'm not really following you. What does this table represent? What is its relevance to rumble scores? --[[User:Simonton|Simonton]] 23:57, 22 September 2008 (UTC)<br />
<br />
It's the influence of each battle on the % score. From the table, after a bot has 5 battles in a pairing, the most recent battle has a weightage of 30%, 2nd most recent 21%, third is 14%, fourth is 10% and the first battle ever run for that pairing is 25% (the first battle always has a disproportionate weighting) towards the % score for that pairing -- [[User:Nfwu|<font color="#3B9C9C">Ketsu</font>]][[User Talk:Nfwu|<font color="#F87217">Nfwu</font>]] 08:48, 23 September 2008 (UTC)<br />
<br />
My fault, I should have explained it better. Its relevance to the stability of the rumble scores is this: The last 4 battles determine 75% of the performance against an opponent. So when 100 battles are fought against a particular bot, battle 1 till 96 determine only 25% of the performance. The good part is that this info can be used to 'repair' results from bad clients. --[[User:GrubbmGait|GrubbmGait]] 19:23, 23 September 2008 (UTC)<br />
<br />
Now I understand! So - the rumble uses .7*averagePercentScore + .3*percentScore (similar to a [[Rolling Average]]) to calculate the %score of any given pairing, and you are showing us that running 100 battles doesn't really make that number any more reliable than running maybe 10 battles (at which point the first only has a weight of 4%). [[ABC]] talked about making his server use absolute averages instead of rolling averages; I wonder if he implemented that. --[[User:Simonton|Simonton]] 20:15, 23 September 2008 (UTC)<br />
<br />
== Security exception 1.6.0 ==<br />
<br />
One bot suffers from a security exception in v1.6.0, namely axebots.SilverSurfer.<br />
It seems the only bot that has this problem, so the impact is not that big. Maybe someone (or Axe himself) can update the bot so it can be processed by the latest robocode versions. --[[User:GrubbmGait|GrubbmGait]] 23:52, 22 September 2008 (UTC)</div>Simontonhttp://robowiki.net/w/index.php?title=RoboResearch/Development&diff=3036RoboResearch/Development2008-09-23T05:31:02Z<p>Simonton: Results!</p>
<hr />
<div>This page will keep the current design for the next phase(s) of [[RoboResearch]]. I'll keep this page as the "official" design; please use the discussion page to offer feedback and contribute new ideas. This page exists to solicit such input, so please don't be bashful!<br />
<br />
=== The GUI ===<br />
[[Image:RoboResearch.JPG]]<br />
<br />
This is the current development GUI for RoboResearch. In the top section you add and orginize which challenges will be run. All the buttons should be obvious except "Group". When you select multiple challenges and press group, they all get the same number in front of them (that's the group number). An effort will be made to complete the battles for all challenges in the same group at about the same time. As challenges complete, they will drop to the bottom of the list and, if they were the last in their group, all others' group numbers will decrement.<br />
<br />
In the bottom section you control what each of your concurrent battle-running threads does. The "Prefer Group" spinner means that if the stated group exists in the pane above, it will run battles from that group. If it does not, it will default back to running from group 1. So, for example, I could add the rumble as group 1 in the top section (once that functionality is available), then set my threads to prefer 1 and 2 as pictured above. One thread would then always run the rumble, and the other thread would run from challenges I add until they are all done, at which time it would default back to running the rumble.<br />
<br />
There will be a "Configure" button in the top section, too, which for the rumble could set things like MAX_BATTLES. After all bots in the rumble have that many battles, RoboResearch would consider that entry "done". You could add 2 rumble entries, one with unlimited battles and one with a max, to achieve things like "first run all bots up to 2000 battles, then run my challenges, then go back to the rumble again".<br />
<br />
What works:<br />
* Adding challenges<br />
* Removing challenges<br />
* Adding threads<br />
* Starting, pausing and killing threads<br />
* The "Prefer Group" feature<br />
* Static results for any item in the battle queue<br />
<br />
To-Do:<br />
* Editing challenges in the queue<br />
* Re-organizing the queue<br />
* Bulk thread operations<br />
* Adding "the rumble" as an option for the queue<br />
* Updating displayed results as battles complete<br />
* More results options (TBD, see [[Talk:RoboResearch/Development#Showing_Results]])<br />
* Ctrl+C should copy from the results table into wiki format<br />
<br />
=== Running Networked ===</div>Simontonhttp://robowiki.net/w/index.php?title=Talk:RoboRumble&diff=3035Talk:RoboRumble2008-09-23T02:47:15Z<p>Simonton: New section: Lynch the Multi-Threaders!</p>
<hr />
<div>== RoboRumble history ==<br />
April 27 2005 - The RoboRumble@Home server is now moved to Pulsar's machine. See /TemporaryServerUp for the RR@H settings files to use and some more details. The only difference you should note is that the flag-less bots no longer have the Jolly Roger flag. This is temporary and will be fixed soon. Huge thanks to Pulsar for carrying the burden (reponsibility-wise) a while with this. I'll sleep tighter now when I don't need to worry if my WinXP Home PC (yes, it was hosted in such an environment before!) is awake and responsive. -- PEZ<br />
<br />
October 28 2005 - The RoboRumble@Home server will be down for several hours for upgrades tomorrow (Saturday Octber 29). As a side effect this will solve the issues some people have with port 8080. --Pulsar<br />
<br />
October 29 2005 - The RoboRumble@Home server is going down shortly and will be up and running again within 12hours hopefully. -- Pulsar<br />
<br />
October 29 2005 - The RoboRumble@Home server is up and running. Updates are needed for RoboRumble@Home clients. -- Pulsar<br />
<br />
February 18 2006 - The RoboRumble@Home server connection might experience some downtime the following hours as I will reorganize the firewall setup. --Pulsar<br />
<br />
March 7 2006 - The firewall switch over has now finally been done, and everything seems to be working. Some people might experience a short delay until DNS records have been updated around the world (though they were and are set to a very short "time to live" to minimize this). RoboRumble@Home clients need to be restarted as Java by default caches DNS lookups. --Pulsar <br />
<br />
== Subpages ==<br />
Should we replace ALL of the subpages? or just the 'important' ones? -- [[User:Starrynte|Starrynte]] 22:16, 17 November 2007 (UTC)<br />
<br />
== Name ==<br />
<br />
Since the new wiki supports symbols in page names, should we put this page at [[RoboRumble@Home]] instead of RoboRumble? We already have a redirect from that page to this one... --[[User:AaronR|AaronR]] 23:34, 17 November 2007 (UTC)<br />
<br />
== RR seems to be down ==<br />
<br />
Roborumble is returning 503 Unavailable for all pages today. Not sure why. -- [[User:Synapse|<font style="font-size:0.8em;font-variant:small-caps;">Synapse</font>]] 03:07, 19 September 2008 (UTC)<br />
:Are you sure? Both [http://rumble.fervir.com/rumble/Rankings?version=1&game=roborumble rumble.fervir.com] and [http://abchome.aclsi.pt:8080/ ABC's] work for me. -- [[User:Nfwu|<font color="#3B9C9C">Ketsu</font>]][[User Talk:Nfwu|<font color="#F87217">Nfwu</font>]] 03:33, 19 September 2008 (UTC)<br />
::I fail. I meant Robocode Repository. -- [[User:Synapse|<font style="font-size:0.8em;font-variant:small-caps;">Synapse</font>]] 05:44, 19 September 2008 (UTC)<br />
::Not a big surprise there. =P -- [[User:Nfwu|<font color="#3B9C9C">Ketsu</font>]][[User Talk:Nfwu|<font color="#F87217">Nfwu</font>]] 13:21, 19 September 2008 (UTC)<br />
<br />
== Lynch the Multi-Threaders! ==<br />
<br />
A thought just occurred to me. I have never liked the fact that robots could be threaded. Why?<br />
# On a single-core (non-hyperthreaded) machine it cannot help the bot without hurting the opponent. Either a) all computation is done on one CPU during your turn, in which case you could have done the same computation with less overhead without the threads, or b) you do computation past your turn, eating up CPU cycles from your opponent.<br />
# On a multi-core (or hyperthreaded) machine, it violates the idea that all bots are equal except for their AI. You suddenly get 2 CPU's in your robot, essentially.<br />
This is a reality we have had to live with, because that's the way robocode is designed. HOWEVER - it just occurred to me that we ''could'' enforce a rule saying that no multi-threaded bot is allowed in ''the rumble''! Which I hereby propose. Besides being unfair to the bot's opponent, acting like a virus stealing CPU, it steals CPU from bots in OTHER battles now-a-days when more than one rumble client executes at a time on multi-core machines! Any bot caught using multiple threads would be immediately removed from the rumble. Does anybody agree? --[[User:Simonton|Simonton]] 02:47, 23 September 2008 (UTC)</div>Simontonhttp://robowiki.net/w/index.php?title=Talk:RoboResearch&diff=3034Talk:RoboResearch2008-09-23T02:21:15Z<p>Simonton: More data loss</p>
<hr />
<div>== SVN Update Notes ==<br />
<br />
If you update from SVN, be ready to change your .cfg files. The example "run.cfg" is updated - it's still easy. Perhaps easier than they were! --[[User:Simonton|Simonton]] 04:25, 16 September 2008 (UTC)<br />
<br />
== HSQLDB No More ==<br />
<br />
Beware of abrupt shutdowns of the database server. I just lost all my scores between [[Simonton/PFResearch]] 0073 and 0083, apparently because I closed Eclipse which simply killed the database process, instead of shutting it down nicely. I certainly thought it would handle such things better than that, and I have done it many times before with no consequence, but apparently my timing was bad this time. Does anyone have a good recommendation for a more reliable database that can be run without firing off a separate process, if desired? --[[User:Simonton|Simonton]] 07:51, 18 September 2008 (UTC)<br />
<br />
It looks like the Apache Derby implementation distributed with Java 6 would be the natural choice! Expect that change to come in the near future, for fear of losing more of my data otherwise! --[[User:Simonton|Simonton]] 15:04, 18 September 2008 (UTC)<br />
<br />
It happened again. This time I only lost some data for 0088. I wasn't going to be upset if I lost alot more, but it just confirms this is a switch that has to be made. For now I'm making a copy of the database directory before I kill the database server. Sending the sever the shutdown command via SQL would work, but that's too much effort. They should make it accept a clean shutdown command from the terminal in which you launch the server, that would be handy. --[[User:Simonton|Simonton]] 02:21, 23 September 2008 (UTC)</div>Simontonhttp://robowiki.net/w/index.php?title=Talk:RoboRumble/Reported_Problems&diff=3033Talk:RoboRumble/Reported Problems2008-09-22T23:57:43Z<p>Simonton: Oops - forgot about that "signature" feature</p>
<hr />
<div>== Repeated Battles ==<br />
<br />
Not sure if this is the best place to put this, but here it is. My roborumble client would keep getting hung up running the same bot over & over, regardless of how many battles it already had or how many other bots were below the <tt>BATTLES_PER_BOT</tt> limit I set. I think I took care of the problem by deleting files between between runs of the rumble. This is my <tt>roborumble.bat</tt> file now:<br />
<pre><nowiki><br />
:TOP<br />
java -Xmx256M -Dsun.io.useCanonCaches=false -cp libs/robocode.jar;libs/codesize.jar;libs/roborumble.jar roborumble.RoboRumbleAtHome ./roborumble/roborumble.txt<br />
del roborumble\temp\battles*<br />
del roborumble\temp\priority*<br />
GOTO TOP<br />
</nowiki></pre><br />
I think the priority battles file was the culprit, but I'm leaving the other line in for good measure. --[[User:Simonton|Simonton]] 16:35, 22 September 2008 (UTC)<br />
<br />
Woah, I certainly see the results of these stuck pairings... such as Drifter vs Okami over 200 times, and similar for Fermat vs Okami. It sure feels unusual seeing over 100 battles in any pairing in RR, but at least we know those pairings are accurate haha. --[[User:Rednaxela|Rednaxela]] 19:22, 22 September 2008 (UTC)<br />
<br />
As for accuracy, below is the impact of battles on the score. This is 0.7*old + 0.3*new. For first battle you can also read 'all battles till now'. This means that 2 new battles will reduce the influence of the previous ones to 50%.<br />
<pre><br />
1 2 3 4 5<br />
first 100<br />
second 70 30<br />
third 49 21 30<br />
fourth 35 14 21 30<br />
fifth 25 10 14 21 30<br />
</pre> --[[User:GrubbmGait|GrubbmGait]] 23:52, 22 September 2008 (UTC)<br />
<br />
Sorry, Grub, I'm not really following you. What does this table represent? What is its relevance to rumble scores? --[[User:Simonton|Simonton]] 23:57, 22 September 2008 (UTC)<br />
<br />
== Security exception 1.6.0 ==<br />
<br />
One bot suffers from a security exception in v1.6.0, namely axebots.SilverSurfer.<br />
It seems the only bot that has this problem, so the impact is not that big. Maybe someone (or Axe himself) can update the bot so it can be processed by the latest robocode versions. --[[User:GrubbmGait|GrubbmGait]] 23:52, 22 September 2008 (UTC)</div>Simontonhttp://robowiki.net/w/index.php?title=Talk:RoboRumble/Reported_Problems&diff=3032Talk:RoboRumble/Reported Problems2008-09-22T23:57:18Z<p>Simonton: I don't get it.</p>
<hr />
<div>== Repeated Battles ==<br />
<br />
Not sure if this is the best place to put this, but here it is. My roborumble client would keep getting hung up running the same bot over & over, regardless of how many battles it already had or how many other bots were below the <tt>BATTLES_PER_BOT</tt> limit I set. I think I took care of the problem by deleting files between between runs of the rumble. This is my <tt>roborumble.bat</tt> file now:<br />
<pre><nowiki><br />
:TOP<br />
java -Xmx256M -Dsun.io.useCanonCaches=false -cp libs/robocode.jar;libs/codesize.jar;libs/roborumble.jar roborumble.RoboRumbleAtHome ./roborumble/roborumble.txt<br />
del roborumble\temp\battles*<br />
del roborumble\temp\priority*<br />
GOTO TOP<br />
</nowiki></pre><br />
I think the priority battles file was the culprit, but I'm leaving the other line in for good measure. --[[User:Simonton|Simonton]] 16:35, 22 September 2008 (UTC)<br />
<br />
Woah, I certainly see the results of these stuck pairings... such as Drifter vs Okami over 200 times, and similar for Fermat vs Okami. It sure feels unusual seeing over 100 battles in any pairing in RR, but at least we know those pairings are accurate haha. --[[User:Rednaxela|Rednaxela]] 19:22, 22 September 2008 (UTC)<br />
<br />
As for accuracy, below is the impact of battles on the score. This is 0.7*old + 0.3*new. For first battle you can also read 'all battles till now'. This means that 2 new battles will reduce the influence of the previous ones to 50%.<br />
<pre><br />
1 2 3 4 5<br />
first 100<br />
second 70 30<br />
third 49 21 30<br />
fourth 35 14 21 30<br />
fifth 25 10 14 21 30<br />
</pre> --[[User:GrubbmGait|GrubbmGait]] 23:52, 22 September 2008 (UTC)<br />
<br />
Sorry, Grub, I'm not really following you. What does this table represent? What is its relevance to rumble scores? -- [[Simonton]]<br />
<br />
== Security exception 1.6.0 ==<br />
<br />
One bot suffers from a security exception in v1.6.0, namely axebots.SilverSurfer.<br />
It seems the only bot that has this problem, so the impact is not that big. Maybe someone (or Axe himself) can update the bot so it can be processed by the latest robocode versions. --[[User:GrubbmGait|GrubbmGait]] 23:52, 22 September 2008 (UTC)</div>Simontonhttp://robowiki.net/w/index.php?title=Talk:RoboRumble/Reported_Problems&diff=3029Talk:RoboRumble/Reported Problems2008-09-22T16:35:18Z<p>Simonton: Repeated Battles</p>
<hr />
<div>== Repeated Battles ==<br />
<br />
Not sure if this is the best place to put this, but here it is. My roborumble client would keep getting hung up running the same bot over & over, regardless of how many battles it already had or how many other bots were below the <tt>BATTLES_PER_BOT</tt> limit I set. I think I took care of the problem by deleting files between between runs of the rumble. This is my <tt>roborumble.bat</tt> file now:<br />
<pre><nowiki><br />
:TOP<br />
java -Xmx256M -Dsun.io.useCanonCaches=false -cp libs/robocode.jar;libs/codesize.jar;libs/roborumble.jar roborumble.RoboRumbleAtHome ./roborumble/roborumble.txt<br />
del roborumble\temp\battles*<br />
del roborumble\temp\priority*<br />
GOTO TOP<br />
</nowiki></pre><br />
I think the priority battles file was the culprit, but I'm leaving the other line in for good measure. --[[User:Simonton|Simonton]] 16:35, 22 September 2008 (UTC)</div>Simontonhttp://robowiki.net/w/index.php?title=Talk:Toorkild&diff=3027Talk:Toorkild2008-09-21T18:02:26Z<p>Simonton: Typo/Grammar</p>
<hr />
<div>== Multiple Choice, You Say ... ==<br />
<br />
Great! Thanks for migrating this so it caught my attention! Now I know what I need to do in the micro category :). --[[User:Simonton|Simonton]] 14:35, 21 September 2008 (UTC)</div>Simontonhttp://robowiki.net/w/index.php?title=Talk:Toorkild&diff=3026Talk:Toorkild2008-09-21T14:35:05Z<p>Simonton: Multiple Choice, You Say ...</p>
<hr />
<div>== Multiple Choice, You Say ... ==<br />
<br />
Great! Thanks for migrating this so it caught my attention! Now I know what I need to in the micro category :). --[[User:Simonton|Simonton]] 14:35, 21 September 2008 (UTC)</div>Simontonhttp://robowiki.net/w/index.php?title=Talk:RoboResearch/Development&diff=3008Talk:RoboResearch/Development2008-09-21T05:35:05Z<p>Simonton: Showing Results</p>
<hr />
<div>== Showing Results ==<br />
<br />
I have already talked with some robocoders about how they would like to see results in the RoboResearch GUI. So far the best design I've come up with (merging ideas from [[Synapse]], [[Rednaxela]], [[Voidious]] and [[Chase-san]]) would open a separate window for each challenge+challenger. It would have a table that shows live-feed results like the summary on wiki pages. That window could be expanded to show a second table underneath the first, with the scores for each season. The top table could also be expanded to include a row for each version of the challenger in the database. Whichever version is selected in the top table is the one whose seasons would be displayed in the lower table. Can I get any feedback or new ideas? --[[User:Simonton|Simonton]] 05:35, 21 September 2008 (UTC)</div>Simontonhttp://robowiki.net/w/index.php?title=RoboResearch/Development&diff=3007RoboResearch/Development2008-09-21T05:28:31Z<p>Simonton: Update</p>
<hr />
<div>This page will keep the current design for the next phase(s) of [[RoboResearch]]. I'll keep this page as the "official" design; please use the discussion page to offer feedback and contribute new ideas. This page exists to solicit such input, so please don't be bashful!<br />
<br />
=== The GUI ===<br />
[[Image:RoboResearch.JPG]]<br />
<br />
This is the current development GUI for RoboResearch. In the top section you add and orginize which challenges will be run. All the buttons should be obvious except "Group". When you select multiple challenges and press group, they all get the same number in front of them (that's the group number). An effort will be made to complete the battles for all challenges in the same group at about the same time. As challenges complete, they will drop to the bottom of the list and, if they were the last in their group, all others' group numbers will decrement.<br />
<br />
In the bottom section you control what each of your concurrent battle-running threads does. The "Prefer Group" spinner means that if the stated group exists in the pane above, it will run battles from that group. If it does not, it will default back to running from group 1. So, for example, I could add the rumble as group 1 in the top section (once that functionality is available), then set my threads to prefer 1 and 2 as pictured above. One thread would then always run the rumble, and the other thread would run from challenges I add until they are all done, at which time it would default back to running the rumble.<br />
<br />
There will be a "Configure" button in the top section, too, which for the rumble could set things like MAX_BATTLES. After all bots in the rumble have that many battles, RoboResearch would consider that entry "done". You could add 2 rumble entries, one with unlimited battles and one with a max, to achieve things like "first run all bots up to 2000 battles, then run my challenges, then go back to the rumble again".<br />
<br />
What works:<br />
* Adding challenges<br />
* Removing challenges<br />
* Adding threads<br />
* Starting, pausing and killing threads<br />
* The "Prefer Group" feature<br />
<br />
To-Do:<br />
* Editing challenges in the queue<br />
* Showing results (minor detail)<br />
* Re-organizing the queue<br />
* Bulk thread operations<br />
<br />
=== Running Networked ===</div>Simontonhttp://robowiki.net/w/index.php?title=File:RoboResearch.JPG&diff=3006File:RoboResearch.JPG2008-09-21T05:14:00Z<p>Simonton: uploaded a new version of "Image:RoboResearch.JPG": Update</p>
<hr />
<div>Screen shot from an early development prototype of GUI for RoboResearch.</div>Simonton