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:40 "Sergey Y." <ivssnn(a)yahoo.com> wrote in message <hrs6i4$qhg$1(a)fred.mathworks.com>... > > 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. That's an excellent counter-tactic! I'm glad to see someone trying to 'beat me at my own game';)
From: Alan Chalker on 5 May 2010 12:49 "Helen Chen" <helen.chen(a)mathworks.com> wrote in message <hrs51b$eeu$1(a)fred.mathworks.com>... > The Contest queue is now officially closed. There are 380 entries in the queue at this point, so after those entries are processed, we will have an answer to our big question - Who is the Grand Prize Winner for this contest! > > ttys, > Helen Helen: I'd like to extend my thanks again to you and the rest of your team for organizing and running this event. I always look forward to the contests and enjoy the various activities and community that has been built up around them. The new website and machinery is great (even if it did cause me a lot of extra work at the start of the contest to adapt;). One minor suggestion: would it be possible to add an explicit hidden field to the submission form that indicates the id number of the 'based on code'? Right now you have this encoded somehow in the auth-token field. With auto-tweaking code it's not really possible to create that reference back to the original code, however I think there is a lot of value in being able to track the relationships between entries, particularly with the new abilities of the website to show both based on and is the basis for data.
From: Robert Macrae on 5 May 2010 13:01 "Nicholas Howe" <NikHow(a)hotmail.com> wrote in message > I've often wished that there was some way to keep separate development threads alive at the same time, so that people could be rewarded for the best block-style solver, the best overlapping solver, etc. Pretty much why I posted in the newsgroup; it makes it possible to find if anyone is interested, rather than being just one more noncompetitive entry. > In this contest, I have long wondered if we would see an entry based upon the recent research in compressive sensing. The problem with overlapping regions is that they have to be 1) reasonably localised (so that they capture smooth features well) and 2) reasonably orthogonal (so that the information from them can be combined without too much iteration. It is quite hard to achieve both, but here are two sketches: 1) Create square regions 8 pixels across. Its then easy to construct local orthogonal subregions 8x4 and 2x(8x2), with 1s and 0s arranged so that the 1s are all on the side expected to be lighter. A substantial subset of the subregions (or all of them) can then queried together, so we learn the average difference between the two sides and can update our estimates. 2) Keep a list of the masks that have been used so far. To select a new query, construct a score (perhaps by smoothing the current image) of pixels expected to be brighter, and orthogonalise this score against previous masks. Query the brightest half. Again this allows us to update our estimates, though the orthogonality will not be perfect. > ... But perhaps some other brave soul has succeeded in doing so, and will surprise us all in the final minutes of the contest. Here is hoping 8-)
From: Jan on 5 May 2010 14:46 "Robert Macrae" <robertREMOVEME(a)arcusinvest.com> wrote in message > It is quite hard to achieve both, but here are two sketches: > 1) Create square regions 8 pixels across. Its then easy to construct local orthogonal subregions 8x4 and 2x(8x2), with 1s and 0s arranged so that the 1s are all on the side expected to be lighter. A substantial subset of the subregions (or all of them) can then queried together, so we learn the average difference between the two sides and can update our estimates. > 2) Keep a list of the masks that have been used so far. To select a new query, construct a score (perhaps by smoothing the current image) of pixels expected to be brighter, and orthogonalise this score against previous masks. Query the brightest half. Again this allows us to update our estimates, though the orthogonality will not be perfect. First thanks for the great contest! I joined this contest for the first time now and enjoyed it a lot. I think the problem was particularly prune towards overfitting. Although maybe if the players would only train their algorithms on the test data set and only now the official data set would be applied, that might have helpeda bit. Anyway, seeing the auto tweaking (although kind of foolish indeed) approaches was just as funny. Also I liked the twilight phase most and would love to have it a bit elongated next time, definitely more than the daylight phase which could have been easily one day shorter in this case. Anyway I wonder if there are solutions for this problem available from the Mathworks people? I wonder where they would stand:) Or if there is some working algorithm with good results along the lines of what Robert writes? Regards, Jan
From: Nicholas Howe on 5 May 2010 15:03
"Robert Macrae" <robertREMOVEME(a)arcusinvest.com> wrote in message > The problem with overlapping regions is that they have to be > 1) reasonably localised (so that they capture smooth features well) and > 2) reasonably orthogonal (so that the information from them can be combined without too much iteration. Robert, I'm not an expert on this field, but the reading that I have done suggests that you actually want queries that are as random as possible (and hence entirely unlocalized). This runs counter to our usual intuition, but so does beating the Nyquist limit. If people are interested in reading more about this, there's a lot out there but here is one article that describes the basic idea: http://dsp.rice.edu/sites/dsp.rice.edu/files/cs/CSintro.pdf Somebody actually tried something along these line early in the contest (see entries commented concerning cosamp code) but I don't think they got it working. |