FAQ of forum

复赛相关

复赛的小组赛阶段是一个上午，允许根据现场显示的得分情况继续修改代码。很多编程比赛都是允许甚至鼓励现场修改代码的，我们去年的第一届比赛也是留下了现场修改代码的时间。

官方出的5个case埋的坑应该都不一样吧 5个case应该要有各自的特点，如果都是同一个坑点，那么对某类弱于此而长于其他的算法不好评价吧 希望官方能说一下是否都是不同坑点，让我们有个心理准备 好考察全面点，不然总会有人可乘之机吧

A: 倒也不能算是坑，也是根据实际网上运行的特点总结出来的一两种极端的情况，等比赛完我们找个时间再详细介绍下吧。

楼主的建议挺好的。这个”一套算法“的问题，的确是引起了很大的争议。大家对比赛的重视有些超出我们的预期，在此也非常感谢大家的热心参与。

第一个背景：

本来这个比赛是没有什么对战PK的，但是因为是算法题，内部评审的时候，大家担心太枯燥，希望增加一些趣味性。而且从去年第一届的比赛经验看，PK捉对厮杀的方式很受欢迎，所以最后增加了自己设计用例进行对抗的环节。

由此就引入了另外个问题，如果选手自己的程序有针对性的对自己的用例进行优化，这个对战环节将毫无意义，所以就引入了”一套算法以及参数“的规定，然后由此带来了无穷的解释和争议。

第二个背景：

在4月份举办了一次我们公司内部的算法比赛，就是大家做的这个题目的原型。有两个选手很有意思，一个选手使用了多进程，每个进程跑一种算法，在截止时间到了以后比较各个进程的结果输出一个最优解；另外一个选手使用了遗传算法，通过不断的提交调整随机数种子，这两个选手的得分都比较高，但是最终并没有获奖，因为我们最后还有一个专家评审环节，对于这两位选手，比赛用例得分虽然很高，但是算法被评判为没有实用价值。

第三个背景：

本次校园大赛，除了想通过比赛选拔出一些编程高手外，还有一个目的，是希望看看能否找到一些好的思路帮我们解决问题，这个未来网络寻路的算法仍然有很大的改进空间，出于这个原因，我们也按照实际业务场景规定了一套算法和参数的要求。

对于本次比赛中出现的各种问题，我们也会不断进行总结，明年还会举办第三届，争取办得更好，让大家感受到更多软件的魅力和比赛的乐趣。

非常感谢大家的关注和参与。