View Clarifications


[ Contest Page | Scoreboard | Submissions | Clarifications | Help | Log In ]


ProblemClarification
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