2017-C04-team7

从 Trac 迁移的文章

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

原文章内容如下：

== zhhhplus ==

流水账：今天trac崩了呢，多亏了jtjl哥哥堇业。今天我们队可以说螺旋爆炸，开场过了两个签到题（C和K）之后，就再没有动过了。在一个小时左右的时候，我和wyz讲了B题的一个扫描法（在此之前曾经给出一个错误的做法），觉得非常可行，非常直观，非常正确，就让wyz敲代码去了，缩在一边想别的题目，比如E，F和H，觉得E题可能要比较麻烦的处理（实际上是没学过AC自动机，所以并没有自动AC），和chy讨论了一下F，chy说也许可以用dfs序做，但是没有什么明确的想法，我没往这边想，倒是想到了一个直接在树上维护的做法，但是chy和wyz以链状时退化为由驳回了，随后和chy讨论觉得树链剖分很正确，其后也是这样想着做的，让chy打了个板子，然而没有正确地使用它，加上机器都被占用来写B题，所以到了最后爆炸的景象。

总结：作为嘴巴选手果然不能评判一道题的实现复杂度，作为队长选择了硬刚B题，辅助调F题的策略可以说非常蠢了，直接导致几乎整场比赛都在调B的细节上了，没有想着趁这个时候多开两题来挽回一下。以及队伍中缺乏字符串选手也导致不难的E题没有被做出来。另外在队员debug不出，心态爆炸的时候，只能做到自己不慌，而不能做到安慰队友，令队友也不慌，可以说非常失职，掌握说学逗唱是本分啊。在晚上调了很久的A之后，觉得计算几何除非在想算法之后把细节都思考得差不多，还是不要贸然开题比较好，比如跟线有关的就要考虑共线，共点等等情况，估算一下它的实现复杂度，以及看榜，来决定到底开不开，有时候有了正确的算法也不应该贸然写题的。其余检讨交给两位队友来做吧。还是希望心态能够平稳一点。

== hanyi0923 ==

这次比赛的结果非常差，我自己总结出几个重点：

1. 应该更冷静看题，并且敢于开题，例如这次F, H都比当时想的还简单很多，但是赛中往错误的方向想了很久，最后也没做出（赛后已经过题）。

2. 有细节的题必须仔细判断，不应该贸然开题，以免造成全队卡题。

3. 个人能力还是有待提高，例如E题的AC自动机DP我赛中完全没办法做（赛后已经过题、已经掌握知识点）。

== zju_wyz ==

这两场比赛，我的问题暴露的很明显。对于细节比较多的题目，在只有算法框架没想明白边界情况的情况下贸然上机，很容易会造成细节爆炸，代码膨胀，最后陷入越写越难维护还必须要写的循环。今天的 B 题，逻辑并不复杂，只是需要考虑的边界情况有点多，这就导致第一遍码完代码之后，不断地修改初始化，不断地调整后面循环的顺序。大部分时间是在做无用功，而且很容易影响全队的心态。

最后十分钟，虽然终于是得到了理论上可以 AC 的代码，但是由于偏序关系没有注意，最后还是 sort() 里死循环然后 T 了，四个小时的努力打了水漂。写挂的 comp 函数挂在下面，引以为戒。

== other ==


``
bool comp(const pii& a, const pii& b)
{
    /*if (a.fi == 0)
    {
        return true;
    }
    if (b.fi == 0)
    {
        return false;
    }

    return (1.0 * a.se / a.fi < 1.0 * b.se / b.fi);

    本意是将斜率不存在的点放前面先处理

    但是这样就造成 (0,0) > (0,1)，(0,0) < (0,1)同时成立的尴尬局面

    */

    if (a.fi == 0)
    {
        if (b.fi == 0)
        {
            return a.se < b.se;
        }
        return true;
    }

    if (b.fi == 0)
    {
        return false;
    }

    return (1.0 * a.se / a.fi < 1.0 * b.se / b.fi);
}


