Thread Subject: MATLAB Programming Contest: April 2 - 9, 2003

 Subject: MATLAB Programming Contest: April 2 - 9, 2003 From: Min Poh Date: 1 Apr, 2003 13:52:11 Message: 1 of 53 The next MATLAB Programming Contest starts tomorrow at 9 a.m. EST and will run until 5 p.m. EST on Wednesday, April 9. Topics and rules will be posted to the MATLAB Contest site tomorrow. http://www.mathworks.com/contest These contests are a great way to learn new programming tricks, as well as show off the ones you have. If you are curious to find out more about past MATLAB contests, visit the link above. Past contest pages are listed under the title "Previous Contests" on the main page. Please use this thread to talk about the contest, strategies, or to ask related questions. If you have an "administrative" type of question that you don't feel applies to anyone else, e-mail us at contest@mathworks.com. The contest will start tomorrow so be sure to set aside some time during the week to watch the contestants at work or to submit an entry. We'll be holding several mid-contest prize giveaways of MATLAB t-shirts, key chains, and mugs so don't wait until the last minute to participate. Good luck! Min Poh The MATLAB Central Team The MathWorks, Inc.
 Subject: MATLAB Programming Contest: April 2 - 9, 2003 From: Ghassan Hamarneh Date: 2 Apr, 2003 11:13:10 Message: 2 of 53 with "all the short straight-line distances are equal to one unit", I presume it is safe to assume that all x,y will be integers (data on a uniform rectilinear grid)? /Ghassan
 Subject: MATLAB Programming Contest: April 2 - 9, 2003 From: Mike Thomas Date: 2 Apr, 2003 11:24:14 Message: 3 of 53 That only applies to the simple example given in the Rules. Take a look at the testsuite.mat file provided in the download zip file, to see a sample of the x and y coordinates. There is no constraint to be integers. Mike > with "all the short straight-line distances are equal to one unit", I > presume it is safe to assume that all x,y will be integers (data on a > uniform rectilinear grid)? > > /Ghassan >
 Subject: MATLAB Programming Contest: April 2 - 9, 2003 From: Duan Date: 2 Apr, 2003 14:40:43 Message: 4 of 53 Hello, The example in rules seems has problem. The length from D to home is sqrt(5)+1 = 3.2. The truck only has 3 units of gas in D. The rule is "One unit of gas will move your truck exactly one unit of distance." How can the truck returns to home from D?
 Subject: MATLAB Programming Contest: April 2 - 9, 2003 From: Lucio Date: 2 Apr, 2003 14:57:43 Message: 5 of 53 Hello Duan sqrt(5)+1 is the distance from C to Home passing by D 1 for C to D sqrt( 1^2 + 2^2) for D to home Duan wrote: > > > Hello, > The example in rules seems has problem. The length from D to home is > sqrt(5)+1 = 3.2. The truck only has 3 units of gas in D. The rule is > "One unit of gas will move your truck exactly one unit of distance." > How can the truck returns to home from D? >
 Subject: MATLAB Programming Contest: April 2 - 9, 2003 From: Mike Thomas Date: 2 Apr, 2003 14:56:00 Message: 6 of 53 The distance from D to home is only sqrt(5) = 2.2, so you do have enough fuel to get home. The distance of sqrt(5)+1 in the rules is in reference of the trip from C to D to home. Mike > Hello, > The example in rules seems has problem. The length from D to home is > sqrt(5)+1 = 3.2. The truck only has 3 units of gas in D. The rule is > "One unit of gas will move your truck exactly one unit of distance." > How can the truck returns to home from D? >
 Subject: MATLAB Programming Contest: April 2 - 9, 2003 From: Ken Crounse Date: 2 Apr, 2003 17:28:13 Message: 7 of 53 For the general use: the scoring constants k1,k2,k3 are the same as the last contest: 1,1/7,1/20 (found by using LSQCURVEFIT ) The constant score contours can be viewed with: % plot scoring constant contours [result,runtime] = meshgrid(1700:10:3500,0:180); k = [1 1/7 1/20]; score = k(1).*result+k(2).*exp(k(3)*runtime); contour(1700:10:3500,0:180,score,20); xlabel('result'); ylabel('run time');
 Subject: MATLAB Programming Contest: April 2 - 9, 2003 From: Duane Hanselman Date: 3 Apr, 2003 09:28:12 Message: 8 of 53 Min Poh wrote: > > > The next MATLAB Programming Contest starts tomorrow at 9 a.m. EST and will > run until 5 p.m. EST on Wednesday, April 9. Topics and rules will be > posted > to the MATLAB Contest site tomorrow. > > > > These contests are a great way to learn new programming tricks, as well as > show off the ones you have. I disagree that "these contests are a great way to learn new programming tricks." They are much better at promoting the development of poor programming practices. Given the lack of comments, submitted code is next to impossible to understand unless one takes the time to decipher what each line does and what the overall strategy of a given solution is. Like most folks, I have a day job that does not allow me the time to be an active observer of the contest, let alone be a viable contributor. Are the contests fun? Yes, but let's not promote them as being something they are not. If you were managing the development of MATLAB code, would you encourage your programmers to adopt the programming practices demonstrated by these MATLAB contests? The only thing I've learned about this contest so far is that xy = (x-x(1)) + 1i*(y-y(1)); is better than xy = (x-x(1)) + i*(y-y(1)); That is, 1i tells the MATLAB interpreter immediately that one wishes to multiply by sqrt(-1), whereas using i forces MATLAB to first check to see if i has been redefined as a variable other than sqrt(-1).
 Subject: MATLAB Programming Contest: April 2 - 9, 2003 From: Frank Hirsh Date: 3 Apr, 2003 15:14:44 Message: 10 of 53 Dear Ed! I suggest not to quote the full mail you are replying to, especially in a blog! Kind regards, Frank
 Subject: timing From: Stijn Helsen Date: 3 Apr, 2003 16:05:41 Message: 11 of 53 Everytime I do this remark. There was just someone who took the lead with a copy of another : Nextnextsafe (a copy of RAUNoster_89 apart from a blank line). The difference in CPU time is 2.7 s! That is a big difference. Stijn
 Subject: timing From: Matthew Simoneau Date: 3 Apr, 2003 18:08:43 Message: 13 of 53 Stijn Helsen wrote: > There was just someone who took the lead > with a copy of another : Nextnextsafe (a copy of RAUNoster_89 apart > from a blank line). The difference in CPU time is 2.7 s! That is a > big difference. The contest has always been sensitive to timing. Disk access time, memory thrashing, and other system activity can randomly affect the entry. The lead can even change because of this. We've tried to reduce the effect as much as possible by taking measures such as pre-loading the submission before starting the timing. I am, however, surprised to see such a big difference. I expected it to be an order of magnitude smaller. We're looking into this to see what we can improve. Thanks.
 Subject: MATLAB Programming Contest: April 2 - 9, 2003 Date: 3 Apr, 2003 19:26:49 Message: 14 of 53 I noticed the parameter 1.09 in the code used by some of the best entries. Can someone tell me what is the significance of that particular number? I found empirically that varying the parameter either up or down results in a worse raw score, so it is clearly optimized, but I don't understand why this rather arbitrary-looking number is so special.
 Subject: timing From: Stijn Helsen Date: 4 Apr, 2003 01:12:07 Message: 15 of 53 > I am, however, surprised to see such a big difference. I expected it > to be an order of magnitude smaller. We're looking into this to see > what we can improve. You can also look to the difference between AddFreight5 and AddFreight5_0. The last one does less and lasts 8 seconds longer! When I do it here (with matlab 6.5) I get timing results which are closer to my expectation : a small difference between the two (and the second a bit faster), and a variance of some 0.1s (the same as you expected). I'm interested in results of your search (not just for this contest). Regards, Stijn
 Subject: timing From: Ave Date: 4 Apr, 2003 10:44:11 Message: 16 of 53 "Stijn" == Stijn Helsen writes:  Stijn> Everytime I do this remark. There was just someone who took  Stijn> the lead with a copy of another : Nextnextsafe (a copy of  Stijn> RAUNoster_89 apart from a blank line). The difference in  Stijn> CPU time is 2.7 s! That is a big difference. Oops, Nextnextsafe was supposed to be different from RAUNoster_89, but apparently I fumbled the submission... Ave
 Subject: timing From: Heinrich Acker Date: 4 Apr, 2003 03:50:48 Message: 17 of 53 Matthew Simoneau wrote: > I am, however, surprised to see such a big difference. I expected it > to be an order of magnitude smaller. We're looking into this to see > what we can improve. > > Thanks. Another example: The same change was made for Home sweet home -> Home sweet home+ AddGasFreight -> AddGasFreight+ So does this change cost 7.74s or save 0.18? Heinrich
 Subject: MATLAB Programming Contest: April 2 - 9, 2003 From: Klaus Quiet Date: 4 Apr, 2003 04:54:33 Message: 18 of 53 In fact, I made a few variations myself, and the best value is dependant of the test suite. 1.089, as I found out empirically seems to work best with the unknown test suite used for the contest while the optimum for the test suite in trucking.zip is different. Klaus "Md" Quiet cyclist wrote: > > > I noticed the parameter 1.09 in the code used by some of the best > entries. Can someone tell me what is the significance of that > particular number? > > I found empirically that varying the parameter either up or down > results in a worse raw score, so it is clearly optimized, but I don't > understand why this rather arbitrary-looking number is so special. >
 Subject: timing From: Ave Date: 4 Apr, 2003 14:42:49 Message: 19 of 53 Interesting... Removing abs reduced time in my machine (AMD Athlon 1GHz, Linux, Matlab 6.5.0.180913a) from 34s to 28s, but increased time in Mathowrks contest machine from 90 to 97s, It's not easy to optimise speed... With abs:  xy = x + 1i*y;  [X,Y]=meshgrid(xy);  dist = abs(X-Y); Without abs:  dist=zeros(n);  for i1=1:n   dist(:,i1)=sqrt((x-x(i1)).^2+(y-y(i1)).^2);  end Ave
 Subject: global stratergy From: Stijn Helsen Date: 4 Apr, 2003 08:08:36 Message: 20 of 53 Garron wrote: > > > Here's an idea for a global strategy: > > ..... I'm not sure, I haven't really looked to the code. But rather in the beginning there were some submissions "building lego blocks"(??). When I saw that title I thought it could be something described here.  I think all those submissions failed because of time. But I suppose people were allready thinking about this.... Stijn
 Subject: Contest Home Diagrams From: Ned Gulley Date: 4 Apr, 2003 12:43:31 Message: 21 of 53 Heinrich Acker wrote: > it seems that there is something wrong with at least one diagram on > the contest homepage. Hello Heinrich: The "normalized log plots" you're referring to are meant to be purely qualitative. We're doing something fairly simple-minded to emphasize recent progress. In each case we subtract the lowest score from all the scores, and then we add an offset to keep the log plot happy. In one plot we add 100, and in the other we add 1. We'll fix it up so they use the same offset, but in the meantime, keep in mind that it's a qualitative plot that is intentionally skewed to make recent progress obvious. The "percent improvement" plot is more usefully quantitative, as you point out. -Ned Gulley. The MATLAB Contest Team
 Subject: Downloadable vs. Remote Test Suite From: E. Brian Welch Date: 4 Apr, 2003 16:46:56 Message: 22 of 53 Not to complain, but I noticed that the likely early bird winner MadMax2 performs significantly worse on the downloadable test suite than my own entry (1855.643K vs. 1837.522K), but then MadMax2 does better with the official on-line test suite (2058.166K vs. 2060.954K). I agree that the official test suite is the true contest measure, but what could account for such a disparity? Maybe just one or two special cases? Brian
 Subject: Downloadable vs. Remote Test Suite From: Matthew Simoneau Date: 4 Apr, 2003 18:54:20 Message: 23 of 53 E. Brian Welch wrote: > Not to complain, but I noticed that the likely early bird winner > MadMax2 performs significantly worse on the downloadable test suite > than my own entry (1855.643K vs. 1837.522K), but then MadMax2 does > better with the official on-line test suite (2058.166K vs. 2060.954K). As the contest continues, the entries tend to become specifically tuned to the test suite. We try to limit this by having a large number of test cases in the suite, but it is inevitable. > I agree that the official test suite is the true contest measure, but > what could account for such a disparity? Maybe just one or two > special cases? This time around we didn't put any strange special cases in the test suite. We wrote some code to randomly generate a test suite. We ran it once to create the actual test suite, and then again to create the sample test suite.
 Subject: Downloadable vs. Remote Test Suite From: E. Brian Welch Date: 4 Apr, 2003 22:57:03 Message: 24 of 53 Matthew Simoneau wrote: > > As the contest continues, the entries tend to become specifically > tuned to the test suite. We try to limit this by having a large > number of test cases in the suite, but it is inevitable. > Thanks Matthew for the explanation. The difference between the test suites does make it more difficult to steal good entries from the queue like I was. I had my own small score improvement to add, but I was sitting there watching the queue and testing entries that popped up. I only had a chance of beating 'MadMax2' because I stole 'SwapRoute' (sorry Claus). Maybe it would be a good idea for new entries to not be viewable until they have a score. But hey, I was just trying to finally be a legitimate winner. This contest seems to be insulated well against cheating. I surrender. Brian
 Subject: score-difference (testsuite<->suite) From: Stijn Helsen Date: 5 Apr, 2003 00:05:53 Message: 25 of 53 Concerning those differences of scoring results. If you compare the scores (testcase/testcase) of two submissions. You can see the big individual differences, positive and negative. That means that the total (or mean) of those individual scores can vary a lot. So I think that those differences of scoring results for the testsuite and final suite are normal. Stijn
 Subject: score-difference (testsuite<->suite) From: Hannes Naudé Date: 5 Apr, 2003 06:37:11 Message: 26 of 53 I had another query which might be relevant to this discussion. I was looking at the code for runcontest when I noticed a peculiarity in the scoring system. It seems that a solution that runs out of fuel is not disqualified (as I assumed) but the score generated is simply that for no freight returned and no fuel returned. This is actually better than the score that [1 1] generates since it returns fuel but no freight. I made the obvious changes to the entry which was leading at the time to improve the performance and saw significant improvement on the sample suite but a poorer result on the test suite. I can think of only two reasonable explanations for this 1. A bug in my code (likely) 2. The online scoring system has been updated to score out-of-gas entries more fairly. Another thing I noticed (and tried to exploit) is the fact that the gas penalty is based on remaining gas at the end rather than total collected gas as everyone seems to have assumed. This can have drastic impact on code along the lines of swaproute, since if the route is made shorter but no extra stops can be added the score actually becomes worse since more fuel is left at the end. I hope someone else can make better use of this knowledge than I have been able to. Hannes Naudé / RAU team
 Subject: score-difference (testsuite<->suite) From: Hannes Naudé Date: 5 Apr, 2003 08:20:30 Message: 27 of 53 Stijn Helsen wrote: > g = cumsum(a(c(1:end-1),4)); > .... g(end) > So that means sum(a(c(1:end-1),4))). I think that that the total gas > is and not the remaining. > > Agree? > Stijn Yes I agree. Stupid mistake on my part. As to running out of fuel. I just did a little experiment. I modified the sample entry to look as follows function c = solver(a) n=size(a,1) c = [1:n 1]; and the raw score went from 4913K to 4922K (ie. got worse). On my system the score went from 4906K to 4887K (ie. got better). To me this looks like conclusive proof that the scoring works different on the online and local versions of runcontest. But I might be wrong (again). While I'm rambling I might as well ask wether any of the old hands at this contest know of a nice program to quickly compare two files under windows (to see what mods were made) as searching for the tweaks becomes prohibitively time consuming and if you just mod a mod you haven't learnt anything. Thanks Hannes Naudé / RAU Team
 Subject: score-difference (testsuite<->suite) From: Stijn Helsen Date: 5 Apr, 2003 07:31:08 Message: 28 of 53 Hannes Naudé wrote: > Another thing I noticed (and tried to exploit) is the fact that the > gas penalty is based on remaining gas at the end rather than total > collected gas as everyone seems to have assumed. This can have > drastic impact on code along the lines of swaproute, since if the > route is made shorter but no extra stops can be added the score > actually becomes worse since more fuel is left at the end. > Is it? I read : g = cumsum(a(c(1:end-1),4)); .... g(end) So that means sum(a(c(1:end-1),4))). I think that that the total gas is and not the remaining. Agree? Stijn
 Subject: filediff From: Stijn Helsen Date: 5 Apr, 2003 08:27:32 Message: 29 of 53 > While I'm rambling I might as well ask wether any of the old hands at > this contest know of a nice program to quickly compare two files > under windows (to see what mods were made) as searching for the > tweaks becomes prohibitively time consuming and if you just mod a mod > you haven't learnt anything. If I'm working on Windows (that is at work ("illegally playing")), I'm using a program which was included in the MS-VisualC++ package. (Here at home on my Mac I'm using BBEdit.) I haven't look for it, but I would think that such a program can be found on the internet. (And I think it is a necessary tool in this contest, at least very very useful.) I wish you good luck. (Is it a big team ?) Stijn
 Subject: filediff From: Hannes Naudé Date: 5 Apr, 2003 09:42:25 Message: 30 of 53 > I wish you good luck. (Is it a big team ?) > > Stijn > No, when we're at max strength we're 3. We're postgrad engineering students and this is much more fun than working on our dissertations. Most of the time its just me, however. My fiance is understandably getting a bit agitated over my addiction to this "game". Good luck to you too and thanks for the info. Hannes Naudé
 Subject: Learning from MATLAB Contest / Commenting entries From: Heinrich Acker Date: 5 Apr, 2003 14:46:54 Message: 31 of 53 Dear Contestants and MATLAB Contest Team, it has been criticized that many of the contest entries are unreadable and therefore it is difficult to follow the contest, even more difficult to learn from it. Although everybody knows that it would be good to add a lot of comments to the code, few contestants take the time. That's not surprising, one has to be quick in this competition. I would like to suggest a way to improve this in the next contest, with the current contest as the example. Imagine the function call of the solver would be function path = solver(x, y, freight, gas, n) with the obvious meanings of the parameters; instead of the current function c = solver(a) In that way, there would be a common basis for all submissions, one that will even not be dropped when tweaking for milliseconds. The work will essentially be the same, as nobody of us is challenged e.g. by the line n=size(a,1). Of course, this will not make it much easier to follow, just a bit, but this improvement is easy to implement. Regards, Heinrich
 Subject: some questions and some waffle From: Stijn Helsen Date: 5 Apr, 2003 16:42:36 Message: 32 of 53 Hi Nathan > I don't really understand how the random number generator works. If a > code depending on some random influence is submitted more than once, > is it guaranteed to produce the same results? This seems to be the > case. That is done on purpose. The random generator is reset, so that every submission has the same (random) luck (or unluckiness) when using random numbers. > Well, this is my first matlab contest and it is giving me far too > much enjoyment. It's one of the most addicitve and compulsive things > I have tried. The exercise is improving my programming skill - true - > but in return I have neckache, backache, a terrible diet, no social > life, and not much of a work life either. Also, I have experienced > physical trembling while making the final preparations to send a code > into the pit. Is that normal? I recognise the things you describe (and I think my wife and children too, and I'm lucky my boss isn't looking over my shoulder whole the time...). > There seems to be a lull in activity at the moment. Are you all > brewing up something special? Or enjoying your saturdays like normal people? Or a combination of the two.... Stijn (Alken - Belgium)
 Subject: rand('state',J) From: Christian Ylämäki Date: 6 Apr, 2003 10:46:06 Message: 33 of 53 Regarding my comment about removing the ability to use rand('state',J).   11093 I don't think that it is nessesary because eventually better programs will come that is less dependent on random numbers.
 Subject: duration of contest From: Stijn Helsen Date: 6 Apr, 2003 17:22:41 Message: 34 of 53 Hi, The discussion has been done a couple of times, but I want to start again. 8 days of a contest of this type (not very important, but "addictive") is long. I had the same last contest. I can't stop, but I'm also not so interested in "working" for three days on this (so that I can't do real work). If it is necessary to have a weekend during the contest I propose to do it from Thursday to Monday or from Friday to Tuesday. Stijn
 Subject: duration of contest From: Nathan Date: 6 Apr, 2003 17:49:16 Message: 35 of 53 I agree. Stijn Helsen wrote: > > > Hi, > The discussion has been done a couple of times, but I want to start > again. 8 days of a contest of this type (not very important, but > "addictive") is long. I had the same last contest. I can't stop, but > I'm also not so interested in "working" for three days on this (so > that I can't do real work). > If it is necessary to have a weekend during the contest I propose to > do it from Thursday to Monday or from Friday to Tuesday. > > Stijn >
 Subject: Stack / function calls From: Hannes Naudé Date: 7 Apr, 2003 03:52:59 Message: 36 of 53 Another query: I notice that the two depth first searches turbodiesel and enumerate by Stijn were both implemented using an explicit stack. Is this due to experience in previous contests, that indicate that this is faster than using recursion?? I'm considering implementing a recursive version but seeing as this is probably the easier option anyway, I figure there must be a reason why no-one has done it?? Thanks Hannes Naudé / RAU Team
 Subject: Stack / function calls From: Stijn Helsen Date: 7 Apr, 2003 04:36:41 Message: 37 of 53 Hi, I've implemented that enumeration first recursive. That had bad timing results. It is especially because a lot of memory is used. If it is about variables which are not changed (constants) it is ok, they are (implicitely) used "by reference". But a lot of arrays are changed (for example an "avail"-variable). Probably it could be done better than as I've done that (for example using global variable), but still I don't think it will be better then the "flat" way. Another reason why I did it, is that it is easier for a "fast-exit". Still another (unused) reason was that other things could be done during "backtracking". But, if you think it could be done better..., good luck with it. Stijn
 Subject: fgbest<-->fgsbest From: Stijn Helsen Date: 7 Apr, 2003 04:50:25 Message: 38 of 53 In the comment of Td lazy, it is written "is fgbest ever better than fgsbest???". Now it is true. In earlier versions findenum gave the two sets of outputs. They were optimized separately. That gave better results, but worse CPU-time. It is still possible that better things can be done with the "long but not-yet-so-good" result then with the "short and currently-best" result. Stijn
 Subject: some questions and some waffle From: Peter Boettcher Date: 7 Apr, 2003 18:23:26 Message: 40 of 53 nathan writes: > Still on the topic of tweaking, do you all think it would be a good > idea to declare a "second winner" based on some formula involving > percentage step improvements? Tweaking is a fine art and should > rightly be rewarded, but it would be nice to give recognition to > developers of major new code too. On this topic I thought it would be a neat idea to run the contest in two phases. The first phase would allow original submissions only. No viewing of others' code at all. A winner would be chosen at the end of phase 1. Then all submissions would be opened for viewing and resubmission, so the best possible entry could evolve. -- Peter Boettcher MIT Lincoln Laboratory MATLAB FAQ: http://www.mit.edu/~pwb/cssm/
 Subject: thoughts about the contest (long) From: Duane Hanselman Date: 7 Apr, 2003 22:24:17 Message: 41 of 53 Ned Gulley wrote: > > > Here are some thoughts (this post is long) about the contest. >  Duane Hanselman has suggested > that we simply do an old-style contest where you mail in one entry > and run them all once. Would you like to see that? Not true. That would be just as bad as the current approach. Please reread my post. The best contest finds a balance between the current instant availability of code submissions and a totally closed contest as you incorrectly attributed to me above. Both extremes lead to a less than ideal contest. How about holding individual entries for 24 hours and keep the contests going as long as they are now. That way an individual can submit multiple refined entries over a 24 hour time period before anyone else sees even their first submission. That way a person can tune their code quite a bit before having others borrow from it. The first day of contests would be private, but privacy would disappear as more and more submissions become public in later days. Early privacy would encourage more people to submit. As it is now, the pool of potential submitters rapidly decreases as submissions are minded for their strengths and the code becomes too complicated for those who cannot spend the time to bury themselves in it. I'm glad that you are willing to say that the purpose of the contests is "fun" as opposed to them being "a great way to learn new programming tricks, as well as show off the ones you have" as stated by Min Poh in the first posting in this thread. Your statement more accurately reflects reality. No one beyond the small number of active submitters can decipher the winning submission without spending undue time figuring out what is going on. Duane Hanselman Mastering MATLAB 6
 Subject: timing From: Yi Cao Date: 8 Apr, 2003 08:26:52 Message: 42 of 53 Matthew Simoneau wrote: > > I am, however, surprised to see such a big difference. I expected it > to be an order of magnitude smaller. We're looking into this to see > what we can improve. > Even worse, my submission, "BugFix" has been failed due to timed out (over 180 seconds). However, the same code resubmitted with name "Unbelievable CPU time" has got CPU time only 96.598 seconds.
 Subject: thoughts about the contest (long) From: MR Keenan Date: 8 Apr, 2003 09:40:59 Message: 43 of 53 It may help to determine the "winner" more accurately if you hide the entries in the queue in the last 1 hour of the contest. But, on the whole, the contest structure is good. I think the quality of the contest is very dependent on the quality of the problem. The current problem is a little dull, but that is a matter of taste. It is certainly more difficult for me to understand the algorithms that have been posted so far than previous contest algorithms, but maybe it's just me (and a very busy work schedule, unfortunately!). Certainly, those CPU issues should be looked into.
 Subject: Difference Plot From: Matthew Simoneau Date: 8 Apr, 2003 13:34:03 Message: 45 of 53 It's hard to pick out which entries are introducing significant new code. To help with this, I just added a new "Difference from Leader". It naively diffs the last 100 entries against the current leader and color codes each by its percent-difference. Mousing over, on most browsers, will show you a tooltip with the entry's author and title. Clicking on it will take you to that entry.
 Subject: thoughts about the contest (long) From: Hiu Chung Law Date: 10 Apr, 2003 17:47:11 Message: 49 of 53 Randomized algorithm is one important type of algorithms for solving hard problem, and banning its use may not be a good idea. Heinrich Acker wrote: > 2. Block any random command, because the contest is about developing > an algorithm, not about gambling. This would also kill some > difficult-to-follow tweaking and test-suite-fitting.
 Subject: Roger Stuckey's comments From: Roger Stuckey Date: 10 Apr, 2003 19:00:21 Message: 50 of 53 Matthew Simoneau wrote: > > > Don't miss Roger Stuckey's comments. They're on a new thread: > > Roger Stuckey "More thoughts" 4/10/03 > 12:49am > Sorry, I hit the wrong button... Doh! Here's the link if anyone's interested: Roger Stuckey "More thoughts" 4/10/03 12:49am Roger
 Subject: thoughts about the contest (long) From: CDMA RF Eng Date: 12 Apr, 2003 09:50:40 Message: 51 of 53 If the decision is made to shorten the contest, how about posting the whole problem statement, sample code, and testsuite a week before the queue opens up? Then folks have a chance to get their minds wrapped around the problem by testing their own algorithms at home, form up a private team, etc. When the queue opens, the serious players can hit the ground running with well thought out algorithms. There would still be time for widespread collaboration via the open source viewing we have in the current rules. The idea of not allowing the top few entries to be viewed is kind of interesting, but has the potential to seriously change the dynamics of the contest. Pat
 Subject: thoughts about the contest (long) From: Hannes Naudé Date: 14 Apr, 2003 17:53:11 Message: 52 of 53 We all know how much fun a completely open contest is. On the other hand some argue that this format does not give enough acknowledgement to the algorithm architects since crafting a new algorithm requires hours and (if it works out) probably only lands the author on top for a few minutes since tweaking can be done quite quickly. In my opinion however, the biggest drawback of the open format is the fact that it induces a significant amount of "groupthink". Since we all read the same (leading) entries we all start to think in the same way and a lot of the diversity inherent in having hundreds of people with different backgrounds from all over the world work on the same problem is lost. In this context I quote Pat > If the decision is made to shorten the contest, how about posting the whole > problem statement, sample code, and testsuite a week before the queue opens > up? Great idea! (One could even have the queue open but private ie. you can test run your code to make sure all is well but the results are not visible to everyone). I suspect many a great algorithm has gone unimplemented because the person who came up with it was too busy following the queue and tweaking. On the other hand tweaking is a big part of the contest experience and if it is lost (by not making the code of leading entries available for instance) the contest will a lot of its popularity. This kind of split approach could force contestants to take a long hard think about the problem before getting sucked into the game and tweaking for milliseconds. Ideally one would then award the early bird prize immediately before actually opening up the queue for public viewing. This would amount to a prize for the best individual contribution. Once the queue opens for public viewing, the great diversity of different approaches present, (since all contributions were made independently) would provide the most hardened tweaker with hours of good "entertainment" and the final result would probably be better than that obtained with a week long entirely open contest. Hannes

Everyone's Tags:

Separated by commas
Ex.: root locus, bode

What are tags?

A tag is like a keyword or category label associated with each thread. Tags make it easier for you to find threads of interest.

Anyone can tag a thread. Tags are public and visible to everyone.