ACM-ICPC比赛随想——刘汝佳

       从第一次听说ACM/ICPC到现在，已经有快七个年头了。最开始因好奇而关注，而现在因了解而关注——关注比赛，更关注参加比赛的人。ACM/ICPC是一个五味瓶。没有接触过它的人不会知道其中的酸甜苦辣，而一旦置身其中，每个选手都会对它产生一种特殊的感情，时间越长，这种感情也越复杂、越浓烈。感情来源于对算法与题目的喜爱，来源于对成功的向往和失败的恐惧，来源于各种选择与放弃中的徘徊与摇摆不定，来源于程序世界与现实生活的巨大差异，也来源于通往理想的曲折道路——探索其中时的无助和艰辛。等到退役的那一天，回过头来再看当时的自己，相信每位选手都会发现自己的很多方面成熟了许多——远不只是编程能力和算法功底。以前我觉得这是比赛的副产品，而现在我认为这才是比赛的主要目的，至少对于选手自己是如此。

 

虽然我从心里喜欢这个比赛，但我并不鼓励每个人参加。并不是每个人在每个时期都适合参加这个比赛，且适合的人选也并不代表一定能取得好成绩——比赛场上是没有“一定”的，任何一个选手都必须有勇气承担风险，就像所有其他有潜在回报的事一样。另一方面，对于所有下定决心参加比赛的选手，我鼓励他坚持到底，因为只有这样才会受到真正的磨练。在“参加”与“不参加”的岔路口上，大多数选手被两个问题所困绕。第一个是“我能获奖么？奖会给我带来什么好处？”，第二个是“抛开荣誉，从比赛中学到的东西值得我花费这么多时间吗？”。第一个问题我无能为力，也不愿意回答，因为这取决于很多复杂的因素。而这些因素，更多的要靠自己把握。而对于第二个问题，我可以毫不犹豫的说：答案是肯定的，但前提是要视野开阔，不要把自己局限在一个狭小的空间之内。大家都知道，ACM/ICPC竞赛要求选手在理论上具有一定的知识和能力、编程上要求速度和正确性，但我认为更重要的一点是：ACM/ICPC培养选手实践能力和洞察力。这两点相对于理论和技术本身而言更难培养，也是高素质人才更需要的。这里的实践能力因追求生产效率和创造性而显著区别于依葫芦画瓢型的体力式的“技术能力”，而洞察力让有心的选手往各方面发展，让自己的才能展现到计算机科学、自然科学乃至艺术、人文方面的各个角落。一位MIT教授曾在课上对学生说：从某种意义下，计算机科学不是关于计算机的，它也不是一门科学。对于这样一个开放型事物，如果能够用洞察力寻找方向，用效率和创造性开辟道路，发展空间将是巨大的。

 

我的选手“生涯”是短暂的。三年半前夏威夷总决赛回来以后虽然有些不甘心，但我从心理上已经不再用选手的标准来要求自己了。随后在完成《算法艺术与信息学竞赛》的日子中，我的思维方式渐渐转向了教练和命题者，虽说少了比赛时的激情，但能更加理智和清醒的看待问题了。那本书是我正式出版的第一本著作，一个各种思想、知识、资源的复杂编织体，虽然有诸多遗憾，但是真实的反映了写作当时我的状态，相信不同动机和立场的人阅读时会有不同的感想和认识。竞赛的题目有着统一的外观，但它们背后的东西包罗万象。这些相关的知识都有着很强的应用背景，而非专门为竞赛而设计，因此有着独立的体系和相应的文献。程序设计语言、数据结构、算法设计方法、计算理论等内容都是经典的计算机科学分支，而高等数学、数论、组合数学、概率论、图论、组合游戏论、人工智能、计算几何、计算机图形学、生物信息学等内容也常见于各类竞赛中。虽然这些学科只有一小部分内容目前已经在题目中出现，但是对这些“小部分知识”的理解和实践将十分有利于对这些学科进行更全面、深入的学习。对任何知识的学习都离不开三方面：理论、模型和实现。理论部分相对容易把握，但要求学习时一丝不苟，善于总结、抓住本质。主要培养选手的洞察力；模型部分比较灵活，富有创造性，不管是模型的建立还是求解，都需要大量积累和思考。这也是最有启发性的部分，主要培养选手的创造力。实现部分比较自由，也是个人风格的体现，很难有一个固定的标准，但有很多前人经验和模式可以遵循。这部分有很多其他资料可以参考，也属于实践性最强的部分，主要培养选手的效率（当然也包括正确性。没有正确性就谈不上有效率）。有了前面的宏观叙述，这三方面孰轻孰重、关系如何，自然就很明了了。

 

对于大多数人来说，ACM/ICPC只是生命中一个很小的部分，但每一位有心的人都可以把这段经历变得重要而有价值。准备ACM/ICPC的日子是一段麻醉期，很多平时在意的时候都可以在准备竞赛时置之不理，也不去过多的考虑未来可能来临的烦恼。思想最单纯的时候做事是最有激情最快乐的，而在这样的时期，与志同道合的人建立的友情也是最可贵的。不管曾经、正在或者即将面临多大困难和艰辛，也不管结果如何，我想把一句话送给关注ACM/ICPC的每一个人：“ACM/ICPC is healthy, just do it.”

 

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/wq1987/archive/2009/09/10/4536780.aspx