Yi Cao currently has the best result, having nudged his entry wakingup to push down to around 38664. Unfortunately, getting this result uses up nearly three full minutes, so the resulting time penalty keeps the final score from being competitive in the main contest. That’s why we’re going to run a challenge to see who can get the lowest result. For this challenge, you won’t be penalized for complexity or timing. If you can run in less than three minutes, your entry is valid. Best result by an entry submitted before 4 PM today (EDT) wins the prize.
Keep in mind that the Tuesday Leap Challenge is still running until midnight tonight.
Also be sure and read Lucio’s insightful midcontest analysis. He made some custom graph theoretic flow charts that are both fun and extremely informative.
Since there are still over 100 entries in the queue prior to the 4PM challenge cutoff, which by my estimates will take over 5 hours still to clear (~2AM), I thought I’d post an analysis of the score vs time tradeoff.
The current leading entry from MikeR has a score of 3947 (res=39301, time=42.5s). The current best result entry is from SY, with a result of 38587 and a time of 175 secs has a score of 16500.
In order to turn this into the winning entry, the TIME would have to be reduced from 175 s to 75 s (a 64% drop in time) it’s impossible to simply reduce the result further and take the lead with such a long entry.
An entry with a result of 1 (which is obviously impossible) would be able to take the lead with a time of ~ 151 secs.
Here’s my attempt at a table showing some of the key ‘break even’ points across the timing spectrum (all scores ~3947)
Time Res
151 1
146 10000
123 30000
108 35000
86 38000
60 39000
50 39230
42.5 39302
Strange bug in the comments. It seems to be trying to filter out anything that has a left or right carat and a dash as a html tag. Here is the table without the carat and dash
Time Res
151 1
146 10000
123 30000
108 35000
86 38000
60 39000
50 39230
42.5 39302 - current leader
30 39400
20 39425
10 39440
1 39450
We are in an interesting ’sweet spot’ right now on the leaderboard. Each .1 secs of time is equal to .85 points of results.
Leave a Reply
About
The MATLAB Programming Contest is a semi-annual competition where contestants submit MATLAB code to try to solve a challenge. For more information, see the overview.
Since there are still over 100 entries in the queue prior to the 4PM challenge cutoff, which by my estimates will take over 5 hours still to clear (~2AM), I thought I’d post an analysis of the score vs time tradeoff.
The current leading entry from MikeR has a score of 3947 (res=39301, time=42.5s). The current best result entry is from SY, with a result of 38587 and a time of 175 secs has a score of 16500.
In order to turn this into the winning entry, the TIME would have to be reduced from 175 s to 75 s (a 64% drop in time) it’s impossible to simply reduce the result further and take the lead with such a long entry.
An entry with a result of 1 (which is obviously impossible) would be able to take the lead with a time of ~ 151 secs.
Here’s my attempt at a table showing some of the key ‘break even’ points across the timing spectrum (all scores ~3947)
Time Res
151 1
146 10000
123 30000
108 35000
86 38000
60 39000
50 39230
42.5 39302
Oops.. my table got cutoff:
Time Res
151 1
146 10000
123 30000
108 35000
86 38000
60 39000
50 39230
42.5 39302
Strange bug in the comments. It seems to be trying to filter out anything that has a left or right carat and a dash as a html tag. Here is the table without the carat and dash
Time Res
151 1
146 10000
123 30000
108 35000
86 38000
60 39000
50 39230
42.5 39302 - current leader
30 39400
20 39425
10 39440
1 39450
We are in an interesting ’sweet spot’ right now on the leaderboard. Each .1 secs of time is equal to .85 points of results.