2018-team8-E06

从 Trac 迁移的文章

这是从旧校内 Wiki 迁移的文章，可能存在一些样式问题，您可以向 memset0 反馈。

原文章内容如下：

[[Image(day6.png)]]

== 流水账 ==

zhhhplus: 一上来大家纷纷把A过了，lsy就去把A题1A了，然后发现L题很签，然后发现B题很签，在我写L题的时候cyw发现I题很签，在lsy写B题的时候，随便讨论了一下，发现K题也很签。我写的L题代码把我们电脑搞死机了两次，有不好的预感，于是决定先写别的。接着在cyw写K题的时候，我们把C题搞出来了，是个随便枚举二进制的sb题。接着就一下子5个1A签掉了5个题，剩下个L题，结果好像因为很多奇怪的精度错误导致了3发罚时，中间我和lsy讨论了一下E题，提出了nlogn建个图来想的想法，然后跟着这个图发现了一个贪心的规律和无倍数节点处理的问题要点，想了一个有两个堆的做法，结果因为一些细节的错误WA了1发，然后又WA了，我开始怀疑算法的问题，构造了个数据发现确实能卡掉它，过了一段时间之后我想到了一个做两遍更新答案的做法，去写了一下，因为细节问题WA了两发才过。接着lsy和cyw此时想好了H题的大致做法，并且去写了一些，我突然发现G题似乎可以求一下点双联通分量然后随便找圈看有没有剩下的点或边来处理，问了一下cyw觉得两个哪个更加能写完，大概还是点双比较短一些，于是决定集火G题，之后到结束都没有调出来，出了一些奇奇怪怪的小bug，以及点双板子随便处理了割顶，非常糟糕，场上大概是过不了了。

== 总结 ==

zhhhplus: 这场签到题巨多，L题精度处理有点糟糕，赛后发现long double就能过，而我们写了系统sqrt边上枚举才过的。做H题还是G题这点，可能是我高估了H题算法的实现难度，低估了G题的实现难度，以及想到了点双的做法之后就没有考虑dfs树的做法（因为点双很正确……），果然下次写中档题之前应该好好考虑一下题目有没有更方便实现的算法。

== 补题 ==

 * G: LIN452
 * H: Pepcy_Ch, LIN452

流水账

zhhhplus: 一上来大家纷纷把A过了，lsy就去把A题1A了，然后发现L题很签，然后发现B题很签，在我写L题的时候cyw发现I题很签，在lsy写B题的时候，随便讨论了一下，发现K题也很签。我写的L题代码把我们电脑搞死机了两次，有不好的预感，于是决定先写别的。接着在cyw写K题的时候，我们把C题搞出来了，是个随便枚举二进制的sb题。接着就一下子5个1A签掉了5个题，剩下个L题，结果好像因为很多奇怪的精度错误导致了3发罚时，中间我和lsy讨论了一下E题，提出了nlogn建个图来想的想法，然后跟着这个图发现了一个贪心的规律和无倍数节点处理的问题要点，想了一个有两个堆的做法，结果因为一些细节的错误WA了1发，然后又WA了，我开始怀疑算法的问题，构造了个数据发现确实能卡掉它，过了一段时间之后我想到了一个做两遍更新答案的做法，去写了一下，因为细节问题WA了两发才过。接着lsy和cyw此时想好了H题的大致做法，并且去写了一些，我突然发现G题似乎可以求一下点双联通分量然后随便找圈看有没有剩下的点或边来处理，问了一下cyw觉得两个哪个更加能写完，大概还是点双比较短一些，于是决定集火G题，之后到结束都没有调出来，出了一些奇奇怪怪的小bug，以及点双板子随便处理了割顶，非常糟糕，场上大概是过不了了。

总结

zhhhplus: 这场签到题巨多，L题精度处理有点糟糕，赛后发现long double就能过，而我们写了系统sqrt边上枚举才过的。做H题还是G题这点，可能是我高估了H题算法的实现难度，低估了G题的实现难度，以及想到了点双的做法之后就没有考虑dfs树的做法（因为点双很正确……），果然下次写中档题之前应该好好考虑一下题目有没有更方便实现的算法。

补题

  • G: LIN452
  • H: Pepcy_Ch, LIN452
附加文件