Difference between revisions of "Judge:Help"

Revision as of 22:13, 15 December 2011

Overview

On the problems page (which is accessible from any page on the Judge by clicking "problems" on the black navigation bar at the top of the page), you will find a list of problems to which you can submit solutions. Clicking the problem name on this page will link you to the problem's description. Note that each problem also has a unique alphanumeric problem code, which you might have to specify when you're ready to submit your solution.

When on a problem description page, you will find a link that reads "Submit" on the right of the problem statement. Clicking this takes you to the submission page and automatically fills in the "Problem code" field of the submission form with the code of the problem you were just viewing. You can also reach the submission form by clicking "submit" on the black navigation bar, but then you will have to fill in the problem code manually.

On the submission form, paste your solution in the box labelled "Code". You can also upload a source file from your computer. After you click "Submit", your program will be compiled (if applicable), run, and evaluated, and you will be taken to a page that shows the results of the evaluation.

Whenever you submit, a copy of your source code, and the date and time and results of your submission, are saved permanently on the server. To view your past submissions, go to the main Submissions page by clicking "submissions" on the navigation bar, and then click "My Submissions" on the right. To view your submissions to a particular problem, navigate to that problem's description page, and then click "My Submissions" on the right.

You can see a list of your solved problems under "My Account".

On the main Judge archive, you can submit as many solutions to any problem as you want. Feel free to solve a problem again in a different language, or using a different algorithm. You'll only get the points for it once, though.

Guidelines for submitting

• Read all input from standard input, and output to standard output, even if the problem statement says otherwise. This means that you should submit the program as though it would read from the keyboard and write to the screen.

• But don't take this literally! The input is a sequence of characters given left to right, top to bottom, and not a sequence of keystrokes. Don't use functions like getch() or readkey; they won't work. The output is likewise a sequence of characters given left to right, top to bottom, and those characters must be outputted in that order; commands that change the cursor position on the screen will not work. This is because your program will actually be reading from a file and writing to a file.

• Input and output are to be in the exact format indicated on the problem description. Do not prompt for input by printing lines such as "Enter the number of points"; these will end up in the output and your program will be graded incorrect.
• If you are using Java, the name of the class containing main() must match the problem code exactly.
• For most problems, the judge will mark your solution correct regardless of how much trailing space appears in the output. Likewise, empty lines are simply ignored.
• The judge does care about spelling and punctuation. Forgetting commas, for example, will cause your program to be marked wrong.
• Unless there is a good reason to do so, DO NOT read in multiple test cases in one shot, store them in an array, and then output their answers all in one shot. Instead, process the test cases one by one. See below for more details.

If you're not getting accepted, don't blame the judge; it's usually your fault. However, if nobody has yet solved the problem you're trying to do (or very few), and you think there might actually be a bug, contact Brian.

Important note: Suppose that the problem A plus B had multiple test cases. So, the first line of the input file would be N (1 ≤ N ≤ 100), the number of test cases to follow, and each subsequent line would contain two integers. For each line containing a pair of integers in the input file, the corresponding line in the output file should contain their sum. For example:

Sample Input

3
1 2
3 4
5 6

Sample Output

3
7
11

Here is how a good solution might look (in C++):

#include <iostream>
using namespace std;
int main()
{
	int N,i,a,b;
	cin >> N;
	for (i=0; i<N; i++)
	{
		cin >> a >> b;
		cout << a+b << endl;
	}
	return 0;
}

And here is how an unnecessarily complicated solution might look:

#include <iostream>
using namespace std;
int main()
{
	int array[100];
	int N,i,a,b;
	cin >> N;
	for (i=0; i<N; i++)
	{
		cin >> a >> b;
		array[i]=a+b;
	}
	for (i=0; i<N; i++)
		cout << array[i] << endl;
	return 0;
}

The first solution runs a for loop N times, and in each iteration it reads two integers and then prints out their sum. The second solution reads all the input into an array and only starts printing output after all the input has been read.

Some people are tempted to write the second solution because they imagine that input and output occur on a terminal and that the contents of the terminal after the program has completed must be the input followed by the output. This is not the case; input will come from a file and output will go to a file, and the two will never interfere with each other.

Thus, it is allowed (and encouraged, in fact) to print the answer to each test case as soon as you get it.

