1.致歉部分

本次推研机试场是我们头一次出函数式交互题，T3 额外子任务的交互库和数据都是由我全权负责的。

当然场上出了一些很明显的疏漏，给带来了较为糟糕的比赛体验。也暴露出了我们这几个月在函数式交互题工作上的问题。

本次比赛交互题目的问题如下：

• 在生成数据的过程中频频出现问题，导致对应提交链接迟迟未能上架；
• 最开始的空间限制配置有误；
• 没有在最开始给出白盒交互库；
• 未对数据生成器进行仔细查验，白盒/黑盒交互库使用了 sort 进行权值排序，导致交互库复杂度量纲（1 log）大于 std 复杂度量纲（线性）。不过这并不影响原始题目时限满足 2 倍 std 限制。

我对此致以诚挚的歉意，并保证做到以下内容：

• 之后再出伪随机生成数据的交互题时，会谨慎检查数据生成器的时间复杂度与常数；
• 对于考研初试 DSA 辅助练习的函数式交互题，其交互库均会作为白盒给出，历史题目将会在整理题解的同时公开交互库。

再次感谢 anon 酱对我们活动的参与和支持，也希望 anon 酱能够继续监督我们的工作。不光是推研机试，还有我们在这之后会持续更新的 DSA 辅助练习系列。

在此也祝 anon 酱初试复试都顺利，我个人非常期待以后能和 anon 酱在推研机试/DSA 辅助练习系列一起共事，把这项工作越做越好～

2.反驳部分

另一方面，关于 anon 酱的指控，也恕我们不能全部接受。当然下面的内容也都是基于客观事实，就事论事。如有任何异议，欢迎继续友好讨论。

本部分主要针对其在小红书上的这部分指控内容：

“然后没有技术含量就是卡常，硬卡常，3e6 的数据范围线性复杂度都过不去，开的 1.1 倍时限吗？？？交了 23 发才卡常卡过去，啊啊啊啊啊啊啊”

题目设计初衷

首先这个数据范围很显然，相比子任务 6 可以放过 2log 做法，子任务 7 需要强制让单 log 算法通过，子任务 8 需要让线性做法通过。

我个人认为这个数据梯度是非常明显的，至少场上有其他拿了 275 的选手都能够看出来。

关于时限设置问题

为什么我在当时没有看出交互库复杂度的明显问题，还会最终依然决定直接上架呢？

首先在跑性能测试的时候我其实就已经发现不对劲了，具体评测结果见这里，3e6 的数据范围在测试点 29 跑了将近 500ms，这怎么看也不像是这个数据范围下应该有的表现。

但是我在测过了初版线性 std（由 Fuyuki 提供），评测链接见这里，测试点 29 为 750ms，这意味着实际算法流程大约 250ms。在算法流程时限给 500ms 的情况下，满足 2 倍 std 时限。我们一直认为在这种情况下不需要再对时限进行修改，因此在看到 anon 的第 21 发线性提交后也一致决定不再修改。

关于选手代码的问题

首先从题目修改的时间轴来看，修改空间设置并重测是在 anon 酱的第 9 发提交之后，提供白盒交互库在第 19 发提交之后。

anon 在小红书上认为“没有任何技术含量，只有卡常”，但是纵观全部 23 发提交（所有代码公众可见），前 20 发提交均为单 log 的，仅最后 3 发为线性。那前面的这一堆提交到底卡常在哪？

此外，anon 酱的线性提交是否在常数上真的优秀呢？答案也是否定的。

我们在赛后对额外子任务调整的过程中，又在 $5\times 10^6$ 的数据范围下进行了一次测试（此时交互库大约占 300ms）：

• Fuyuki 基于线段树实现的单 log 代码
• anon 场上的线性代码

可以看到两者在峰值时间上是差不多的，因此从我们作为命题者的视角，就算真的被卡了其实也并没有什么意外的。

综上，有关卡常的指控，至少从组织方的角度来说，我们是不予认可的。

当然了，在更新了终版 std 之后，纠结卡常的问题也没有任何必要了，除了 std 的写法其他的线性做法基本都寄了（笑）