历经两个晚上的奋斗，终于把这个题目AC了- -回过头来看看其实真的不难……状态十分悲剧啊……但愿成都不要悲剧……
http://acm.zju.edu.cn/onlinejudge/showProblem.do?problemCode=3229
题目的意思挺简单的，一个人要在n天里面给m个MM拍照，每天有一个最大的照片数量以及若干MM能够拍的上下界，还有每个MM最终需要的照片总数，问有没有可行方案，有的话输出总照片数最大的任意一种方案
赤裸裸的上下界最大流
昨天晚上找来这题主要是想要充实一下模版，专门找的一个上下界最大流的题目来做的
一开始用了很朴素的dfs找增广路的办法……毫无悬念的TLE……改bfs，继续TLE……当时就不知道怎么办了……话说当时我还不知道SAP这种东西……发现很迟了，于是睡觉，睡前手机百度了一下，朴素的找增广路效率那叫一个低……
第二天百度了挺久，发现SAP属于编程复杂度很低，效率很高的典范- -于是就写SAP，先拿了一个普通的最大流测试，算法是对的，时间嘛- -题目太弱了，dfs都是0ms……
于是开始改ZOJ3329的程序，改啊改的……本地样例过了，提交，WA……
于是开始死命地改……怎么改怎么WA……做了N多无用功，不过也算是有一些收获，比如找到了一个之前算法的bug，改掉之后速度从800ms一下子降到200ms……
终于再几个小时无用功之后突然想到自己出数据……靠……想到这么个破东西……
于是拿样例稍微改了一下……改着改着……发现一个答案错误的数据！！！！！
马上根据数据结果看了一下程序……突然发现init里面一个上下界写反了……泪奔……
我记得我反复检查init至少3遍啊……
最终总算是AC了，速度很快，排在AC列表的第一位！SAP果然暴力！！
总结一下收获吧- -
1.本身这两天都是在有点疲劳的时候做题目，所以很多低级错误，所以休息好很重要
2.SAP真的很暴力……
3.死命WA的时候适度的静态查错是可以的，但是改代码必须建立在确实发现了错误，而不是瞎改
4.死命WA的时候可以试着自己出数据，或者对样例数据进行一些小改动。由于样例数据一般都很小，所以小的量变就很容易导致发现错误，很有可能会有收获的，而不是死盯着那几个样例不放
5.最后我把一开始WA的程序除了init什么都不改，提交，1150MS，AC，速度比最终AC的程序慢了很多，这也算是一个收获了吧……