flow

传送门 题意： 给出一个 \(n*m\) 的迷宫，有 \(a\) 个入口, \(b\) 个出口。 现在有 \(a\) 个机器人都从入口出发，一开始方向默认为下，你可以选在在一些格子上面放置一个转向器，转向器有四种： 向下走变为向右走； 向下走变为向左走； 向上走变为向右走； 向上走变为向左走。 每个格子最多放一个转向器。 问最后是否存在一种方案，使得每个机器人都能到达从其中一个出口。 思路： 因为题目要求转向器只能接受固定方向，并且变为固定方向，所以有几个比较重要的观察： 不存在两个机器人的路线共线； 若一个格子上存在转向器，那么至多只能经过一个机器人； 若一个格子上没有转向器，那么可以经过两个方向垂直的机器人。 观察一挺好证明，若存在两个机器人共方向，说明其中一个机器人经过转向器，而另一个没有经过，出现矛盾。后面几个yy一下应该好理解。 所以现在问题就是，一个格子只能横向经过或竖向经过，若经过转换器，只能经过一次，问能否使得 \(a\) 个机器人成功走到终点。 考虑网络流，我们将点拆成两类：一类是“水平”类点，另一类是“垂直”类点。那么一开始我们有水平和水平的相连，垂直的和垂直的相连，流量为 \(1\) 。 考虑经过转换器时，方向发生了变化，那么我们对于一个点，允许其向另一个方向转化，流量为 \(1\) 。 容易发现这样的建图刚好符合上面的要求。 PS：网上代码很多都是错的

