Spring 2010 MATLAB Contest, April 28 - May 5
in [Matlab]
|
Prev: Single number into vector elements
Next: neural network
From: Amitabh Verma on 4 May 2010 15:42 "The Tuesday Longevity Prize. Whoever stays in the lead with a single entry for the longest amount of time on Tuesday (midnight to midnight, UTC) wins the prize. The winner will need to take the lead any time on Tuesday, and will receive credit for all the time spent in the lead, including Wednesday. Any ties will be broken by whoever appeared most recently." I had a few questions on the above from the contest blog. Does the Longevity contest end at midnight Tues, UTC or run into Wed. ? Is the score the cumulative time spent in lead or the longest entry that was in lead ? Thanks. Best, Amitabh PS: I agree pics would be nice to have :)
From: Sergey Y. on 4 May 2010 16:21 "the cyclist" <thecyclist(a)gmail.com> wrote in message > Also, out of curiosity (and only if you don't mind sharing, of course!): Does your code automatically grab the leader, and tweak any and all numerical parameters? Or do manually seek out more likely parameter for tweaking? > > the cyclist As we discussing technical part of automatic tweaking I am curious too (If it is not a secret of course) : does your software reads result and looks for the minimum in multidimensional space or just tries all parameter values? Sergey
From: Alan Chalker on 4 May 2010 18:12 "the cyclist" <thecyclist(a)gmail.com> wrote in message <hrpsah$t7e$1(a)fred.mathworks.com>... > > Out of curiosity, Alan, will you just run your auto-generator continuously until the end of the contest? If so, it looks like we can safely assume that the queue will continue to grow until the end, since you can feed the queue at one entry per minute, and each entry requires more than that in processing time. (Note that this is not a complaint, just an observation.) > > Also, out of curiosity (and only if you don't mind sharing, of course!): Does your code automatically grab the leader, and tweak any and all numerical parameters? Or do manually seek out more likely parameter for tweaking? > > the cyclist No I won't run it overnight.. I'll take a break after the end of the current mini contest until about an hour before the ultimate contest end tomorrow. I have a special super duper strategy to implement then;) I'm happy to share any and all details of my auto-submission code. Yes, I continuously scan to see who the current leader is. If it's my own entry I don't do anything at all. If it's another new code I grab the code, then have a ordered set of 'likely numeric parameters' to tweak. A lot of this is just gut feel from earlier in the contest. For example, say a key parameter to tweak is currently at 0.1234. Then my code would first submit an entry with that changed to 0.1235, the next one would be 0.1233, next 0.1236, then 0.1232, etc. etc. I repeat this about 10 times on average, trying to tweak slightly on both sides of the parameter. Then I go to the next likely parameter (unless of course the leader changes during this process, in which case it starts over again with the new code).
From: Alan Chalker on 4 May 2010 18:15 "Sergey Y." <ivssnn(a)yahoo.com> wrote in message <hrpvjg$6hm$1(a)fred.mathworks.com>... > "the cyclist" <thecyclist(a)gmail.com> wrote in message > > Also, out of curiosity (and only if you don't mind sharing, of course!): Does your code automatically grab the leader, and tweak any and all numerical parameters? Or do manually seek out more likely parameter for tweaking? > > > > the cyclist > > As we discussing technical part of automatic tweaking I am curious too (If it is not a secret of course) : does your software reads result and looks for the minimum in multidimensional space or just tries all parameter values? > > Sergey It's essentially just doing an educated parameter sweep. With the level of tweaking we are doing it's overfitting to the test suite, so there's no real way to truly 'algorithmically optimize'.
From: Helen Chen on 4 May 2010 18:27
Robert Macrea accidentally posted this to a separate thread. He asked me to repost it for him. <snip> A Third Way It seems a shame that many of the competitive entries are still dominated by just two basic solvers that query non-overlapping regions. Why, when there are so many other approaches available? To try to make the mix more interesting here is a third approach. In itself it is not competitive, but I think that if tweaked to the level of existing entries it would outperform them on some images, particularly where contrast is reasonably even across the whole image rather than being focussed around a few features. A Third Way carries out an initial scan using two rectangular overlapping scans, with the second a grid offset by half a grid width. Between them these scans take up about 80% of the available queries, and they each give a different, coarse version of the image. Every pixel has two estimated values, and if you form a combined image from their means you see an image with pixel blocks half the size of the initial scans. In effect you have faked the resolution you could get with 1.6x the permitted number of scans, which sounds good. In particular it should make smoothing more effective. The catch is that in place of exact answers you would have with a real 1.6x scan you only have two estimates for the result of each query. Clearly you have lost accuracy near any sharp edges, which is where the remaining 20% of queries come in. Because we have two estimates for each subarea we have a good idea where the uncertainties are highest, so we can query these subareas in order to improve the overall quality of the estimate. Not only do these queries pin down exact answers for the queried subarea, they also reduce uncertainties for all 8 adjacent subareas. In low contrast areas of course the two initial estimates will be similar so we won't waste queries there; queries cluster near high-contrast areas the two estimates differ most, and this is why we only need to query about 1/8 of the subareas to get a reasonable-quality image. The result should be an image with reasonably accurate subarea estimates, and subareas smaller on average than can be produced by the two main approaches. The problem seems to be that this improvement is spread rather evenly across the whole image instead of being as strongly focussed on sharp edges as it is with subdivision. I don't have time to take development any further, but if you want to have a play I'd suggest an number of areas for attention (on top of the sloppy coding). -- Ideally you don't want to query too many subareas that are very close together, as this is redundant. It may be worth recalculating uncertainties as subareas are queried? -- Subarea boundaries have been allocated evenly along both x and y axes, but if t is the usual edge of a subarea this results in some subareas that are (t+1)^2 pixels while most subareas are t^2 or t.(t+1). Might it be better to put all the large gaps along just one axis so the largest area is t.(t+1)? -- Smaller areas give better estimates; this should slightly modify the dispersion and mean estimates? -- The complexity of the code gives great scope for optimisation and bug hunts, so many hours of tweaking are available 8-) Good luck to anyone who can get this into competitive form! Incidentally, if anyone fancies a collaborative effort I am out of coding time but have a number of other ideas that might be interesting, a sketch for a fourth solver based on edge detection and a few others for improvements in late scans and post-processing. Email me at ff95 a t dial dot pipex dot com if you are interested. </snip> |