Path: news.mathworks.com!not-for-mail
From: <HIDDEN>
Newsgroups: comp.soft-sys.matlab
Subject: Re: MATLAB Central Spring Contest
Date: Mon, 12 May 2008 14:34:02 +0000 (UTC)
Organization: The MathWorks, Inc.
Lines: 39
Message-ID: <g09kgq$ldb$1@fred.mathworks.com>
References: <fv82i0$nql$1@fred.mathworks.com> <fvsk1d$m84$1@fred.mathworks.com> <fvsmhv$se6$1@fred.mathworks.com> <fvsot0$gr9$1@fred.mathworks.com> <fvsqp9$8gg$1@fred.mathworks.com> <g066qs$drt$1@fred.mathworks.com> <g08tt2$c2b$1@fred.mathworks.com>
Reply-To: <HIDDEN>
NNTP-Posting-Host: webapp-02-blr.mathworks.com
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Trace: fred.mathworks.com 1210602842 21931 172.30.248.37 (12 May 2008 14:34:02 GMT)
X-Complaints-To: news@mathworks.com
NNTP-Posting-Date: Mon, 12 May 2008 14:34:02 +0000 (UTC)
X-Newsreader: MATLAB Central Newsreader 870024
Xref: news.mathworks.com comp.soft-sys.matlab:467916


Contest team, I haven't said it yet, so thanks for running
another great contest! I'm already looking forward to the
next with some of the changes that have been mentioned here.

Speaking of those changes, here's my take on many of items
that have been brought up...

Ideas I like:
    1. Rate limiter.
    2. Longer twilight.
    3. 1000 nodes instead of 1000 characters. (Although
maybe 1000 is too large. Maybe a 500 node challenge?)
    4. Can't view entries until they are scored.
    5. Mid-contest and end-of-contest analyses. I know it is
a lot of work, but I always find them interesting and
sometimes helpful in developing my own code.

Ideas I'm not sure about:
    1. One hour twilight before all contest deadlines. This
may cause people to only submit code right before deadlines,
which would make the rest of daylight pretty boring. If
twilight is only added at the very end of the contest, then
the phases become darkness, dawn, daylight, and dusk.
    2. Random rand seed. Random numbers *can* have a place
in legitimate entries, and I feel pretty strongly that an
entry should give the same score every time it runs.
However, this would eliminate one type of magic number tuning.
    3. Quantize run time in the scoring equation. This
minimizes the impact of tiny speed tweaks and run time
variation, but quantization boundaries will always be a problem.

Ideas I'm against:
    1. Some other method of computing a generality score. No
matter how you do it, tweaking can optimize entries for the
new score computation.
    2. Reduce the weight of time in the score. It's more
interesting to balance time vs. performance, rather than
just go for performance.