• CF985G


    这题的计数部分还是挺有趣的,虽然涉及到的知识以及思维难度并不难。


    映入脑帘的是建补图然后三元环计数。但那样边数没有保证。

    正难则反,我们考虑先求所有三元组的贡献和,然后减去至少有一条边的。u1s1 普通的正难则反不容易想到,但这题是要求反,实际上是个「反难则正」,这应该很容易想到吧(

    总贡献的话,把加法拆开,算每个点的贡献即可。就加一加它作为最小、次小、最大的贡献,容易算出。

    然后是至少有一条边的三元组。那就分成一条边、两条边、三条边来算。

    一条边:似乎不是很好算。考虑这样一个过程:对每条边,算出所有其他点与这两个点的贡献和,最后加起来。这样得到的既不是恰好一条边的,也不是至少一条边的,而是一条边的算了一次,两条边的算了两次,三条边的算了三次。那么我们如果知道了两条边、三条边的答案,一条边也就出来了,而本来也要求这两个,难度没变化。于是不妨就这样搞。而这个非常容易算,还是枚举这两个点的排名,想必来做这题的人都不用听了。

    两条边:似乎也不是很好算。考虑统计每条三元链的贡献和,这样得出来的是两条边一遍,三条边(三元环)三遍。那么如果求出这个和三元环的答案,两条边也自然就出了。而三元环是本来就需要算的,难度并没有增加。于是不妨就这样算。那么这玩意怎么算呢,考虑对一个特定的点的有序邻居序列做事情,显然可以分成左右两部分,分别小于和大于该点编号。那么考虑一个类似分治的东西,算左边的内部的、右边内部的、一左一右(像 * 的 ***)的,都好算(

    三元环就直接套板子吧。

    总结一下,对一条边和两条边这两个难算的东西,我们并没有硬刚,而是通过类似正难则反的「总值减去好算的剩下值」的方式算,包括开头的反难则正也是这个道理,容斥大概也有这味。计数 / 贡献统计类题目做法的本质其实就是不断地把难算的转化为容易算的。

    珍爱生命,远离抄袭!
  • 相关阅读:
    emgu比对.txt
    【RequestContextHolder】SpringMVC之RequestContextHolder分析
    【JdbcTemplate】springboot之多数据源配置JdbcTemplate
    Spring Boot配置过滤器的两种方式
    【过滤器异常全局处理异常】全局统一异常处理无法拦截filter中catch的异常
    【内部类】使用
    冒泡排序选择排序插入排序
    JavaScript深入之new的模拟实现
    Java———static关键字,代码块,abstract关键字,interface,内部类,异常处理
    java 面向对象思想
  • 原文地址:https://www.cnblogs.com/ycx-akioi/p/solution-cf985g.html
Copyright © 2020-2023  润新知