Result

21st(35th) place

Replay

Z 先读了 D，再读了 J，然后想了一个没 log 的做法，但是漏了情况。写了 J 然后 wa 了。D 读了 A、H，W 读了 H、G，然后一起在想 H。想了一个 \(\log^2\) 的做法，但是觉得太麻烦 W 把写了 1/3 的 D 踢下来了。

Z 跟 W 讨论 D，然后 W 给了一个对每个 \(i\) 弄一个单调栈的做法，Z 去写了，写到一半说内存开不下，W 说用 stl 开得下（这个时候 W 觉得 Z 过于紧张）。Z 写完 D 但是没过样例，W 和 D 讨论出了 A 的贪心，W 踢下 Z 去写 A（Z 后来觉得不应该换人而应该继续调试，但是 Z 应该主动拒绝）。W 写完 A，没测样例，打印出来看，然后让 Z 继续调 D（魔幻操作）。W 看了一会儿 A 觉得没问题，又踢下 Z 开始跑样例，样例 2 没过，又换上 Z 开始调试 D。W 又踢下 Z 开始调试 A，一小会儿之后把 INT_MIN 改 INT_MAX 然后过了 A。

Z 又上来调试 D，然后过了 D。D 和 W 说了 E 的做法，觉得没问题，D 也觉得 E 比 H 好写，然后就去写 E。这之前 W 和 D 也讨论出了 G 题，但是先放着。D 写 E 的时候，W 给 Z 说了一下 H 题意，想找一个更好写/复杂度更好的做法。但是，神奇的事情发生了，W 和 Z 交流出现了偏差，Z 理解错了题意，也没看样例，然后给了 W 一个更好的做法，但是 W 也没仔细听。D 写完 E 之后（写 E 的时候 W 说 G 有问题）测了测没过样例，改了错之后交了 wa 了，打印出来在旁边查错。W 和 D 看了很多遍，觉得没有写错，开始想漏掉的 case。

这个时候 Z 开始上去写 H（并且删掉了 D 一开始的代码），写了一会儿。W 和 D 被 E 题搞疯了，因为没觉得有错，这个时候更糟糕的事情发生了，Z 写完了开始测样例，没过，调了一会儿之后，他说话了：“我好像看错题了。“ W 和 D 心态崩了。换 D 继续写一开始的 H，但是写了一点，Z 说他来想办法 fix 一下 H，所以又换 Z 上机。这段时间想出了 E 漏掉的 case，改掉之后过了 E。Z 又说 fix 不了，又换 D 写 H 题。

D 写完 H 之后，测了一会儿交了 RTE，发现数组开小了改掉过了 H。W 和 Z 讨论了一下 J，现在带 log 的做法没问题了，然后就去写 J，但是写到一半发现有些 case 要多想一下，就下来了。现在 W 又觉得 G 没问题，就去写 G 了，写完之后没 init re 了，改了之后还 re，本地调了一下改了过了样例，还造了点数据（非法数据）然后过了提交就过了 G。Z 继续写 J，写完之后交了 wa 了，W 写了个对拍拍了小数据调试，fix 了几个小错误然后提交过了 J。

最后还剩下 20 分钟，rush 读了一下 B 题，但是感觉没时间了，就摸了。最后吃了一下 roasted beef sandwich 觉得太难吃了（那个午餐调查问卷到底有什么用啊？），然后吃了点 chips D 说真 tm 好吃。

for 刘子渊

为什么时光不能倒流

• 中途换人/换算法：H 题 W 不应该把 D 踢下去。Z 也不应该把 D 的代码删掉。就算有更好的写法，但是一个显然是正确的，写了一半的代码，不应该放弃。

• 上机之前检查题意/算法：有一个人（比如 W）提醒一遍注意事项，包括画样例等。算法也有两个人 double check。

• 题目没读完：不管如何，找一个人读完题（W），一定要读完题。

• 交流产生歧义：交流题目/题意的时候，一起画样例，或者演示一遍算法流程。

• case 题目：J 题的各种 case 应该想得更清楚一些再去写。在纸上把 case 列出来，便于检查和补充。

• 如果H多想几分钟，用栈维护树上差分换掉启发式合并优先队列，用差分换掉环上的树状数组，就是线性的时间复杂度，就不会发生被踢掉的事情，coding时间也能少个几分钟。

• 如果E能不漏掉情况，一次提交就通过，就能在Z上H之前要求Z讲一次算法；或者在E wa掉之后打印代码让W检查有没有写错，和Z再确认一次H的做法。

• 如果W在训练时没有养成随时打断别人读题给人喂假题的习惯…

• 如果一道题目要完全改变做法，写的两个人要沟通达成一致。

