Get Time
Search | Watch Thread  |  My Post History  |  My Watches  |  User Settings
View: Flat (newest first)  | Threaded  | Tree
Previous Thread  |  Next Thread
Statistics | Reply
1 Psyho Poland 940107.89 1 936497.54 2475 0
2 ACRush China 925365.35 2 928286.40 2943 0
3 nhzp339 China 919051.98 4 917016.16 1263 165
4 ainu7 South Korea 917255.22 3 917654.03 1394 1
5 chokudai Japan 856304.47 6 863892.83 1177 577
6 blackmath Germany 850648.39 5 866033.43 212 43
7 wleite Brazil 836853.20 7 839390.58 83 0
8 colun Japan 770271.80 8 828312.92 435 0
9 eldidou France 671024.14 9 678750.58 16 63
10 doudouille France 633877.27 10 591220.89 0 741
11 Komaki Japan 516565.90 11 558497.39 2 1533
12 Milanin Ukraine 509705.36 12 518837.21 0 267
Re: Statistics (response to post by wleite) | Reply
Why did people get so many zeroes?
Re: Statistics (response to post by dimkadimon) | Reply
I think it's mostly because of the big number of constraints in the problem.
During most of the time of the contest I was struggling with bugs, and one hour before the end of the contest, I had still more than 10% of zeroes, so I was also close to have a bug number of zeroes in the final results.

The side effect of all this debugging is that I left a line in my code that limits the number of new bases to 1... I guess I need to practice coding fast AND correctly. :)
Re: Statistics (response to post by eldidou) | Reply
It sounds like this competition was closer to an algorithm match than a marathon match. I think the contestants should have been given more time (24 hours). I also wish that we could solve this problem for 2 weeks, but now there is not much point.
Re: Statistics (response to post by dimkadimon) | Reply
I think it was a pretty good problem for the finals.

Although I tested the problem off-site, after 3 hours I had a very good solution and spend the next 2-3 hours tweaking things and trying slightly different settings. So, I think 12 hours is enough for a final, after 10-12 hours its difficult to think straight. I'm not an expert with algorithms matches, and I could came up with a solution that had a great chance of winning (In only 6 hours), so I won't classify this problem as an algorithm match, it felt very marathon like.

I can understand the amount of zero scores. There is a lot of possible cases where you would try to built a base in the same move on the same spot by different workers, or move a worker where another worker will be building, or even trying to move where another worker is collection resources, spawning a worker where another worker wants to move, etc.
Re: Statistics (response to post by JacoCronje) | Reply
You learn a lot about the problem by actually running the contest. After the contest I think it was Psyho that said the elaborate constraints were unnecessary and only lead to more bugs without adding anything to the contest. I never considered that it was possible to use simpler constraints, but I have to totally agree. In retrospect it is obvious. Allowing workers to walk on or through bases, to build bases on cells with workers, to gather or deliver resources by simply entering the cell and maybe some other things would have probably helped significantly. But the first four people to play with the problem didn't think of that even though there was plenty of debugging. It could have been worse. Not allowing multiple workers in a cell would have been a nasty traffic jam.

Then again, walking around without stepping on resources was pretty central to the problem, so that could not be eliminated. I would guess that this was the most complex constraint and the cause of most bugs, so maybe it wouldn't help so much.

Someone could modify the visualizer to use simpler rules and try it. And I bet that if there was any interest we might be able to convince mystic_tc to run an actual unrated contest for two weeks (or whatever) with the modified rules. Wow, that would really be a first, and open discussion about what the problem should be, followed by the actual contest. I think we should try that.