Spring 2010 MATLAB Contest, April 28 - May 5
in [Matlab]
|
Prev: Single number into vector elements
Next: neural network
From: Alan Chalker on 5 May 2010 12:06 Just to pre-emptively respond to any comments about me flooding the queue at the end, I'd like to point to the following blog post from a week ago from Seth: http://blogs.mathworks.com/contest/2010/04/28/new-contest-website-features/#comment-6569 "Regarding the login requirements, there is no rule that a given player use only one login ID, but if we start giving awards for most prolific, or greatest improved, multiple IDs would hurt your chances. It might be interesting if your own submissions were competing for the top spot." And I'll also point to the newsgroup conversations from past contests, in particular: http://www.mathworks.com/matlabcentral/newsreader/view_thread/238684
From: Alan Chalker on 5 May 2010 12:13 "Helen Chen" <helen.chen(a)mathworks.com> wrote in message <hrs1kl$ovd$1(a)fred.mathworks.com>... > > Helen > ps. Time is always the time of submission. Helen: I'm glad to hear that. One of the tactics I tried yesterday morning was to wait until an entry of mine was in the lead, and the queue was empty, and then to fill the queue with lots of entries that take up almost the full 180 second limit (this was my Queue delay series of entries). The thought was that if it was scoring time that counts, those queue delay entries would significantly increase the time it took before other entries could be scored, artificially inflating my longevity time. Interestingly, Sergey seems to have been wondering what I was doing and resubmitted several of those entries, even further increasing the queue delay. I thought it important to publicly disclose this tactic now, and the fact that it doesn't actually help, in order to avoid anyone else from trying it in future contests and unnecessarily lengthening the queue processing time.
From: Oliver Woodford on 5 May 2010 12:25 "Alan Chalker" wrote: > Just to pre-emptively respond to any comments about me flooding the queue at the end, I'd like to point to the following blog post from a week ago from Seth: > > http://blogs.mathworks.com/contest/2010/04/28/new-contest-website-features/#comment-6569 True, but I'd like to post-emptively quote Ned's post from yesterday (http://blogs.mathworks.com/contest/2010/05/04/smaller-than-one-thousand/) which states "Sock puppet accounts are frowned upon". Consider this a stern frowning. :)
From: Sergey Y. on 5 May 2010 12:32 "Alan Chalker" <alancNOSPAM(a)osc.edu> wrote in message <hrs5eg$cgt$1(a)fred.mathworks.com>... > Interestingly, Sergey seems to have been wondering what I was doing and resubmitted several of those entries, even further increasing the queue delay. I thought it important to publicly disclose this tactic now, and the fact that it doesn't actually help, in order to avoid anyone else from trying it in future contests and unnecessarily lengthening the queue processing time. Actually I was using similar tactics, however differently. Couple times I strongly suspected that my code is better then current best. In that case I was trying to submit several submissions and then my code. That way code will be scored at earlier times, but becomes visible as best significantly later delaying start of your “tweaking machine gun” Then I saw your slow code and tested it for the same purpose.
From: Robert Macrae on 5 May 2010 12:38
"Oliver Woodford" <o.j.woodford.98(a)cantab.net> wrote in message <hrrcsu$a3j$1(a)fred.mathworks.com>... > > Robert, sounds like we're on the same wavelength here. You are suggesting, in more concrete form, an approach I have suggested a couple of times already. Indeed, my Super Slim entry implements the first stage of just such a method, but using two overlapping scans to get 9 times the resolution rather than your 4. I think it's definitely a winning approach, but like yourself I haven't the time to implement it fully. Hah! I liked the idea of using 3 or 4, but decided that I might hit problems with instability as sharp features would cause ripples two or 3 subareas away. Then I got bogged down in coding the edges and ran out of time; with hindsight I should not have hand-coded rectangular areas, the gain nothing like worth the hassle. I think overlapping regions like this are potentially a step forward, but as Nick comments below there are others that may be better... Robert Macrae |