参数传递是调度字体工作流运行时非常重要的一部分，工作流的执行，单个作业的执行，多个工作流之间的依赖执行，历史任务重算，都涉及到参数传递和同步。 1 参数类型综述 azkaban的工作流中的参数可以分为如下几个类型： Azkaban UI 页面输入参数 环境变量参数 job作业文件中定义的参数 工作流的用户定义的属性文件，上游作业传递给下游的参数 工作流运行时产生的系统参数 job的common参数 参数类型与其对应的参数范围如下： 参数类型 作用域 UI 页面输入参数 ，即工作流参数 flow全局有效 工作流ZIP压缩包中的属性文件（.properties结尾） flow全局有效,zip文件目录以及子目录有效 工作流运行时参数 flow全局有效 环境变量参数 flow全局有效 job的common参数 job内局部有效 JOB文件中定义的参数 job内局部有效 上游作业传递给下游的参数 job内局部有效 2. job 参数简介commom参数 除了 type , command , dependencies 三个参数外，还有如下一些保留参数可以为每个job配置 参数 说明 retries 失败的job的自动重试的次数 retry.backoff 重试的间隔（毫秒） working.dir 指定命令被调用的目录。默认的working目录是executions/${execution

最大流 #include<bits/stdc++.h> using namespace std; #define inf 0x3f3f3f3f const int N=1e4+10; const int M=1e5+10; struct Edge { int to, next, w; } edge[M<<1]; int head[N],cur[N],pos=1,level[N]; void add(int a, int b, int c) { edge[++pos] = (Edge){b, head[a], c};head[a] = pos; edge[++pos] = (Edge){a, head[b], 0};head[b] = pos; } bool bfs(int s, int t) { memset(level, 0, sizeof level); queue<int> q; level[s] = 1; q.push(s); while (!q.empty()) { int pos = q.front();q.pop(); for (int i = head[pos]; i; i = edge[i].next) { int v = edge[i].to; if (!edge[i].w || level[v]) continue; level[v] = level[pos]

一：SDN控制平面 一个或多个SDN控制器组成，是网络的大脑。  对底层网络交换设备进行集中管理，状态监测、转发决策以及处理和调 度数据平面的流量；  通过北向接口向上层应用开放多个层次的可编程能力。 （一）典型的SDN控制器体系架构 SDN控制平面分为6层 南向接口层主要对各种南向接口协议的支持，如Open Flow，Netconf,OVSDB等，控制器通过接口层的通道实现对底层网络的管理 抽象逻辑层主要是将服务抽象出来，实现各种通信协议的适配，为各模块和应用提供一致的服务 基础网络层在任何控制器中都是必不可少的，这里的模块包括了控制器内部的实现逻辑，比如：拓扑管理、链路计算等，也包括一些底层的网络实现逻辑，比如BGP Vxlan的实现等 内置应用层提供了基础的功能包，如L2、L3网络，Overlay APP，服务链APP等 北向接口层中，控制器实现了Restful API的接口或者嵌入式的API提供给上层应用调用 配置管理层提供了控制器服务管理，集群管理和图形化界面，如ODL控制器提供了模块的启用、删除等功能，Floodlight等控制器提供了一个简单易用的UI界面，可以在web界面中调用控制器的北向API对控制器进行配置 二：控制器关键技术 主要是包括南向网络控制和北向业务支撑 （一）南向网络技术 通过南向接口协议进行链路发现、拓扑管理、策略制定、表项下发等：

hlpp（欢乐婆婆）算法总结 突然发现咕了好久（X） 　　emm先大概说一下，hlpp是针对网络流算法的一种复杂度更优的算法，基于预流推进（即模拟） 复杂度上界为 n 2 根号m 且跑不满 （所以学会了它，可以解决绝大部分dinic能解决的问题，以及绝大部分dinic不能解决的问题 先把以前的dinic算法放一下吧 你谷P3376 网络最大流模板 #include<bits/stdc++.h> #define re register using namespace std; const int maxxx=(1ll<<31)-1; inline int read() { register int x=0,f=1; char ch=getchar(); while(ch<'0'||ch>'9') {if(ch=='-') f=-1; ch=getchar();} while(ch>='0'&&ch<='9') {x=x*10+ch-'0'; ch=getchar();} return x*f; } struct node { int to,nxt,dis; }e[210000]; int head[100010],cur[100010],cnt=-1; void add(int u,int v,int w) { e[++cnt].to=v; e[cnt].dis=w; e[cnt]

使用SpringWebFlow 本章主要内容： · 创建会话式的Web应用程序 · 定义流程状态和行为 Spring Web Flow 是Spring MVC 的扩展，它支持开发基于流程的应用程序。它将流程的定义与实现流程行为的类和视图分离开来。 1 在Spring中配置Web Flow Spring Web Flow是构建于Spring MVC基础之上的。这意味着所有的流程请求都需要首先经过Spring MVC的DispatcherServlet。我们需要在Spring应用上下文中配置一些bean来处理流程请求并执行流程。现在，还不支持在Java中配置Spring Web Flow，所以我们需要在XML中对其进行配置。有一些bean会使用Spring Web Flow的Spring配置文件命名空间来进行声明。因此需要在上下文定义XML文件中添加这个命名空间声明： <?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:folw="http://www.springframework.org/schema/webflow

目录 Git相关 基本概念 常见客户端 TortoiseGit Sourcetree Intellij Idea 命令行 常用命令 存储区域 命令之 add & commit &push 命令之 branch & checkout 命令之 cherry-pick 命令之 merge & rebase Flow相关 GitFlow GitHub Flow GitLab Flow ExeFlow 总结 本文会分为两部分讲解，第一部分介绍Git的基础概念、常见客户端、常用命令，是一个基础说明。第二部分介绍Git的管理流程，主要是GitFlow，Github Flow、Gitlab Flow和ExeFlow四种。 Git相关 基本概念 Git是一个基于GNU协议的开源分布式版本控制系统，是由Linux的创始人Linus Torvalds在2005为了进行Linux内核的研发时自己编写的。不同于之前的大部分客户端-服务器模式的代码管理系统，在每台电脑上的每个Git目录都是一个完整的代码仓库，包含了历史所有的提交记录并且可以完整查看所有版本，而不需要有服务器或者网络连接。 2019年9月Git的当前的最新版本为2.23.0. 常见客户端 TortoiseGit TortoiseGit，就是我们俗称小乌龟。他们为Svn也提供了很优秀的windows客户端。而且这是一个开源的软件

题目描述 这是在阿尔托利亚·潘德拉贡成为英灵前的事情，她正要去拔出石中剑成为亚瑟王，在这之前她要去收集一些宝石。 宝石排列在一个n*m的网格中，每个网格中有一块价值为v(i,j)的宝石，阿尔托利亚·潘德拉贡可以选择自己的起点。 开始时刻为0秒。以下操作，每秒按顺序执行 在第i秒开始的时候，阿尔托利亚·潘德拉贡在方格（x,y）上，她可以拿走（x，y）中的宝石。 在偶数秒，阿尔托利亚·潘德拉贡周围四格的宝石会消失 若阿尔托利亚·潘德拉贡第i秒开始时在方格（x，y）上，则在第i+1秒可以立即移动到（x+1，y），（x，y+1），（x-1，y）或（x，y-1）上，也可以停留在（x,y)上。 求阿尔托利亚·潘德拉贡最多可以获得多少价值的宝石 输入格式 第一行给出数字N,M代表行列数.N,M均小于等于100，宝石的价值不会超过10000.下面N行M列用于描述数字矩阵 输出格式 输出最多可以拿到多少价值宝石 输入输出样例 输入 #1 2 2 1 2 2 1 输出 #1 4 说明/提示 姚金宇的原创题。 代码： include<iostream> #include<cstdio> #include<cstring> #include<algorithm> #include<queue> #define R register #define inf 1e9+7 using namespace std