Q&A

Z 先读了 D，再读了 J，然后想了一个没 log 的做法，但是漏了情况。写了 J 然后 wa 了。

• Q: 为什么会先做 J？？？
• A: 因为按照错误想法很好写。

D 读了 A、H，W 读了 H、G，然后一起在想 H。想了一个 log^2 的做法，但是觉得太麻烦 W 把写了 1/3 的 D 踢下来了。

• Q: 应该先做 A，因为 A 比较简单，看完题就应该有思路。 W 和 D 应该想清楚了才可以上机。以后算法出锅的话要有两个人对此负责。
• A: D的A这时还没读完，W喂H的题意打断了A。H通过的算法一开始就想清楚了，虽然不是线性的但是D第一反应是这个。

Z 跟 W 讨论 D，然后 W 给了一个对每个 i 弄一个单调栈的做法，Z 去写了，写到一半说内存开不下，W 说用 stl 开得下（这个时候 W 觉得 Z 过于紧张）。Z 写完 D 但是没过样例，W 和 D 讨论出了 A 的贪心，W 踢下 Z 去写 A（Z 后来觉得不应该换人而应该继续调试，但是 Z 应该主动拒绝）。

• 这里我赞成 W。当然具体应该看场上情况。如果是我们队的话可能会给 10min 调试，同时在场下确认 A 的细节，或者去读新题。

W 写完 A，没测样例，打印出来看，然后让 Z 继续调 D（魔幻操作）。W 看了一会儿 A 觉得没问题，又踢下 Z 开始跑样例，样例 2 没过，又换上 Z 开始调试 D。W 又踢下 Z 开始调试 A，一小会儿之后把 INT_MIN 改 INT_MAX 然后过了 A。

• 如果有另外一个比较短的题的话，我会选择 W 的做法。打印出来静态读一下代码逻辑确认有没有问题。但如果没有的话，我不会选择 W 的做法，因为会打断另一个人的完整性。
• 不应该频繁换人。

Z 又上来调试 D，然后过了 D。

D 和 W 说了 E 的做法，觉得没问题，D 也觉得 E 比 H 好写，然后就去写 E。这之前 W 和 D 也讨论出了 G 题，但是先放着。

D 写 E 的时候，W 给 Z 说了一下 H 题意，想找一个更好写/复杂度更好的做法。但是，神奇的事情发生了，W 和 Z 交流出现了偏差，Z 理解错了题意，也没看样例，然后给了 W 一个更好的做法，但是 W 也没仔细听。

• 如果没心思仔细听就直接打断说没心思听。确保队伍成员之间的交流是有效的。
• 想完做法后第一件事先看样例，验证做法。如果计算过程特别复杂的话可以跳过这步。

D 写完 E 之后（写 E 的时候 W 说 G 有问题）测了测没过样例，改了错之后交了 wa 了，打印出来在旁边查错。W 和 D 看了很多遍，觉得没有写错，开始想漏掉的 case。

• Q：G 不应该是板子题吗？
• A：W也不是第一次怀疑板子有问题。

这个时候 Z 开始上去写 H（并且删掉了 D 一开始的代码），写了一会儿。W 和 D 被 E 题搞疯了，因为没觉得有错，这个时候更糟糕的事情发生了，Z 写完了开始测样例，没过，调了一会儿之后，他说话了：“我好像看错题了。“ W 和 D 心态崩了。换 D 继续写一开始的 H，但是写了一点，Z 说他来想办法 fix 一下 H，所以又换 Z 上机。这段时间想出了 E 漏掉的 case，改掉之后过了 E。Z 又说 fix 不了，又换 D 写 H 题。

D 写完 H 之后，测了一会儿交了 RTE，发现数组开小了改掉过了 H。

W 和 Z 讨论了一下 J，现在带 log 的做法没问题了，然后就去写 J，但是写到一半发现有些 case 要多想一下，就下来了。现在 W 又觉得 G 没问题，就去写 G 了，写完之后没 init re 了，改了之后还 re，本地调了一下改了过了样例，还造了点数据（非法数据）然后过了提交就过了 G。Z 继续写 J，写完之后交了 wa 了，W 写了个对拍拍了小数据调试，fix 了几个小错误然后提交过了 J。

最后还剩下 20 分钟，rush 读了一下 B 题，但是感觉没时间了，就摸了。最后吃了一下 roasted beef sandwich 觉得太难吃了（那个午餐调查问卷到底有什么用啊？），然后吃了点 chips D 说真 tm 好吃。

• 中间谁在跟榜读题？之后需要有一个人对队伍决策进行跟踪，同时监控场外情况。