From: Sergey Y. on
"Alan Chalker" <alancNOSPAM(a)osc.edu> wrote in message <hrs7i1$3dt$1(a)fred.mathworks.com>...
> 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'?


If we go that way I would respectfully request &#8220;official Web API&#8221; :)


I lot of thanks to Matlab contest team for wonderful problem and new site.
Good luck to all participants. Hopefully I will see you in a half a year

Sergey
From: Yi Cao on
"Nicholas Howe" <NikHow(a)hotmail.com> wrote in message <hrsld1$k01$1(a)fred.mathworks.com>...
> "Hannes Naudé" <naude.jj+matlab(a)gmail.com> wrote in message
> > The reason why our simple block based solvers appear to outperform the cutting edge stuff from academia is the fact that the problem as stated here does not actually correspond exactly to the compressive sampling problem typically studied in the real world. In that case, one is not able to adjust your query pattern dynamically based on the results from earlier queries. Rather, the entire set of query masks need to be specified at the outset.
> >
> > Being able to adjust our queries to zoom in on areas with detail is a significant (allthough not realistic) advantage and allows the custom developed code to outperform the off the shelf CS code by orders of magnitude.
>
>
> Thanks for clarifying this, Hannes. I feel better now about not putting the time into delving through that CS material! (As I write this your entry stands at the top of the heap, so it looks like you managed to do quite well with other techniques also.)

I was thinking a zooming approach, even with diagonal masks but was not successful to compete with current approahes. My view is that the contest is a game. We cannot and should not treat it too academically.

It sounds like Hannes' random entry will finally beat my 'final effort' series. Well-done!

Yi
From: Alan Chalker on
"Sergey Y." <ivssnn(a)yahoo.com> wrote in message <hrsmcd$ol5$1(a)fred.mathworks.com>...
>
> However, direct probing is against the rules.

To reinforce that, here's the relevant section of the rules:

"Extraction of puzzles in the test suite by manipulating the score, runtime, or error conditions is also forbidden. In the small scale, this has been an element of many past contests, but in the Blockbuster Contest, Alan Chalker turned this into a science."
From: Alan Chalker on
"Alan Chalker" <alancNOSPAM(a)osc.edu> wrote in message
> "Extraction of puzzles in the test suite by manipulating the score, runtime, or error conditions is also forbidden. In the small scale, this has been an element of many past contests, but in the Blockbuster Contest, Alan Chalker turned this into a science."

Helen (and all): Just a minor error I never noticed before in the rules. It was the Blackbox contest, not the Blockbuster contest.
From: Robert Macrae on
"Nicholas Howe" <NikHow(a)hotmail.com> wrote in message

> 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).

"Reading" -- dubious concept, it will never catch on

I had a look at random queries. They handle the "nearly orthogonal" bit well, but I don't think they can be best. The value of a query is (at least roughly) how different the answer is from your prior estimate. That is the argument for large overlapping queries, but it works best if you can pick pixels that for some reason seem likely to be all be higher or lower than their current means suggest (eg because they are all on the dark side edges). Pure random queries can't do this so the gain per query seems rather low... but I'll take a look at your reference, I'm probably missing something.

Robert Macrae