About the test cases

The sample test cases are shown for two reasons. One is to help you ascertain that you have correctly interpreted the problem statement and the input and output format. The other is to discourage you from submitting solutions that are obviously wrong (because they don't even process the sample input correctly). Please take advantage of the sample test cases! Please don't complain that your program is failing the actual test data unless you've at least managed to pass the sample test data.

Also, be aware that the actual test data will most likely be quite a bit more difficult than the sample test data, meaning that it will often:

• contain a large number of data points or large number of lines of input, so your program will have to be very efficient in terms of time and memory;
• contain tricky "edge cases" and "corner cases" that tend to expose bugs in many attempts at solution implementations;
• contain difficult test cases that cannot be solved using naive algorithmic reasoning that might work for the sample.

Please don't ask whether so-and-so-difficult-test-case might show up in the test data. The answer is probably yes; why shouldn't problems be challenging? You should always assume that any test case that is not explicitly forbidden by the problem statement can and will appear in the test data.

Summary of supported languages

#include <iostream>
using namespace std;
int main()
{
	int a, b;
	cin >> a >> b;
	cout << a+b << endl;
}

var
	a,b: integer;
begin
	readln(a,b);
	writeln(a+b);
end.

main() {
	int a, b;
	scanf("%d %d", &a, &b);
	printf("%d\n", a+b);
	return 0;
}

main = do
        x <- getLine
        y <- getLine
        print (read x + read y)

puts Integer(gets) + Integer(gets)

print int(raw_input()) + int(raw_input())

import java.util.Scanner;
public class aplusb
{
    public static void main(String args[])
    {
        Scanner sc = new Scanner(System.in);
        System.out.println(sc.nextInt()+sc.nextInt());
        sc.close();
    }
}

<?php
echo fgets(STDIN) + fgets(STDIN) . "\n";
?>

print_int (read_int()+read_int());;
print_newline ();;

print <> + <> . "\n";

Judge system specifications

• Operating system: Ubuntu 11.04 (Natty Narwhal) 32-bit
• Processor: Intel® Xeon® CPU X3440 @ 2.53 GHz

• The CPU is dual-core, but multiprocessing has been disabled because it interferes with timing on the Judge server. Dedicated server machines do not suffer from the same issue, despite having multiple cores.

• Memory: 2 GB physical RAM, 1 GB swap

"My program compiles (or is correct) on my computer but not on the judge."

For loop variable scoping

This type of code compiles in Microsoft Visual C++ 6.0 (but not here):

for (int i = 0; i < N; i++)
{
	...
}
if (i == N)
{
	...
}

This is because in this case g++ conforms to the standard, which indicates that a variable declared as i is above is local to the for loop, whereas MSVC6 fails to conform to this part of the standard.

Strange C++ compilation errors

C++ compilers tend to give notoriously unhelpful error messages, for example:

/usr/include/c++/4.1.3/bits/stl_iterator_base_types.h: In instantiation of 'std::iterator_traits'

Often, this means that one of your variables is using the name of an existing function. Even if you have only included iostream, the Judge uses an old version of g++ that is less stanards-compliant than newer versions, and algorithm will automatically be included, so that names like count, fill, and transform, functions declared in that header, can trigger this error.

Execution discrepancies

If your program runs correctly on your computer but produces the wrong answer on the Judge, one of the following is usually the cause:

• Printing to standard error (at this time, whatever you print to standard error will end up in standard output, and hence cause your program to fail the test data.)
• Misunderstanding the input and/or output format.
• Failure to initialize a variable.
• Accessing an array out-of-bounds.
• Doing something you shouldn't be doing, such as popping from an empty stack, or trying to take the log of a negative number.
• Doing something you really shouldn't be doing, such as making weird system calls.
• Assuming that standard input and standard output are terminals (whereas in actual fact they are files), or assuming they are files (they might in some cases be pipes).
• Assuming the grader is a 64-bit machine. (It isn't; most major olympiads are using 32-bit environments, simply because switching to 64-bit environments at this point would require a lot of work and provide no real advantage; and so we follow suit.)

Status Codes (and their likely meanings)

If your program is Accepted, congratulations!

The status codes WA (Wrong Answer) and CE (Compile Error) have very obvious meanings.

RE (Runtime Error) can have a variety of meanings. When a runtime error occurs, more information is often available:

• SIGSEGV - Invalid memory access: you're going out of bounds on an array, string, vector, etc.
• SIGFPE - Division by zero, square root of a negative, etc.
• SIGABRT - Uncaught exception or failed assertion in C++; can also be caused by popping empty stacks and the like
• Memory Corruption - same as SIGSEGV, but for other programming languages
• Uncaught Exception - same as SIGABRT, but for other programming languages

IR (Invalid Return) usually occurs only for programs submitted in interpreted languages, and may indicate a compile-time error (i.e., syntax error) or a runtime error.

TLE (Time Limit Exceeded) means that your code is too slow. (Note that the time limit is per test case). Often, this may mean that your code contains an infinite loop, and your program will never stop executing. In other cases it may mean that your program will terminate, but not within the time limit indicated. (Distinguishing between the two is the famous Halting Problem, which is impossible to solve.)

MLE (Memory Limit Exceeded) means that your program tried to allocate memory beyond the memory limit indicated. This can occur if you declare a very large array, or if a data structure in your program becomes too large.

OLE (Output Limit Exceeded) occurs very rarely, and indicates that your program tried to print an unacceptably large number of characters to standard output (i.e., more than 16 million). This usually means you have an infinite loop.

IE (Internal Error) is not your fault, and usually occurs during maintenance. Contact an admin if you are concerned; they will eventually rejudge your submission.

Note for Java users: The only error message that can be trusted is Accepted. All other error messages either do not occur or may not mean what they seem to. For example, you will probably never see Memory Limit Exceeded; instead, you will simply get Wrong Answer. This is because the JVM makes it difficult to determine what actually happened.

Grading

For regular problems, the judge compares your output character for character - except that it ignores the amount of whitespace. The file check.cpp contains the source code to the judge program used for the vast majority of problems in the archive.

Some problems have special graders that take care of multiple outputs. For these, the above rules usually still apply. To be safe, though, try to match the output format shown in the sample cases exactly, in the spirit of Postel's Law: Be generous in what you accept, rigorous in what you emit. (Usually, the guy before you will follow Postel's Law too; the problem setters do their best not to put trailing spaces and extra blank lines in the input.)

Flushing output

On interactive problems such as Guess the Number, it is very important that you flush the standard output stream before each occasion on which you expect a response from the grader. For example, in Guess the Number, you have to flush after each guess, because after each guess, you expect the grader to tell you whether it was correct, too high, or too low. If you fail to do this, the grader might never receive your output, which means your program will time out while waiting for a response from the grader that will never come. This is done as follows:

• C:

  fflush(stdout);

• C++:

  cout.flush();

• Pascal:

  flush(output);

• Java:

  System.out.flush();

• Haskell:

  hFlush stdout

• Assembly: Output is written immediately at each sys_write call, so there is no need to flush.
• Ruby:

  $stdout.flush

• Python:

  sys.stdout.flush()

• PHP:

  flush(); ob_flush();

• OCaml:

  flush stdout;;

• Perl:

  $stdout->flush;

  Note: This code assumes that $stdout is an IO::Handle object. Alternatively, you can use

  autoflush STDOUT 1;

  if you want to have standard output flushed after every write operation.

Often, flushes will occur automatically after each time a newline is printed, and, unless something really bad happens, standard streams are automatically flushed when a program terminates. However, do not rely on this being the case on the Judge, which may be configured differently.

BBCode

Tags

• [quote]...[/quote] to quote a post
• [code]...[/code] for code (language automatically detected)
• [url]...[/url] for a link
• [i]...[/i] italic
• [b]...[/b] bold
• [u][/u] underline
• [color=red]...[/color] color
• [size=5]...[/size] size
• [sup]...[/sup] ^superscript
• [s]...[/s] strikethrough
• [list][*]A [*]B[/list]: list

• A
• B

Emoticons

Encase certain keywords between a pair of :: to make an emoticon. Here are the currently supported keywords:

:angel:
:applause:
:biggrin:
:confused:
:cool:
:eh:
:fear:
:impressed:
:kidding:
:mad:
:naughty:
:neutral:
:rolleyes:
:sad:
:sick:
:silenced:
:smile:
:think:
:tongue:
:twisted:
:whistle:
:wink: