信息学竞赛之设计获胜策略.docVIP

?信息学竞赛之设计获胜策略?????一个好的取胜之道是制定在竞赛中指导你行动的策略。无论是在好的情况下还是在坏的情况下，它将帮助你决定你的行动。用这种方法你可以在竞赛中将时间花费在解决编程问题上而不是试图决定下一步该干什么…这有点像预先计算好你面对各种情况的反应。 心理上的准备也很重要。 竞赛中的策略 首先通读所有的题目；草拟出算法，复杂度，数量，数据结构，微妙的细节，… 集体讨论所有可能的算法 —— 然后选择最“笨”但却可行的算法。（注：请注意这一点，对参赛选手来说获奖就是唯一目的） 进行计算！（空间和时间复杂度，并且加上实际期望和最坏情况下的数量） 试图证明该算法错误（？？原文是Try to break the algorithm）—— 使用特殊的（退化的）测试数据。 将问题排序：根据你所需付出的努力，将最“短”（从原文理解是指解决问题费时最短）的问题排在前面。（从“短”到“长”的次序为：以前做过的，容易的，不熟悉的，困难的） 编写程序解决一个问题 —— 对每一道题而言，一次一道题 确定算法 构造特殊情况的测试数据 写出数据结构 编写并测试输入子程序（编写额外的子程序来显示数据输入的正确性） 编写并测试输出子程序 逐步细化：通过写注释来刻划程序的逻辑轮廓 一个部分一个部分地填充并调试代码 完成代码使其正常运转，并验证代码的正确性（使用一般情况的测试数据） 试图证明代码错误（？？原文是Try to break the code）——使用特殊情况的测试数据来验证代码正确性 逐渐优化——但足够了即可，并且保存所有的版本（使用困难情况的（即运行时间长的）测试数据来计算出实际运行时间） 时间安排策略和“故障控制”方案 ??? 制定一个计划决定在各种（可预测的！）故障发生时的行动；想象你可能遇到的问题并计算出你所希望做出的反应。核心问题是：“你何时花费更多的时间在调试程序上，你何时放弃并继续做下一题？”。考虑以下问题： 你已经花费了多长时间来调试它？ 你可能有什么样的BUG（BUG是指程序中的错误）？ 你的算法有错吗？ 你的数据结构需要改变吗？ 你是否对什么地方可能会出错有一些头绪？ 花费较短的时间（20分钟）在调试上比切换去做其他别的事要好；但是你或许能够在45分钟内解决另一个问题（？？原文是A short amount (20 mins) of debugging is better than switching to anything else; but you might be able to solve another from scratch in 45 mins.） 你何时返回到一个你先前放弃的问题？ 你何时花费较多的时间优化一个程序，你何时放弃当前优化工作而切换去作其他事？ 从这里考虑出去（？？原文是Consider from here out）——忘记先前的努力，着眼于将来：你如何才能就你目前所有的抓住下一个小时。 在你上交你的答案之前列出一个校验表： 在竞赛结束前五分钟冻结代码？（？？原文是Code freeze five minutes before end of contest?） 将所有的声明关闭。 将调试输出关闭。 确认输入输出文件名正确。 确认输入输出格式正确。 重新编译并再测试一次。 将文件以正确的文件名复制到正确的位置（软盘）。 提示和技巧 如果可以就用暴力法（即穷举法）解决 （注：居然将这条作为技巧，可见竞赛的目的就是获奖，为此要“不择手段”。） 键索引顺序搜索（KISS= Keyed Indexed Sequential Search）：简单就是聪明！（？？原文是KISS: Simple is smart!） 提示：注意限制（在问题陈述中指明） 如果可以给你带来方便的话就浪费内存（假如你能侥幸逃脱处罚的话） 不要删除你额外的调试输出，将它注释起来 逐渐地优化，足够了即可 保留所有的工作版本 从编码到调试： 空白是好的（？？原文是whitespace is good） 使用有意义的变量名 不要重复使用变量 逐步细化 在写代码之前先写注释 有可能的话尽量避免使用指针 避免使用麻烦的动态内存：静态地分配所有的东西。 尽量不要使用浮点数；如果你不得不使用，在所有使用的地方设置允许的误差（绝对不要测试两个浮点数相等） 对注释的注释： 不要写得太长，简洁的注解就可以了 解释复杂的功能：++i; /* increase the value of i by 1*/ 这样的注释是毫无意义的。 解释代码中的技巧 将功能模块划定界限并且document （？？原文是Delimit document functional