idea about 2 weeks long contest is quite good, at least I’d like to have 2 weekends for solving those interesting problems (and as described not in all countries weekend is saturday and sunday)
From my point of view I’m not interested in pypy, or virtual contests, prizes for challenge problems or two tester (my opinion is that it works well with one tester).
On the other hand I’m against reserving some time for challenge problems - I really like those, but it’s a strategy which problem you would like to solve (except ACRush, that solves all of them :-D).
not 500-600 its 1700-1800 lines I am a beginner. Seeing BIG solution makes me ignore the solutions ACRush also used to come 2nd,3rd 4th a few years ago but now he has practiced so much…he’s better than others…
FACT : I support that I am also not able to grasp completely many ideas of top solution.Increasing the number of days would surely help me out.
Well, but by increasing number of days, all you would gain would be more headaches… Because one thing I believe in algorithm contests is that having the right idea is key… Without it, you won’t go far, even if contest was 20 or 30 days… You (and I ofc, I’d say Im at medium/beginner level) would gain more if editorials could be discussed with setters themselves on a larger time window.
Please cast your votes on above 3 points. Also ask fellow Codechefers to do the same. I will post the results once decent number of responses get recorded. Note - This is not official form
@bugkiller : You should have mailed the codechef during the contest. The user should definitely be banned for posting this on public forums like these.
I think this format is good. I feel the codechef has very very good testers Anton and Hiroto but I think the codechef should us (at least) two testers for each contest to minimize the contest end date and problem modifications.
@javadecoder >> And how would they know the user’s id here, on Codechef? And there is no way you can permanently stop this thing, so extending the contest duration will, yes, increase this scenario further more.
@bugkiller I could find the user’s id in less than a minute (Google rocks) and know I agree even more that the duration time of long contests shouldn’t be extended in such extreme way. Well what’s the fun in getting points by cheating, I think codechef offers a great opportunity for self achievement and self learning . The contests are actually to test YOUR skills, I really hate people who do this, that might even take the credit away for those who came up with the solutions by themselves… If one likes to compete this way one should search for team competitions
We like the suggestion of running the contest from a Friday afternoon IST to Monday afternoon IST (gives most (not all) people in the world 2 weekends). We are seriously considering this.
Oh no! March 1 is Friday. So March long contest will start as usual. I was hoping that I will have more time on testing it, especially considering that February is a short month
I see one of the reasons to not release the test data is to avoid copying of codechef problems to other online judges and also not let someone else use problems in some prohibited way.
So from this point of view it seems reasonable to not release the test data.
I understand your point that as CodeChef uses SPOJ for running its system tests its not feasible to release the Run Log but I feel that some alternative way should be developed to provide the user with the test cases due to which the user’s solution failed the system tests. Many a times the user is unable to figure out the bug in his code even after looking at other person’s accepted solution, which sometimes leads to leaving the problem unsolved.
Websites like Topcoder and Codeforces also provide the user with the System Run Log. So I don’t get your point that the problems being copied or used in some prohibited way. Besides that, many of the problem statements in the CodeChef practice problem set have been copied from spoj.pl, so it should not be an issue when some other online judge copies CodeChef problems.