……所以为什么省赛总结起了一个这种奇怪的标题……
尊重别人的委托 - 关于题目
除非完全失去了对生活的希望, 不然别人委托的工作还是至少应该抱着敬意来完成的。
先不论题目质量(10题中有3题可以网络流乱搞过去),题目中明显的失误就有不少。 虽然这并不在是说北邮的出题人不尊重他们的工作。 (其实可以看出他们已经努力了,Nice try.)
输出呢?经验是什么?数据范围呢???这种随便过一遍就能审阅出的明显问题, 出现在省级比赛上,真的不会让人看不起吗? 裁判组在比赛开始一刻钟有队伍提出质疑之后才(陆续)发现了此题中的各种问题。 即使是印刷了错误版本的题目,依然不能原谅吧?
Real contest? Faux contest?
即使用伦敦地铁用的字体也无法改变你英语差的事实。另外, 1Il只有用游标卡尺才能量出区别的字体用在科技类文本里大概不太好吧?
最后是一道没有人能读懂的题。敝校公认英语最强的两位队员没有一个看懂的。 感兴趣的读者可以挑战一下。要能够解释样例才行喔。
正直者之死 - 关于F题
于是上面写了那么多,到这里却才是本次省赛真正的亮点。 下面我就以此题最大受害者 [1] 的身份来讲述一下F题的故事……
首先来看一下题目(图片比较乱…):
实际上F题是容斥里面比较常规甚至可以说是相当简单的, 题目本身也可以说是中规中矩。思路其实很明显:设条件 x1≠x2 x2≠x3 x3≠x4 x4≠x1 分别为A, B, C, D,同时也用A, B, C, D表示符合相应条件的集合。 全集为仅需满足范围限制的四元组构成的集合。 容易发现答案并不好通过A, B, C, D的集合大小求得。 正难则反。∁A, ∁B, ∁C, ∁D及它们的交的大小更容易求得,而且 ∁(∁A∪∁B∪∁C∪∁D)恰好为所求的集合。多么基本的容斥……
然而事情从这里开始变得诡异了起来。作为一道容斥, 自然有把代码写成一坨屎的可能性。我的代码很不幸就写成了一坨。 写到75%的时候觉得头大,于是直接砍掉重练。这次相对来说比较顺利, 样例也是一发就通过了。然而, 以往根本不负责数学题的我[2] 对自己写的容斥持怀疑态度,决定写个暴力对拍一下。这下好。 最水(没样例水)的数据就把我的程序卡掉了。于是就开始挂机找问题。 这时比赛已经进行到了80分钟,我们队还没有瞟过一眼榜。于是找出榜一看, F题已经被过穿了。与此同时我还注意到这题的一血是开场6分钟 的时候被我校一支相对较弱的挂星队拿到的。这下更好了。 虽然是基本的容斥,但是按山东选手的水平,也不能6分钟写完吧? 于是就开始想自己是不是想复杂了,然后就开始试图换思路, 就有了题面附近大量乱七八糟的草稿以及下面这张图……
后来甚至想到了把整个区间分8段然后乘法原理强上的思路…… 然而因为依然难写所以也被否决了。此时的我,大概已是意识模糊,不省人事, 以至于当队友跟我说「还是继续容斥吧」之后, 我甚至无法用容斥手算出正确的结果了。。。 最后我就直接宣告死在了这道题上。另外一个队友最后30分钟试图用乘法原理强搞, 不过到比赛结束也没有搞出来。 [3]
当然如果事情就这么结束了的话,也不足以让这题成为本次比赛最大的亮点。 比赛结束后我问了一下那支6分钟过此题的队伍,得知他们 直接输出的四个区间长度的积。当时我就立刻晕了: 莫非是花了四个小时在完全不同的一道题上?不过这题这么短应该不会读错吧? 于是我试图询问他有没有对循环不等的条件有印象,他表示不知情。我…… 不得不猜测出题人rand生成的数据, 而且很不幸这106组数据里面没有一组区间有重叠部分的。 此时我的内心十分平静,甚至想对裁判组施展白帝圣剑: F题什么难度你们不知道吗?6分钟被人过了就不看眼他的代码吗? [4]
当然如果这件事情只有这么简单,显然依然不足以让此题成为本次比赛最大的亮点。 闭幕式之前在山财校园中闲逛时,听到了这样的对话:
——「有个队四层循环就过了。」
——「那有什么,我们队连样例都没过也过了。」
听到这段对话的我表面强装镇定,内心早已就地阵亡。 1042的计算量都能过,难道这题T=0?
后来通过官方渠道证实,这题在比赛过程中用于评测的数据是全空的。 还导致了最终裁判组和主办方之间意见的不一致。裁判组最后拒绝签字, 这其实是负责任的行为, 但是裁判组也可以以此把锅甩给PC^2和主办方所谓的「技术支持组」了。 首先,PC^2是一个浑身上下都是bug,设计上也存在一些问题的程序。 我们在配置17年校赛的时候,就遇到过PC^2无法保存题目名称的bug。 各种各样的连接问题也是数不胜数,Judge还会爆Java内存。但是即便如此, 裁判组仍然对此负有不可推卸的责任:如果在6分钟时就发现了问题, 完全有时间重新上传数据并进行重测,对比赛也不会造成太大影响。 而事到如今,这个6分钟通过的队伍, 让大量其他不应该如此快速「通过」此题的队伍「通过」了此题, 同时也对我们这样完全没有专攻数学题目的队伍造成了不可估量的打击, 最后还让各方闹翻。这样的疏忽……可以算是epic fail了。 至于推锅给「技术支持组」, 一个有多年出题经验的学校把锅丢给一个没几年ACM经验的学校, 可以说是非常不公了。当然由于我并不清楚这其中的分工, 所以并不好对此妄加评论。然而我认为主办学校的「技术支持组」, 本来就不应该负责太多与比赛直接相关的事务。
其实可以合理地预测, 比赛过程中没有验算而且在120分钟内通过此题的队伍,能够通过rejudge的 也许只是凤毛麟角。
至于这题对我队的影响,远没有未过一题这么简单。 已经理论掉的I题也因此驾鹤西去了。当然,经历了无数次「几乎成功」的失败之后, 我本人对此早已麻木,也就写不出×乎上那种动情的文字, 所有的心情只能汇集成一个「sigh」了。
然而以后碰到这种情况估计还是会死的。人家就是如此正直,你有什么办法。
不过讲道理总不能把自己成功的希望寄托在别人的失误上吧(
做最坏的打算 - 关于F题和其他
事已至此,任何的假设都成了虚拟语态。更应该考虑的显然是找一个合适的解决方案。 在这个问题上,即使我是「F题最大的受害者」,我仍然是十分理解裁判组的, 因为类似的事情在我们举办校赛的时候也遇到过。 所以我也没有像某些参赛者一样去「围攻」裁判组(我甚至没有加群), 因为我们都清楚被围攻的滋味并不好。从出题人在知乎上的表态看, 他们也承受着巨大的压力。 但是F题的问题实际上与出题人的关系不大——更多在于题目配置及比赛过程中的疏忽。 [5]
至于在如何处理的问题上,从自私的角度考虑,当然是删除F题对我们最有利:
因为这样我们队就变成第一了。其实无论是rejudge,维持原判还是直接删除,
对部分队伍来说都是不公平的。较为公平的解决方案,
无非是订正数据并延长比赛时间,甚至重赛。
但是无论是承办方还是从北京远道而来的裁判,谁能承受延时或者重赛的负担呢?
[6]
在组织程序设计竞赛的时候, 负责比赛准备的各方往往对比赛过程中可能发生的各种事故不做太多预案, 而是更多地依赖提前把问题减少到最少。然而人总是不可避免地犯错, PC^2也没有应对这种问题的功能(甚至全部重测的功能)。是时候让PC^2退休了。
一向阴暗的未来
与山东其他高校不同,山大的ACM实验室似乎即将成为各路教员追逐名利的工具。 真正一心为了实验室发展的人,不是根本没有,就是完全被边缘化了。
当然,在现在各方都没有任何实际行动的前提下,并没有办法得出什么实质性的结论。 不过,未来悬而未决的感觉也不好啊(
Fun facts &c.
- 苟狗写了全部AC代码。
难道我成功培养了新一代代码手 - 最后半小时队友试图抢救F题时,已经空状态的我在一边理论I题……
……实在惭愧 - 山财,作为一所刚刚开始搞ACM的学校,对这场比赛准备得可以说是很充分, 也十分有诚意了。为了防止发生去年滚榜时的尴尬情形, 他们甚至还提前排练了滚榜环节。 虽然后来发生了各种不可预见的事故导致榜没有滚成, 但是这不足以彻底抹杀他们为准备这场比赛付出的努力的。
- 至于北邮,这所已经为山东省赛命题(至少)两年的学校, 在命题这方面自然也可以说是十分有经验了。即使遇到了各种各样意料之外的事情, 也不应该完全否定他们的工作——因为出题本身就不是一个容易活啊。
- 14级学长的自嘲:「有了我们之后就再也没捧过杯」。
希望明年可以换种方式自嘲。