Difference between revisions of "Judge:Help"

Latest revision as of 02:30, 29 November 2016

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. If the Judge is busy grading other submissions, you will see a message that says "Waiting for other submissions to finish...". Be patient; your submission will be held in a queue and graded on a strictly first-come, first-served basis.

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, although we provide no guarantees as to the integrity of the data. 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

• Time and memory limits are posted for each problem. Note the memory limit is a total memory limit, and includes memory used by your programming language runtime, so if the memory limit is 16 MiB, and you have a big array of size 15.5 MiB, you will probably still exceed the memory limit. Also note that there is no separate stack size limit; only total memory (stack+heap+static+code) is limited.
• 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.

Forbidden actions

Your program shall not do, or attempt to do, any of the following:

• fork,
• access the network,
• open, create, delete, rename, move, or examine any file or directory, or examine or change any file or directory's attributes, or change its current working directory, or otherwise examine or interact with the filesystem,
• write to standard input,
• interact with any other process, except by interacting with the grader for an interactive task by reading from standard input and writing to standard output,
• examine any other process,
• read, write, or execute memory from the address space of any other process or any shared library that your program has not loaded,
• execute any other program, or dynamically load a shared library from disk that is not automatically loaded by the programming language runtime or standard libraries,
• technically circumvent the grader in order to exceed the stated time or memory limits, or do, or attempt to do, any of the above.

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())

print(int(input()) + int(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";

^* We retain an old g++ version, g++-4.1.3, as the primary C++ compiler on the PEG Judge. If you select just "C++" (not "C++11") from the dropdown, you get g++-4.1.3. We use this version because newer versions, such as 4.3, have removed the max, min, max-assignment, and min-assignment operators that a lot of old submissions depend on. The PEG Judge also has a newer compiler, g++-4.9.1, which supports the entire C++11 core language and also the regex header. Eventually the g++ version will be stabilized and C++11 will be made the default language option; this is the current plan.

Output-only problems

An output-only problem is a problem in which you are given all the test input during the contest and merely required to submit the correct output at some point before the end of the contest. Contrast this with ordinary ("batch") problems in which you do not get to see the test data during the contest and must submit a program to generate the output.

Problems that are intended to be output-only may generally be submitted in only one language, which is called "TEXT" on the problem page and submission status page, and "Output-only" in long form on the submission form. Simply paste or upload the correct output.

Language restrictions

The sidebar on the right of each problem description page shows a list of languages that can be used to solve that problem. The language codes used are the same as those shown on the submissions page. (Hover over a language code to see its full description.)

Most problems can be solved in every language except TEXT. The TEXT (output-only) language is usually reserved for output-only problems (see above). There are, however, cases in which not all languages may be used. In general:

• Some problems, such as Shortest Code Contest, only make sense if solutions are to be written in one (or a few) particular language(s) (here, C or C++). These problems are expected to be very rare on the PEG Judge, since they are mostly nonalgorithmic in nature.
• In some problems the main algorithmic challenge results from such tasks as manipulating large integers (see Bignum), parsing strings (see Regex), or dynamically evaluating expressions. In such cases, languages with built-in facilities for performing these operations are disallowed. For example, A Plus B 2 is very easy in any language with built-in bignums. The vast majority of problems on the PEG Judge are not of this variety.

• It might be argued that C++ should not be allowed on some problems because it has the algorithmically complex std::set and std::map (see dynamic set, map) in its standard library, whereas C and Pascal do not. However, C++ is allowed in every major programming competition, including the IOI, all major national olympiads, the ACM ICPC, and TopCoder. (On the other hand, whereas most competitions allow Java, not all of them do.) Therefore, C++ should always be allowed, and so should C and Pascal, which are allowed at every major programming competition except TopCoder. (It should also be pointed out that C is minimal by design, and hence restricting oneself to using it to write algorithms is nearly as pointless as writing in assembly language (which is also supported); although this is likely to be a controversial point.)

Judge system specifications

• Operating system: Debian GNU/Linux 7.0 (Wheezy), 64-bit

• Note: Submissions are compiled for a 32-bit target.

• Processor: Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz, dual-core
• Memory: 2 GB physical RAM, 512 MB swap

Compilation discrepancies

Sometimes, your program may compile on your computer but not on the Judge.

C++

Existing C++ compilers vary in standards compliance, so programs that compile on MSVC often do not compile on gcc, and programs that compile on one version of gcc might not on another.

The Judge's C++03 compiler is a "classic" version, g++-4.1.3. This has some extra features such as the <? and >? operators, and lets you get away with including fewer headers than you're supposed to. It has its quirks, but you'll get used to it, as competitive programmers have for the last few years.

But switching to C++11 is recommended. This uses a recent version, 4.9.0. Recent gcc versions conform much better to standards, and also produce much better error messages.

Even still, C++ compiler error messages are often extremely verbose and hard to read. If you see huge error messages with lots of angle brackets, check your template usage. (Note that many of the functions in the algorithm header are templated so that they can work with generalized iterator ranges; the most common example is std::sort().)

Java

Your program's main class's name must match the problem code exactly, even in letter case. For example, if your main class is called "A1" and the problem code is "a1", your program cannot be graded. (This will be changed in the near future.)

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:

• 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 generally regular files), or assuming they are regular 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)

