Scribd
Upload
5 views

Programming_Challenges_23-23

This document provides guidelines for submitting programs to a judge, emphasizing the importance of including a specific @JUDGE ID line and properly formatting the code. It also highlights the need for careful interpretation of problem specifications and outlines the types of feedback that may be received from the judge, including verdicts like Accepted and Presentation Error. Students are advised to ensure their output matches the required format to avoid common pitfalls.

Uploaded by

Sandeep Singh
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
5 views

Programming_Challenges_23-23

This document provides guidelines for submitting programs to a judge, emphasizing the importance of including a specific @JUDGE ID line and properly formatting the code. It also highlights the need for careful interpretation of problem specifications and outlines the types of feedback that may be received from the judge, including verdicts like Accepted and Presentation Error. Students are advised to ensure their output matches the required format to avoid common pitfalls.

Uploaded by

Sandeep Singh
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 1

1.1.

Getting Started With the Judge 3

Specifically, each submitted program must contain a line (at any location) with an
@JUDGE ID: field. Usually, this line is placed inside a comment. For example,

/* @JUDGE_ID: 1000AA 100 C "Dynamic Programming" */

The argument after the @JUDGE ID: is your user ID (1000AA in the example). This is
followed by the problem number (100 in the example), and then by the language used.
Make sure you use the UVa ID number for all submissions to this judge! Upper- and
lowercase letters are indistinguishable. If you fail to specify the programming language,
the judge will try to auto-detect it – but why play games? Finally, if you have used any
interesting algorithm or method, you may include a note to that effect between quotes,
such as Dynamic Programming in the example above.
Bracketing your program with beginning/end of source comments is a good way to
make sure the judge is not confused by junk appended by your mailer.

/* @BEGIN_OF_SOURCE_CODE */

your program here

/* @END_OF_SOURCE_CODE */

Certain mysterious errors will go away when you do this.

1.1.3 Feedback From the Judge


Students should be aware that both judges are often very picky as to what denotes a
correct solution. It is very important to interpret the problem specifications properly.
Never make an assumption which is not explicitly stated in the specs. There is absolutely
no reason to believe that the input is sorted, the graphs are connected, or that the
integers used in a problem are positive and reasonably small unless it says so in the
specification.
Just like the human judges of the ACM International Collegiate Programming Con-
test, the online judge provides you with very little feedback about what is wrong with
your program. The judge is likely to return one of the following verdicts:

• Accepted (AC) — Congratulations! Your program is correct, and runs within the
given time and memory limits.

• Presentation Error (PE) — Your program outputs are correct but are not pre-
sented in the specified format. Check for spaces, left/right justification, line feeds,
etc.

• Accepted (PE) — Your program has a minor presentation error, but the judge is
letting you off with a warning. Don’t be concerned, because many problems have
somewhat ambiguous output specifications. Usually your problems are something
as trivial as an extra blank at the end of a line, so stop here and declare victory.

You might also like