[ Contest Page | Scoreboard | Submissions | Clarifications | Help | Log In ]
| Problem | Clarification |
|---|---|
| General |
I/O? Please use standard in and standard out! Input -- Java: Scanner in = new Scanner(new BufferedReader(new InputStreamReader(System.in))); C: scanf("%d %d", &integer1, &integer2); C++: int x; cin >> x; Output -- Java: System.out.println("asdf"); C: printf("%d %d", integer1, integer2); C++: int x = 5; cout << x << endl; |
| General |
Java class names? Please use the following class names (make sure classes are public): Problem A - public class A { ... } Problem B - public class B { ... } . . . |
| General |
Compilers? gcc 4.9.2 javac 1.6.0_37 Python 2.6.6 ghc 7.0.4 |
| General |
The I/O from the actual contest website uses CR line endings (instead of LF or CR LF); does the I/O from this judge also have the same thing? Yes, sorry - it should be fixed now. |
| C - Ambiguous Encodings |
I took a look at the real contest I/O and it turns out that the judge output is completely wrong because it uses 64-bit longs to hold values that may overflow, e.g. for the test case that is comprised of 100 1s. For this case the answer is a super large Fibonacci number that is larger than 2^63. Sigh, sorry - never checked it, just assumed that everything was OK. Just got in (1:24 MST) |
| General |
What happened? Rejudging. |
| General |
What is my RTE? ################################################################################ # Grading Script -- Running for ubc26/PC_03.py ################################################################################ PROBLEM: PC_03 EXT: py JUDGE_IN: data/C.in JUDGE_OUT: data/C.out TIME_LIMIT: 5 TEST_CASE_NUM: 0 DIFF_PROGRAM: diff --== Compiling ==-- --== Running ==-- Traceback (most recent call last): File "/home/pscadmin/tmp/acm/PC_03.py", line 62, in print("Case #{}: {}".format(i + 1, f(0))) ValueError: zero length field name in format REJECT: runtime error |
| B - Magnetos |
The input data on the actual contest is missing the last line. Is this fixed here? Our data was the same as the contest data. yes, looks like it has 252 instead of 253 edges, so I am not sure how we got these accepted solutions (well, the answer is 'No'). I will add a not-so-random edge and see if it changes verdicts. Funny, I guessed 2-1 edge should come next and it actually changes No to Yes. |
| B - Magnetos |
Short explanation of issues with the second problem. - original input file was missing the last edge in the last case - added an edge - which changed the answer That is why I had to rejudge B twice, it should still pass for people that had AC before. |
| C - Ambiguous Encodings |
Short explanation of... blah blah C. Output file was wrong in two cases, because they never checked if the answer could fit into a 64-bit signed integer. Removed those two and re-judged. All AC should still be AC (although they should not have been), but correct solutions will also be AC now. |
| D - The One Dollar Gambler |
What happened to D It was missing a checker. It is OK now (data verified) |
| General |
Are there any problems with correct I/O I do not know. A,E,F,G can still turn out to be wrong. |
| General |
Is the judge dead? |
| General |
Is the contest still on? My file is taking ages to be judged Sorry, yes, judge "ran out of resources" for some reason. I think our server is on a VM |
| General |
Is the online judge still judging? It has been 20 min since I submitted my code and it shows "not yet judged" See above |
Ultra Cool Programming Contest Control Centre v1.8
Copyright (c) 2005-2010 by Sonny Chan