AC means accepted. If you see this, congratulations!

The status code CE (Compile Error) has an obvious meaning.

WA (Wrong Answer) means your program's output was judged to be incorrect, according to whichever judge the problem uses. For example, for problems that use the strict judge, this could mean that you printed out the wrong numbers, or it could mean you printed out the right numbers but with the wrong amount of whitespace. (For most problems the judge is lenient about whitespace; see the grading section.)

RE (Runtime Error) can have a variety of meanings. Often this means the program was terminated by a signal, which will be shown to you. Common signals are:

• SIGSEGV - Invalid memory access: you're going out of bounds on an array, string, vector, etc. Can also mean you're using too much memory.
• 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. In C++ this is often due to bad_alloc() being thrown by the STL when you try to create too large of a vector, set, map, etc.

If RE is accompanied by a status code (as in RE (status=1)) it means the program terminated with a nonzero exit code. This can mean you forgot return 0 in C. In interpreted languages, it can also indicate a compile error (such as a missing semicolon) or a runtime error.

If you submitted in Pascal, common exit codes are automatically translated into error messages such as Division by zero. If you submitted in Java, and your program exited by throwing a common exception, such as java.lang.ArrayIndexOutOfBoundsException, this will be shown to you in the submission status. In both cases, more unusual exceptions are usually just shown as a nonzero status code.

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.)

In some cases you may see "(wall clock)" next to a TLE status code. This means that your program used too much real time, rather than too much CPU time. This rarely occurs---it means your program spent too long waiting for system calls such as reading input, rather than spending too much time on calculations.

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.

Overall status code

Each test case your program is run against produces a status code. The overall status code is the highest-ranked status out of all individual test case statuses. The statuses are ranked from high to low as follows:

1. Internal Error
2. Runtime Error
3. Memory Limit Exceeded
4. Output Limit Exceeded
5. Time Limit Exceeded
6. Wrong Answer
7. Accepted

For example, if you get Wrong Answer on one case, and Time Limit Exceeded on another, the overall status that will be shown on the submissions page is Time Limit Exceeded. If any case has an Internal Error, the entire submission will show Internal Error. You will only get the overall verdict of Accepted if all cases are Accepted.

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.)

The grader is run on each case, even if your program terminated with an error. So, for example, if you get Runtime Error, you might still get full marks on the case, if you produced the correct output before the error occurred. The exception is if you get TLE. If you get TLE, then you fail the case even if you produced the correct output.

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: