ACM评判结果

合集下载
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

ACM评判结果.txt如果你同时爱几个人,说明你年轻;如果你只爱一个人,那么,你已经老了;如果你谁也不爱,你已获得重生。

积极的人一定有一个坚持的习惯。

本系统可以对您提交的源代码进行编译并且运行,然后判断您提交的程序是否符合题目的要求,最后给出相应的信息。

具体信息如下:
Waiting :系统无法在第一时间给所有提交以评判结果。

Compiling : 您提交的代码正在被编译。

Running : 您的程序正在系统上运行。

Accepted (AC) : 您的程序是正确的,恭喜!
Presentation Error (PE) : 虽然您的程序貌似输出了正确的结果,但是这个结果的格式有点问题。

请检查程序的输出是否多了或者少了空格(' ')、制表符('\t')或者换行符('\n')。

Wrong Answer (WA) : 输出结果错,这个一般认为是算法有问题。

Time Limit Exceeded (TLE) : 您的程序运行的时间已经超出了这个题目的时间限制。

Memory Limit Exceeded (MLE) : 您的程序运行的内存已经超出了这个题目的内存限制。

Output Limit Exceeded (OLE) : 您的程序输出内容太多,超过了这个题目的输出限制,多半是死循环引起的。

Compilation Error (CE) : 您的程序语法有问题,编译器无法编译。

具体的出错信息可以点击链接察看。

Out Of Contest TIme : 比赛已经结束,这个只有在比赛中才会出现
Runtime Error (RE) : 运行时错误,这个一般是程序在运行期间执行了非法的操作造成的。

以下列出常见的错误类型:
ACCESS_VIOLATION 您的程序想从一些非法的地址空间读取或向其中写入内容。

一般例如指针、数组下标越界都会造成这个错误的。

INTEGER_DIVIDE_BY_ZERO 在进行整数除法的时候出现了除数为零的异常。

STACK_OVERFLOW 栈溢出。

一般是由于无限递归或者在函数里使用了太大的数组变量的原因。

本系统的评判流程是这样子的:对用户提交的源程序进行编译,如果编译通过,则运行编译好的EXE文件,同时使EXE文件从文本数据中读取测试数据,
并同时保存EXE文件的输出,如果EXE文件运行没有超出规定的时间与内存空间,则对EXE 输出的数据与正确答案数据进行比对,最后给出结果。

所以用户的程序仍然使用标准输入输出,例如题目1000可以这样子写
常见问题解答
1. 我的程序如何进行输入输出?
2. 在线判题系统(以下简称POJ)的编译器是哪些?
3. 提交的时候可否使用快捷键?
4. 请问提交的程序是如果被判答的?
5. POJ对提交程序的不同判答的意义?
6. Special Judge的题目有什么不同?
7. 如何确定程序读入的终止?
8. 为什么我的程序在GCC/G++ (C/C++)下被判成WA/TLE/RE,但是在C/C++ (GCC/G++)下被判成AC?
9. 有些题目的时间限制是1秒,但是有些程序却以几秒的时间AC了?
10. 我的程序仅仅超过时间限制15MS,我该怎么优化程序呢?
11. 我还有其他问题?
________________________________________
问题: 我的程序如何进行输入输出?
解答: 你的程序应该始终使用标准输入(stdin)和标准输出(stdout).比如,你可以使用scanf(在C/C++编
译器下)或者cin(在C++编译器下)来读取数据,使用printf(在C/C++编译器下)或者cout(在C++编译器下)
来输出答案.用户提交的程序将不允许读/写文件操作.如果你坚持要这样做,OJ很可能会返回Runtime
Error(运行时错误)或者Wrong Answer(答案错误).
另外还要注意的是在C++下的I/O操作.由于其复杂的内部实现方式,cin和cout相对于scanf 和printf来说
要慢上不少.如果在G++下编译提交,速度的差异将会愈加明显.所以如果题目给出的数据将有巨大的输入
数据时,使用cin和cout有可能导致意外的Time Limit Exceed(超时).
________________________________________
问题: 在线判题系统的编译器是哪些?
解答: 目前我们使用5个编译器来支持各种语言的程序提交.C和C++采用的是MS-VC++ 6.0,而对于
GCC/G++,采用的是MinGW+GCC/G++ 3.4.2. 对于Pascal, 采用的是FreePascal 2.0.0. 对于Java, 采用的
是JDK 1.5.0.
下面是1000的正确程序在不同编译器下的写法:
C and GCC:
#include <stdio.h>
int main(void)
{
int a, b;
scanf(\"%d %d\", a, &b);
printf(\"%d\\n\", a + b);
return 0;
}
C++ and G++:
#include <iostream>
using namespace std;
int main(void)
{
int a, b;
cin >> a >> b;
cout << a + b << endl;
return 0;
}
使用GCC/G++的提醒:
对于64位整数, long long int 和 __int64 都是支持并且等价的.但是在读和写的时候只支持scanf(\"%
I64d\", ...)和printf(\"%I64d\", ...).
不支持\"%lld\"是因为MinGW下的GCC和G++使用的msvcrt.dll动态链接库并不支持C99标准.
根据ISO C++标准,在G++下,main函数的返回值必须是int,否则将会导致Compile Error(编译错误)的判答
.
Pascal:
Program p1000(Input, Output);
Var
a, b: Integer;
Begin
Readln(a, b);
Writeln(a + b);
End.
Java:
import java.util.*;
public class Main
{
public static void main(String args[])
{
Scanner cin = new Scanner(System.in);
int a = cin.nextInt(), b = cin.nextInt();
System.out.println(a + b);
}
}
使用JAVA的提醒:
Java程序的提交必须使用单个源文件.除了要遵守其他程序提交的规则之外,使用Java提交的程序还必须
从一个静态的main方法开始执行,并让该main方法置于一个名为Main的类中,否则将会导致Compile
Error(编译错误)的判答.遵守了上述规则的情况下,你可以实现和初始化任意需要的类.
在JDK 1.4下的一个标准程序如下:
import java.io.*;
import java.util.*;
public class Main
{
public static void main (String args[]) throws Exception
{
BufferedReader stdin =
new BufferedReader(
new InputStreamReader(System.in));
String line = stdin.readLine();
StringTokenizer st = new StringTokenizer(line);
int a = Integer.parseInt(st.nextToken());
int b = Integer.parseInt(st.nextToken());
System.out.println(a + b);
}
}
________________________________________
问题: 提交的时候可否使用快捷键?
解答: 以下是提交页面的快捷键
ALT+s 提交
ALT+u 用户名域(如果你还没有登陆)
ALT+l 编译语言选项
ALT+p 提交的题目ID号
________________________________________
问题: 请问提交的程序是如果被判答的?
解答: POJ首先将你提交的程序存为文件,然后试图按照你选择的编译语言进行编译.如果编译出现错误,
将会判答Compile Error.然后POJ运行您的程序,将输入数据送入程序,并且开始计时(记录程序的运行时
间).输入数据储存在一个或多个输入文件中.每一个文件都会用来判定你的程序并且只使用一次.在程序
执行过程中,如果POJ发现你的程序的运行状态符合Runtime Error, Time Limit Exceed, Memory Limit
Exceed 或者 Output Limit Exceed的标准,这些判答就会返回并结束.这意味着在TLE或者MLE的情况下,
不能确定程序是否能在充裕的硬件和时间条件下得到正确的结果.当你的程序跑完一个输入文件时,POJ将
会对你的输出文件和相应标准输出文件进行比较,或者在Speical Judge的题目时进行Special Judge.如
果输出是不正确的且不满足Presentation Error,将会给与Wrong Answer判答并结束.否则POJ将会继续进
行下一个输入文件的运行和处理.如果所有的输入文件都已结束,如果整个过程中没有遇到上述的6种错误
但是输出的符合Presentation Error的条件,将会给与Presentation Error的判答并结束.否则,恭喜
您,Accepted将会判答.
________________________________________
问题: POJ对提交程序的不同判答的意义?
解答: 下面是POJ所有的判答结果,缩写,和准确含义
Waiting: 你的程序正在被判答或者在等待判答.
Accepted (AC): 恭喜!您顺利通过了本题的所有测试数据!
Presentation Error (PE): 你的程序的输出格式和题目所要求的不是完全一致,但是输出的数据是正确
的.这一般是白字符(空格,tab和/或换行等白字符)的缺少或者多余或者空行的缺少多余所导致的.每行的
结尾的空格和输出的末尾空行不会被判成PE.请仔细检查输出的空格,空行等是否与要求的输出完全一致.
Wrong Answer (WA): 你的程序没有输出正确的答案。

为了简化判答,如果是Secial Judge 的题目,本该
判Presentation Error的程序也可能返回Wrong Answer.
Runtime Error (RE): 你的程序在执行过程中崩溃了. 可能的原因包括:非法文件访问,栈溢出,数组越界
,浮点异常,除零运算等等. 程序长时间不响应也可能被认为是发生了Runtime Error.
Time Limit Exceed (TLE): 你的程序运行的总时间超过了时间限制.每个题目有2个时间限制,即TOTAL
TIME LIMIT(总运行时间限制)和 CASE TIME LIMIT(一次运行时间限制).前者是你的程序运行所有的
输入文件数据的总时间限制,后者则是运行单个数据输入文件的限制. 两者之中只要有一个超时,就会导
致判答Time Limit Exceed. 如果你的程序被判答Time Limit Exceed,但是并没有超过总运行时间限制,
那就说明你的程序超过了一次运行时间限制.
如果题目没有特殊说明CASE TIME LIMIT, 那么将默认设置为与TOTAL TIME LIMIT相同的值,并且不会在
题目中显示出来.
Memory Limit Exceed (MLE): 你的程序使用的最大内存超过了内存限制.
Output Limit Exceed (OLE): 你的程序的输出超过了文本输出大小限制.目前文本输出大小限制被设置
为标准输出大小的2倍.最主要的原因是你的程序在包含输出的语句中陷入了无限循环的错误.
Compile Error (CE): 编译器在编译你的程序的时候发生了错误.警告信息不会被认为是错误.单击POJ对
你的程序的判答结果,可以看到编译器产生的错误和警告信息.
No such problem: 你提交的程序不存在或者不可用.
System Error: 你的程序无法运行.举例:你的程序需要比当前硬件条件下的内存多得多的空间.
Validate Error: Speical Judge程序无法正确检验你的输出文件. 可能是Special Judge 程序有错.如果
你的程序被判答Validate Error,请尽快通知管理员.(当然,这也意味着你的程序很可能是错误的).
________________________________________
问题: Special Judge的题目有什么不同?
解答: 但一个题目可以接受多种正确答案,即有多组解的时候,题目就必须被Special Judge.Special Judge程序使用输入数据和一些其他信息来判答你程序的输出,并将判答结果返回.
________________________________________
问题: 如何确定程序读入的终止?
解答: 大部分情况下,题目会在input中清晰地描叙输入数据如何结束,比如,test cases 的数目或者一
行全零的数据,等等.但是,有时候你必须用EOF结束符来确认文件的结尾.在这种情况下,你必须检查
scanf的返回值(返回有多少个值被成功的读入或者为0时返回EOF),对于cin,则可以类似的通过!cin来
确认.你可以参考Problem 1001的Hint进一步了解如果确定程序读入的终止.
________________________________________
问题: 为什么我的程序在GCC/G++ (C/C++)下被判成WA/TLE/RE,但是在C/C++ (GCC/G++)下被判成AC?
解答: 很可能是因为你的程序里的一些微小错误在不同编译器的因素下导致的不同判答。

我们建议您仔
细检查您的代码以找到错误。

另外一个可能的原因就是不同的编译器往往使用不用的函数,库,和设置
来生成可执行文件。

所以在特殊情况下,有可能不同编译器下生成的可执行程序会有不同的执行效率或
者执行结果。

比如,MS-VC++的栈的大小比在G++下的栈要大。

一个具有很深的递归的程序就可能出现暴
栈的情况。

如果你很肯定地认为你的程序在不同编译器下判答的差异是由编译器造成的,请联系我们。

________________________________________
问题: 有些题目的时间限制是1秒,但是有些程序却以几秒的时间AC了?
解答: 大部分这样的程序是Java程序。

众所周知,Java程序的运行速度比C/C++程序要慢很多。

所以对于
Java程序的时间限制也要长于普通时限。

确切的说,Java程序允许运行的运行时限是普通时限的3倍。


且给于150MS的多于时间作为I/O速度慢的补偿。

如果你的程序不满足上述条件,请联系我们。

________________________________________
问题: 我的程序仅仅超过时间限制15MS,我该怎么优化程序呢?
解答: 大部分情况下,你的程序实际上需要比时限多较多的时间来运行。

POJ会在题目的时限到达的时候
自动终止你的程序。

通常超时的程序会显示超过时限15MS。

一般的优化程序技巧包括缩小算法的常数和
采用更加有效的算法。

关于调试和测试:
(一). 下面是几种比较常见的错误:
1.输入输出格式错误
2.数据类型错误(尽量用大的类型)
3.范围检查错误(可以稍稍加大上下界)
4.变量名称错误
5.漏语句(看事先设计好的变量是否都用上了,然后看每个模块是否实现了应有的功能,是否完成了接口)
(二). 我们应对于每道题设计充分的测试数据,并保留那些比较具有代表性的测试数据,以便于优化的时候比对.
3. 一定要记住删除屏幕输出!
4. 最后一定要记住关闭程序中用于临时调试的特殊设置和语句!
5. 输出数据的每一行(包括最后一行)必须以一个换行符结束,行末不要保留多余空格。

对于每一道试题,在相应的目录中都有一个格式检查程序来检查输出文件格式的合法性。

该程序的文件名是:<shortname>_check。

格式检查程序仅仅检查输出文件名的正确性和文件格式的合法性而不检查结果的正确性。

检查结果显示在屏幕上。

6. 如果领队或参赛选手对评测结果有异议,可以填写相应的表格,并在评测结果公布后的三个小时之内提交评测委员会申请复议或复评。

当领队或参赛选手对复议或复评结果仍有异议时,应提交NOI科学委员会仲裁,并以NOI科学委员会的仲裁结果为该项评测的最终结果。

7. 调试的时候,一定要钻输入文件的牛角尖,考虑到各种情况。

8. 调试的时候,常常可以编一个非常非常易编的程序,采用算两次的方法,不过前提是必须保证正确。

9. Writeln是Fp中最笨但又是最准确的调试方法。

10. 调试时每发现一个错误,都最好浏览一下整个程序,看是否有类似错误,这样非常有效!
11. 在每一处可以中止程序的地方,都要看一看是否需要close file.
12. 程序出现不确定性的问题,如对于同样数据,有时死机,有时不死机,但多半都是随机模块有误!
13. 指针出错常常是出现了Nil^.Next
14. 递归程序的调试应该使用F7(F8)+Call Stack,尽量不要用F4。

15. 不要只顾埋头拉车,要抬头看路。

当被一两个子程莫名其妙的错误弄得晕头转向的时候,记住:很可能错误在其他地方。

16. 读写文件之前才打开文件,操作完毕立即关闭。

17. 每改完一个错误要想想是否改正确了,是否改彻底了,程序中(特别是有Paste的地方)是否有相同错误。

18. 很多题目最易忽视的就是初状态=末状态的情况,还有初状态和末状态存在可操作的决策。

(如Mars Explorer)
19. 多考虑一些特例,在这方面认真些,全面些,仔细些,常比多考虑些时空上限划算得多。

20. 编函数的时候千万别忘了给函数赋返回值,否则会引起随机性错误。

21. 调试语句一般和上下文保留一空行,最好加上注释,并且一定记住在最后删除。

22. 中途输出后结束一定要记住Halt
23. Byte,Shortint调试会以String类型出现,第一位以字符串长处理,遇到#0中止。

FP 和RHIDE中皆如此。

24. FP中的Extended类型有时候变量值未改变。

25. 调试和测试的时候一定要充分考虑到各种边界和特殊情况。

26. 自测时千万不要忘测数据上限,主要是看是否会超界。

大半错误均源于此!之后仔细察看Const中的数。

27. 大数组处理很容易出错,所以尽量避免开过大的数组及其调试。

28. 多维数组的调试RHIDE比FP Bug还多,而大数组多元素的查看可考虑使用RHIDE。

相关文档
最新文档