网络流小结
联赛过后,虽然遗憾的没拿到一等,但这不是止步不前的时候,于是我就学了学网络流,学了这几天,也该总结总结了......
网络流其实就是一种图论模型,在这种图中,边权变成了坑爹的流量,常见的最短路问题也变成了最大流-最小割问题
网络图和普通图的最大区别也就是边权不再是一个干干巴巴的数字,或者强赋意义的数量,而是真真正正地变成了一个具有实际意义的量—容量.我个人认为,这在现实中有着更广泛的应用,网络流量的分配,水流量的分配等诸多问题,都可以转化为这个模型,网络流具有十分广泛的应用,或许这也是它被称为图论的最高奥义的原因之一吧.
网络图的存储与普通的图并无太大不同,这也得益于邻接表这一巧妙的设计,我常用的存储方式是这样的:
struct edge {
int to , next , flow ; // 意义与普通邻接表相同,flow就是"边权",也就是容量
} ;就是这么一个结构体,当然这其中没有牵扯到费用,因为我还没学习最小费用最大流这类问题
而只知道如何存储是远远不够的,这只是一个小基础.网络流的第一步就是最大流问题,问题描述为:
对于一张只具有一个源点和一个汇点的网络,求出从源点到达汇点所能实现的最大流量.
这个问题与经典图论问题的区别显而易见,这时的边权/容量是一种限制,并且是可变的.而且,显然,对于一条路径的最大流,限制它的是它的最小弧容量.
一个很显然的思路是每次都尝试去在可行的范围内寻找还未满载的路径并使其达到最大流.这样一条未满载还可增加流量的路径称之为增广路.每次寻找增广路这个思路大的方向上是没有错的,事实上我们也正是这样做的.
但是,这样有一个很显然的问题,聪明的你一定已经想到了,那就是这会导致加入我们当前得到的可行流中的某一条弧属于一条更优的路径,那么这条更优的路径就会被阻塞而导致无法统计.而如果我们使用一贯的回溯思路来解决,那么复杂度就上升到了指数级,这种复杂度往往难以承受.
首先明确一个事实,从 \(u\) 流向 \(v\) 数值为 \(val\) 的流量 , 再从 \(v\) 流向 \(u\) 数值为 \(value\) 的流量等价于从 \(u\) 流向 \(v\) 的数值为 \(val-value\) 的流量
那么我们就需要一种设计,来使得不通过回溯也能完成所有可行流的统计.由此,我们对于一条弧 \((u,v)\) 建立它的反向弧 \((v,u)\) ,由于一开始并不能有任何的流量从 \(v\) 流向 \(u\) 所以一开始,反向弧的所有容量为0.每当我们正向流过 \(val\) 的流量,对应的反向弧就能反向流动 \(val\) 的流量.这种机制,正是 \(Edmond \: Karp\) 算法和 \(Dinic\) 算法的实现基础.反向弧的引入使得我们已经流过的流量有了流回来的机会,因此,它代替了回溯的作用.
那么一个非常自然的思路呼之欲出了:每次寻找一条增广路进行增广,最后统计出的答案就是最大流!
增广的过程也十分简单,把增广路径上所有的正向弧容量减去路径上最大的可行流,反向弧同时增大相应的容量即可
接下来的问题便是寻找增广路,一个很自然的想法是使用 \(bfs\) 或者 \(dfs\).而我们也确实是这么做的,只不过一般不使用 \(dfs\),它很容易变得很慢,于是我们就选用了喜闻乐见的 \(bfs\) ,稳定的 \(O(n)\) 复杂度相比较而言十分优秀.
明确了以上思路之后,就能得到一个正确也不太慢的最大流算法了,这就是\(Edmonds \: Karp\) 算法,简称 \(EK\) 算法.虽然正确性有了保障,而且也足以应付一些不太刁钻的数据,但它的复杂度是 \(O(n \times m^2)\) 的,十分的不理想.因此,我们需要一种更加优秀的算法,来保证时间复杂度.
To be continued......
标签：容量,增广,复杂度,路径,网络,流量,算法,小结 来源： https://www.cnblogs.com/Equinox-Flower/p/10633382.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。