昨天写了网络流的 EK 算法（ 写得我自己都不太懂 ），今天再来总结一下另一个网络最大流的算法 Dinic 。 先来介绍一个概念：残量网络。 一个网络中所有剩余容量大于0的边和与这些边相连的节点组成这个网络的残量网络。 我们回忆一下EK算法的过程： 1.在网络中寻找一条剩余容量大于0的边，把它加入到增广路中。 2.依据找到的增广路，更新边的剩余容量和最大流。 所以，我们每次对增广路的搜索，都可能需要对整个残量网络进行遍历，而只找到一条增广路，还可以进一步优化。 在这里，我们提出了节点的层次d[x]，它表示从s到x最少需要经过的边数。在残量网络中，满足d[y] = d[x] + 1的所有边(x , y)构成的子图被称为 分层图 。显然，它是一张有向无环图。 而传说中的 Dinic 算法就是通过以下两个步骤来求最大流： 1.在残量网络中不断通过BFS构造分层图，直到s不能到达t。 2.在分层图上用DFS求增广路，在回溯时更新剩余容量。 好啦，大体的介绍完了，具体是怎么回事呢？？（ 其实我也不太懂 ） 在BFS时，我们每找到一个节点x，它到s的最少边数d[x]一定已经求得，那么所有以x为起点的边(x , y)（剩余容量大于0）都可以成为分层图中的子图，于是我们把所有与x相连的节点y的d[y]（它还没有被赋值）都更新为d[y] = d[x] + 1,因为只需要多走一条边就可以到y了。这样

如果你是个在厂里搞开发的，并且曾有过如下的遭遇： (1) 你被要求马上发布版本，现实却是当前开发的某功能做了一半，现在做不完也毙不干净； (2) 你开发的下一个版本的功能已经做完了，但你们车间的两个工友在做当前版本发布，于是你老没法提交代码，最后憋到内伤； (3) 车间里正happy地开发新版本，突然厂里来了指示，要求在已发布版本基础上做一个小改动。 结果你们痛苦地切分支改代码测试发版本，结果指示是执行了，这个改动却忘了合并到主线上。 (4) 各种其他…… 那么，建议你试下Git Flow；当然，如果你们车间用的是SVN啥啥的，先看看Git吧。 以下介绍的是经过我“微创新”之后的Git Flow版本，修改了原版的一些BUG，某些细节上也有些差异。我做的改动具体可以看我前面的几篇博客。 http://www.jiangyouxin.net/2013/02/12/git_flow_1.html http://www.jiangyouxin.net/2013/02/13/git_flow_2.html http://www.jiangyouxin.net/2013/02/14/git_flow_3.html 获取代码： git clone https://github.com/JiangYouxin/ gitflow.git cd gitflow git checkout t