``
补题：B(√)E(√)F(√)H(√)I(√)

zhhhplus

流水账：今天trac崩了呢，多亏了jtjl哥哥堇业。今天我们队可以说螺旋爆炸，开场过了两个签到题（C和K）之后，就再没有动过了。在一个小时左右的时候，我和wyz讲了B题的一个扫描法（在此之前曾经给出一个错误的做法），觉得非常可行，非常直观，非常正确，就让wyz敲代码去了，缩在一边想别的题目，比如E，F和H，觉得E题可能要比较麻烦的处理（实际上是没学过AC自动机，所以并没有自动AC），和chy讨论了一下F，chy说也许可以用dfs序做，但是没有什么明确的想法，我没往这边想，倒是想到了一个直接在树上维护的做法，但是chy和wyz以链状时退化为由驳回了，随后和chy讨论觉得树链剖分很正确，其后也是这样想着做的，让chy打了个板子，然而没有正确地使用它，加上机器都被占用来写B题，所以到了最后爆炸的景象。

总结：作为嘴巴选手果然不能评判一道题的实现复杂度，作为队长选择了硬刚B题，辅助调F题的策略可以说非常蠢了，直接导致几乎整场比赛都在调B的细节上了，没有想着趁这个时候多开两题来挽回一下。以及队伍中缺乏字符串选手也导致不难的E题没有被做出来。另外在队员debug不出，心态爆炸的时候，只能做到自己不慌，而不能做到安慰队友，令队友也不慌，可以说非常失职，掌握说学逗唱是本分啊。在晚上调了很久的A之后，觉得计算几何除非在想算法之后把细节都思考得差不多，还是不要贸然开题比较好，比如跟线有关的就要考虑共线，共点等等情况，估算一下它的实现复杂度，以及看榜，来决定到底开不开，有时候有了正确的算法也不应该贸然写题的。其余检讨交给两位队友来做吧。还是希望心态能够平稳一点。

hanyi0923

这次比赛的结果非常差，我自己总结出几个重点：

1. 应该更冷静看题，并且敢于开题，例如这次F, H都比当时想的还简单很多，但是赛中往错误的方向想了很久，最后也没做出（赛后已经过题）。

2. 有细节的题必须仔细判断，不应该贸然开题，以免造成全队卡题。

3. 个人能力还是有待提高，例如E题的AC自动机DP我赛中完全没办法做（赛后已经过题、已经掌握知识点）。

zju_wyz

这两场比赛，我的问题暴露的很明显。对于细节比较多的题目，在只有算法框架没想明白边界情况的情况下贸然上机，很容易会造成细节爆炸，代码膨胀，最后陷入越写越难维护还必须要写的循环。今天的 B 题，逻辑并不复杂，只是需要考虑的边界情况有点多，这就导致第一遍码完代码之后，不断地修改初始化，不断地调整后面循环的顺序。大部分时间是在做无用功，而且很容易影响全队的心态。

最后十分钟，虽然终于是得到了理论上可以 AC 的代码，但是由于偏序关系没有注意，最后还是 sort() 里死循环然后 T 了，四个小时的努力打了水漂。写挂的 comp 函数挂在下面，引以为戒。

other

``

bool comp(const pii& a, const pii& b)

{

/*if (a.fi == 0)

{

return true;

}

if (b.fi == 0)

{

return false;

}

return (1.0 * a.se / a.fi < 1.0 * b.se / b.fi);

本意是将斜率不存在的点放前面先处理

但是这样就造成 (0,0) > (0,1)，(0,0) < (0,1)同时成立的尴尬局面

*/

if (a.fi == 0)

{

if (b.fi == 0)

{

return a.se < b.se;

}

return true;

}

if (b.fi == 0)

{

return false;

}

return (1.0 * a.se / a.fi < 1.0 * b.se / b.fi);

}

``

补题：B(√)E(√)F(√)H(√)I(√)