Spring 2010 MATLAB Contest, April 28 - May 5
in [Matlab]
|
Prev: Single number into vector elements
Next: neural network
From: Oliver Woodford on 30 Apr 2010 18:58 "Oliver Woodford" wrote: > The question this poses is which region to split next. You want to split regions that are textured, so you get more information out; splitting a textureless region gains you nothing. I believe that improving this decision process is where the real improvements will come in this contest. Incidentally, I started work on a method that tries to focus on regions where the gradient is not spatially linear. Since regions with linear gradient are well reconstructed by the post-processing smoothing step, splitting them up is wasted effort. However, I couldn't get it to work well. Perhaps someone else will... Oliver
From: Oliver Woodford on 30 Apr 2010 19:22 "Oliver Woodford" wrote: > I made sure my queries gave a unique and exact solution for the sum of each region, the regions being the intersections of all query masks. Given n queries that means I can only solve this uniquely for n (or fewer) regions - any more regions and you need regularization. Lastly (really), num regions >> queryLimit (by having queries overlapping many other queries) combined with regularization/Bayesian inference could well prove to be another rich vein for improvement. It's what all the cutting edge compressive sensing algorithms do, after all. The only problem is squeezing it all into 180 seconds! Oliver
From: Amitabh Verma on 1 May 2010 11:54 Why is the node count affecting the score. I thought it didn't matter in computing the final score. #1 less nodes? srach 14184133 57.361 28378.3 (cyc: 14, node: 2959) http://www.mathworks.com/matlabcentral/contest/contests/2/submissions/1472 #2 *linear cycler the cyclist 14184133 57.216 28378.6 (cyc: 14, node: 3263) http://www.mathworks.com/matlabcentral/contest/contests/2/submissions/1464 Even though the computing time is more in less nodes? just because of the lesser node count it ranks above. Also I had seem some entries where the complexity at 10 resulted in no score variation to an entry and same code with a higher than 10 complexity. Any thoughts ?
From: srach on 1 May 2010 14:39 "Amitabh Verma" <amtukv(a)gmail.com> wrote in message <hrhiqs$l63$1(a)fred.mathworks.com>... > Why is the node count affecting the score. I thought it didn't matter in computing the final score. > > #1 less nodes? srach 14184133 57.361 28378.3 (cyc: 14, node: 2959) > http://www.mathworks.com/matlabcentral/contest/contests/2/submissions/1472 > > #2 *linear cycler the cyclist 14184133 57.216 28378.6 (cyc: 14, node: 3263) > http://www.mathworks.com/matlabcentral/contest/contests/2/submissions/1464 > > Even though the computing time is more in less nodes? just because of the lesser node count it ranks above. > > Also I had seem some entries where the complexity at 10 resulted in no score variation to an entry and same code with a higher than 10 complexity. > > Any thoughts ? It is stated in the rules that the node count contributes to the score: http://www.mathworks.com/matlabcentral/contest/contests/2/rules#notes Regards srach
From: Alan Chalker on 2 May 2010 11:18
I have been able to figure out the scoring formula and am posting it here as I traditionally do. As usual, it’s very similar to the recent contests: score = k1*result + k2*e(k3*runtime) + k4*max(complexity-10,0) + k5*nodes Where: k1 = 0.002 k2 = 0.01 k3 = 0.1 k4 = 1 k5 = 0.001 The current leading entry has a time of 77s, result of 14064009, cyc of 23, and nodes of 3537. Here’s a breakdown of the current tradoffs: -cyc and score are a 1:1 ratio (i.e. each point shaved off cyc is a point shaved off the score) -time and score are a 1:2.2 ratio -result and score are a 1:0.002 ratio -node and score are a 1:0.001 ratio As is common at this point in the contest, Abhisek Ukil’s entries have already settled in just below the ‘knee’ of the time exponential curve, which is rather flat until about ~85s. However, because of results are so high right now and change quite a bit with small tweaks, I think we are going to find more payoff in trying to reduce the results by processing the images for a bit longer, at least until the times get up around the 95s range. Unfortunately that also means that during the various contest end times the queue is going to get very backlogged, since each entry will take several minutes to execute. |