May
27
May
25
很纠结地最后可以参加这个比赛了，但是这个比赛只能两个人参加，于是BFS只能拆散了。
Sandy和Boluor组队，然后我另外去找了Eire组成新队，队名70km :D
12点左右就到了机房，结果LCY说对外通知是12:30入场>_<|| 郁闷。
然后随便找一台机器测试了一会儿，到大约12点40的时候被安排坐到team30的位置(可是我们是team51=.=)
花了一点时间把vimrc先大致敲了一点进去，和eire讲了一点vim的基本操作，敲了一个model.cpp
1点多一点点开始比赛，8道题目，可是国软这次这么小气，两个人才一份题目，orz。
于是把题目拆开，Felix负责ABCD，Eire负责EFGH。
还好是中文，看完比较快，Eire说后面四道题目貌似没有直接可以写的
然后我看到B是一个简单的BFS，C是一个更简单的模拟水题
于是直接上去敲C，结果很快就WA了，检查了一下，发现一个小错误，Submit，又WA，超郁闷。
打印代码一边检查，然后Eire看H题，我和他讨论了一下，刚开始想到记忆化搜索
但是发现不对，没有高精肯定要溢出，高精效率又太低。
于是列出一个不太严谨的式子：如果把n拆成x份，那么最后的结果是x^(n/x)（忽略小数）
然后大致证明了3是最划算的（我居然忘了怎么求导T_T 还好Eire还记得。。。）
然后又大致觉得如果是4就应该拆成2 * 2
于是顺着这个不严格证明得出的思路写代码。
其间Felix改了一下C题，又WA，检查代码发现多了一个测试的printf T_T，注释，提交，AC@35min
一个简单的C题被我搞出3个WA。。。罪人啊。。。。
很快Eire根据那个"证明"结果写出了代码，提交，1AC@42。振奋。
然后Felix看B题的BFS应该很简单，虽然Eire有点担心，但是还是毅然决然地开题
写完以后测试发现不太对，打印代码一边晾去，由Eire开始写他想得已经差不多的G题
其间Eire又转去细想，而Felix在打印的代码上面发现了几处错误
改正以后样例基本OK了，然后是最后一个不对
自己看了一下样例，发现是样例错了，于是问judge。
结果被告知出题人kid正在地大回途中，waiting。。。
于是Eire继续G题，由于roman 2 arabic的函数写得很好，然后用一个struct+stable_sort，1AC@114min
这个时候开始网络变得非常垃圾，点一个Refresh就能把PC^2卡死，超郁闷。
还好等了不是太久kid回来了，原来是他把6写成5了，不好改题目，于是就把数据改了。
然后提交之，发现TLE了，超囧。
检查了一下，发现在BFS的循环里面有错，队尾指针在某个情况下不会改变(以前没遇到过)，于是很囧地进入死循环TLE
修改了以后检查了一遍，又发现一些其他的错误，一并改之，提交，WA@130+min T_T
很郁闷很郁闷地继续检查，大概160min发现原来是存名字的map在每一个case之前没有clear，超囧。
又提交一次，还是WA！郁闷啊郁闷啊郁闷。
纠结了很久，大概30min以后问了maner是不是最后一个case后面不需要再加\n
maner说，大概是。。。于是改之，提交，终于AC@196min...
剩下的四道题目和Eire讨论了一下：
A题是一个枚举+二维DP的问题，Felix能想出这个框架，但是实在是不会写DP，无奈放弃
D题状似计算几何，但是细看其实不然。Felix也想出了应用容斥原理的算法基本框架，就是不会写T_T
E题可见边——Eire很后悔地说没有带上图形学的书。。。
F题奇怪的比赛——完全没有思路，嗯。
此时70km@Rank2，仅次于momo+feli。
但是后面好几个队伍都出了3题甚至4题，估计很快就能超过我们，郁闷
更郁闷的是LCY同志宣布：由于比赛过程中网络状况比较差，比赛延长半个小时
于是我深情地拉着LCY的手说：我恨你T_T
由于最后一个半小时都没有题目可以做，于是Eire在5点多一些就先跑路了
Felix非常无聊地水了一下D题，毫无意外地TLE，于是也不再继续写了。。。。
——
最后非常意外地70km还是留在Rank2的位置。究其原因，主要有这么几点：
首先，因为从地大回来的队伍不仅推迟一个小时才开始做题，而且都太累了——毕竟写了一天的代码啊，此乃侥幸。
其次，做题策略把握得比较好——
a) 看题，我们把所有的题目都快速扫过去，没有一看到简单的就急于做出来，
因此在整个比赛的过程中基本上是按照从简单到难的顺序做出来，这个还是比较划算的
b) 比赛的过程中时间安排得好。一旦觉得自己会陷入僵局的时候就打印代码换人写
事实上确实是，在纸上看代码很容易找到代码的错误，并且往往一次能找出不止个一并改好
c) 把自己的想法适当地和队友讨论，这样能让自己明确自己的思路，找到自己可能存在的问题，
同时如果自己存在问题，也可以借助队友的局外人身份找出（旁观者清啊！）
再次，河蟹的队伍气氛也很重要。整个比赛过程中非常开心，无论是卡题还是AC还是WA还是TLE（其实后两个结果都是Felix的贡献T_T），都可以笑得很happy，一点沉重的气氛都没有，我觉得这对队伍比赛时的状态有非常积极的作用，让我想起的去年暑假集训的Matrix76队，气氛一向都是非常河蟹。
此外，发现自己的基础还有很大一部分不扎实，主要体现在：
1. 简单的DP不会写.....
2. 容斥原理不会写.....
3. 算法流程没有完全想清楚就开始码字.....
4. 一个BFS能写出好几个错误，边写编改.....
5. 居然能挂在初始化上面，无语啊无语啊无语。。。
以上，OVER，特别感谢队友Eire同学，嗯。
Sandy和Boluor组队，然后我另外去找了Eire组成新队，队名70km :D
12点左右就到了机房，结果LCY说对外通知是12:30入场>_<|| 郁闷。
然后随便找一台机器测试了一会儿，到大约12点40的时候被安排坐到team30的位置(可是我们是team51=.=)
花了一点时间把vimrc先大致敲了一点进去，和eire讲了一点vim的基本操作，敲了一个model.cpp
1点多一点点开始比赛，8道题目，可是国软这次这么小气，两个人才一份题目，orz。
于是把题目拆开，Felix负责ABCD，Eire负责EFGH。
还好是中文，看完比较快，Eire说后面四道题目貌似没有直接可以写的
然后我看到B是一个简单的BFS，C是一个更简单的模拟水题
于是直接上去敲C，结果很快就WA了，检查了一下，发现一个小错误，Submit，又WA，超郁闷。
打印代码一边检查，然后Eire看H题，我和他讨论了一下，刚开始想到记忆化搜索
但是发现不对，没有高精肯定要溢出，高精效率又太低。
于是列出一个不太严谨的式子：如果把n拆成x份，那么最后的结果是x^(n/x)（忽略小数）
然后大致证明了3是最划算的（我居然忘了怎么求导T_T 还好Eire还记得。。。）
然后又大致觉得如果是4就应该拆成2 * 2
于是顺着这个不严格证明得出的思路写代码。
其间Felix改了一下C题，又WA，检查代码发现多了一个测试的printf T_T，注释，提交，AC@35min
一个简单的C题被我搞出3个WA。。。罪人啊。。。。
很快Eire根据那个"证明"结果写出了代码，提交，1AC@42。振奋。
然后Felix看B题的BFS应该很简单，虽然Eire有点担心，但是还是毅然决然地开题
写完以后测试发现不太对，打印代码一边晾去，由Eire开始写他想得已经差不多的G题
其间Eire又转去细想，而Felix在打印的代码上面发现了几处错误
改正以后样例基本OK了，然后是最后一个不对
自己看了一下样例，发现是样例错了，于是问judge。
结果被告知出题人kid正在地大回途中，waiting。。。
于是Eire继续G题，由于roman 2 arabic的函数写得很好，然后用一个struct+stable_sort，1AC@114min
这个时候开始网络变得非常垃圾，点一个Refresh就能把PC^2卡死，超郁闷。
还好等了不是太久kid回来了，原来是他把6写成5了，不好改题目，于是就把数据改了。
然后提交之，发现TLE了，超囧。
检查了一下，发现在BFS的循环里面有错，队尾指针在某个情况下不会改变(以前没遇到过)，于是很囧地进入死循环TLE
修改了以后检查了一遍，又发现一些其他的错误，一并改之，提交，WA@130+min T_T
很郁闷很郁闷地继续检查，大概160min发现原来是存名字的map在每一个case之前没有clear，超囧。
又提交一次，还是WA！郁闷啊郁闷啊郁闷。
纠结了很久，大概30min以后问了maner是不是最后一个case后面不需要再加\n
maner说，大概是。。。于是改之，提交，终于AC@196min...
剩下的四道题目和Eire讨论了一下：
A题是一个枚举+二维DP的问题，Felix能想出这个框架，但是实在是不会写DP，无奈放弃
D题状似计算几何，但是细看其实不然。Felix也想出了应用容斥原理的算法基本框架，就是不会写T_T
E题可见边——Eire很后悔地说没有带上图形学的书。。。
F题奇怪的比赛——完全没有思路，嗯。
此时70km@Rank2，仅次于momo+feli。
但是后面好几个队伍都出了3题甚至4题，估计很快就能超过我们，郁闷
更郁闷的是LCY同志宣布：由于比赛过程中网络状况比较差，比赛延长半个小时
于是我深情地拉着LCY的手说：我恨你T_T
由于最后一个半小时都没有题目可以做，于是Eire在5点多一些就先跑路了
Felix非常无聊地水了一下D题，毫无意外地TLE，于是也不再继续写了。。。。
——
最后非常意外地70km还是留在Rank2的位置。究其原因，主要有这么几点：
首先，因为从地大回来的队伍不仅推迟一个小时才开始做题，而且都太累了——毕竟写了一天的代码啊，此乃侥幸。
其次，做题策略把握得比较好——
a) 看题，我们把所有的题目都快速扫过去，没有一看到简单的就急于做出来，
因此在整个比赛的过程中基本上是按照从简单到难的顺序做出来，这个还是比较划算的
b) 比赛的过程中时间安排得好。一旦觉得自己会陷入僵局的时候就打印代码换人写
事实上确实是，在纸上看代码很容易找到代码的错误，并且往往一次能找出不止个一并改好
c) 把自己的想法适当地和队友讨论，这样能让自己明确自己的思路，找到自己可能存在的问题，
同时如果自己存在问题，也可以借助队友的局外人身份找出（旁观者清啊！）
再次，河蟹的队伍气氛也很重要。整个比赛过程中非常开心，无论是卡题还是AC还是WA还是TLE（其实后两个结果都是Felix的贡献T_T），都可以笑得很happy，一点沉重的气氛都没有，我觉得这对队伍比赛时的状态有非常积极的作用，让我想起的去年暑假集训的Matrix76队，气氛一向都是非常河蟹。
此外，发现自己的基础还有很大一部分不扎实，主要体现在：
1. 简单的DP不会写.....
2. 容斥原理不会写.....
3. 算法流程没有完全想清楚就开始码字.....
4. 一个BFS能写出好几个错误，边写编改.....
5. 居然能挂在初始化上面，无语啊无语啊无语。。。
以上，OVER，特别感谢队友Eire同学，嗯。
May
20
本文包含一个很挫的算法和一个很赞的算法
-----------------------
24点是一个足够古老的游戏了：
给出四个一位数（可能重复），使用加减乘除和括号将这四个数字整合成一个算式，使得算式的结果等于24。
当然，不是所有的四个一位数都可以组合成24的，比如1,1,1,1显然就不能。
有两个经典的组合是 1, 5, 5, 5 和 3, 3, 8, 8 —— 你可以找出有效解吗？
对于任意给出的四个一位数，如果不考虑重复的情况（比如1，5，5，5，把三个5当成不同的数字）
那么可以算出，可能的算式有 (4*3*2*1) * (1*2+1*1+2*1) * (4 * 4 * 4) = 7680种。
这么大的数字用人脑去算是很不合理的，所以应该写一个程序来处理，嗯。
（中间的 1 * 2 + 1 * 1 + 2 * 1是什么？——下面再说）
这个程序的实现我大一的时候曾经想过，但是那时候对语言掌握都很差，更别说写出具体的回溯等算法来实现。
昨天又想到这个问题，于是拖了这么久，终于在今天把代码写出来了（一题两年出，一跑就郁闷）。
-----------------------
24点是一个足够古老的游戏了：
给出四个一位数（可能重复），使用加减乘除和括号将这四个数字整合成一个算式，使得算式的结果等于24。
当然，不是所有的四个一位数都可以组合成24的，比如1,1,1,1显然就不能。
有两个经典的组合是 1, 5, 5, 5 和 3, 3, 8, 8 —— 你可以找出有效解吗？
对于任意给出的四个一位数，如果不考虑重复的情况（比如1，5，5，5，把三个5当成不同的数字）
那么可以算出，可能的算式有 (4*3*2*1) * (1*2+1*1+2*1) * (4 * 4 * 4) = 7680种。
这么大的数字用人脑去算是很不合理的，所以应该写一个程序来处理，嗯。
（中间的 1 * 2 + 1 * 1 + 2 * 1是什么？——下面再说）
这个程序的实现我大一的时候曾经想过，但是那时候对语言掌握都很差，更别说写出具体的回溯等算法来实现。
昨天又想到这个问题，于是拖了这么久，终于在今天把代码写出来了（一题两年出，一跑就郁闷）。
May
18
网上可以搜到很多相关的资料，这里不具体说了，
大致就是，定义struct/class的时候 编译器会把其中的每个成员的存储位置对齐
对齐原则一般是和该成员大小一致，比如int的就从%4=0的地址开始存储，多余的空间就编译器随便填充了。
然后struct还要填充，直到整个struct的大小是最大成员大小的倍数（VC6.0）——为什么呢？
Felix觉得这样是为了保证连续存储的时候下一个struct的最大成员也是对齐的。
此外，编译器还会对struct的存储地址进行对齐。
我实际测试了一下，我发现32bit的gcc在对struct进行填充的时候
如果某成员的大小大于4Bytes(long long, double)的时候，实际上是以4字节对齐的。
如果在程序中指定了
#pragma pack(n)
那么对齐的时候就会把元素的大小和n进行比较，取较小的那个来对齐。
此外：
#pragma pack(push)
#program pack(pop)
可以成对使用，用来保存(push)当前的n和取出(pop)之前的n——当然，这是在编译过程中处理的。
下面是我的一段测试程序：
大致就是，定义struct/class的时候 编译器会把其中的每个成员的存储位置对齐
对齐原则一般是和该成员大小一致，比如int的就从%4=0的地址开始存储，多余的空间就编译器随便填充了。
然后struct还要填充，直到整个struct的大小是最大成员大小的倍数（VC6.0）——为什么呢？
Felix觉得这样是为了保证连续存储的时候下一个struct的最大成员也是对齐的。
此外，编译器还会对struct的存储地址进行对齐。
我实际测试了一下，我发现32bit的gcc在对struct进行填充的时候
如果某成员的大小大于4Bytes(long long, double)的时候，实际上是以4字节对齐的。
如果在程序中指定了
#pragma pack(n)
那么对齐的时候就会把元素的大小和n进行比较，取较小的那个来对齐。
此外：
#pragma pack(push)
#program pack(pop)
可以成对使用，用来保存(push)当前的n和取出(pop)之前的n——当然，这是在编译过程中处理的。
下面是我的一段测试程序：
May
16
早上参加了腾讯的笔试，做完以后自我感觉良好，但是后来和sandy讨论了一下，发现还是挫了，因为没用上Hash。
于是中午回去狠查了一些资料，看到了一点东西，充实了些。
下载文件 (已下载 1663 次)
看到一些字符串的Hash函数，想测试一下它们的实际性能
于是写了个程序来生成5w个字符串
用不同的hash函数计算hash值模9793（随便写的一个数字）
然后再用 sort 和 uniq 看了一下结果，发现 sdbmhash 是最好的, jshash其次，也很不错
然而很意外的是 elfhash 的性能则相当差，完全达不到可用的标准
——在对5w个数进行hash以后得到的结果里面，居然有700多个0和400多个1。
下面贴一些代码：
gen_data.cpp
hash.cpp
查看结果：
于是中午回去狠查了一些资料，看到了一点东西，充实了些。
下载文件 (已下载 1663 次)看到一些字符串的Hash函数，想测试一下它们的实际性能
于是写了个程序来生成5w个字符串
用不同的hash函数计算hash值模9793（随便写的一个数字）
然后再用 sort 和 uniq 看了一下结果，发现 sdbmhash 是最好的, jshash其次，也很不错
然而很意外的是 elfhash 的性能则相当差，完全达不到可用的标准
——在对5w个数进行hash以后得到的结果里面，居然有700多个0和400多个1。
下面贴一些代码：
gen_data.cpp
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
char tbl[] = "0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ!@#$%^&*()_+=-?><:';,./][{}\\\"";
int main(){
char s[1024];
int i, l, m = strlen(tbl), j;
srand(732984);
freopen("str.txt", "w", stdout);
for (i = 0; i < 50000; ++i){
l = rand() % 100 + 1;
for (j = 0; j < l; ++j)
s[j] = tbl[rand() % m];
s[j] = 0;
printf("%s\n", s);
}
return 0;
}
#include <stdlib.h>
#include <string.h>
char tbl[] = "0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ!@#$%^&*()_+=-?><:';,./][{}\\\"";
int main(){
char s[1024];
int i, l, m = strlen(tbl), j;
srand(732984);
freopen("str.txt", "w", stdout);
for (i = 0; i < 50000; ++i){
l = rand() % 100 + 1;
for (j = 0; j < l; ++j)
s[j] = tbl[rand() % m];
s[j] = 0;
printf("%s\n", s);
}
return 0;
}
hash.cpp
#include <iostream>
#include <cstdlib>
#include <cstring>
using namespace std;
unsigned int elfhash(char *s){
int hash = 0, x = 0;
while (*s){
hash = (hash << 4) + (*s++);
if(((x = hash) & 0xf0000000l) != 0){
hash ^= (x >> 24);
hash &= x;
}
}
return hash & 0x7fffffffl;
}
unsigned int jshash(char *s){
int hash = 1315423911;
while (*s){
hash ^= (hash << 5) + *s++ + (hash >> 2);
}
return (hash & 0x7fffffffl);
}
unsigned int sdbmhash(char *s){
int hash = 0;
while (*s){
hash = (hash << 6) + (hash << 16) - hash + *s++;
}
return (hash & 0x7fffffffl);
}
int main(){
char s[1024];
freopen("str.txt", "r", stdin);
freopen("elf1.txt", "w", stdout);
while(true){
scanf("%s", s);
if(feof(stdin)) break;
printf("%d\n", elfhash(s) % 9793);
}
return 0;
}
#include <cstdlib>
#include <cstring>
using namespace std;
unsigned int elfhash(char *s){
int hash = 0, x = 0;
while (*s){
hash = (hash << 4) + (*s++);
if(((x = hash) & 0xf0000000l) != 0){
hash ^= (x >> 24);
hash &= x;
}
}
return hash & 0x7fffffffl;
}
unsigned int jshash(char *s){
int hash = 1315423911;
while (*s){
hash ^= (hash << 5) + *s++ + (hash >> 2);
}
return (hash & 0x7fffffffl);
}
unsigned int sdbmhash(char *s){
int hash = 0;
while (*s){
hash = (hash << 6) + (hash << 16) - hash + *s++;
}
return (hash & 0x7fffffffl);
}
int main(){
char s[1024];
freopen("str.txt", "r", stdin);
freopen("elf1.txt", "w", stdout);
while(true){
scanf("%s", s);
if(feof(stdin)) break;
printf("%d\n", elfhash(s) % 9793);
}
return 0;
}
查看结果：
引用
$ sort elf1.txt | less
$ sort elf1.txt | uniq | less
$ sort elf1.txt | uniq | less
May
13
今天回顾WOJ1398，发现了这个当时没有理解透彻的算法。
看了好久好久，现在终于想明白了。
试着把它写下来，让自己更明白。
最长递增子序列，Longest Increasing Subsequence 下面我们简记为 LIS。
排序+LCS算法 以及 DP算法就忽略了，这两个太容易理解了。
假设存在一个序列d[1..9] = 2 1 5 3 6 4 8 9 7，可以看出来它的LIS长度为5。
下面一步一步试着找出它。
我们定义一个序列B，然后令 i = 1 to 9 逐个考察这个序列。
此外，我们用一个变量Len来记录现在最长算到多少了
首先，把d[1]有序地放到B里，令B[1] = 2，就是说当只有1一个数字2的时候，长度为1的LIS的最小末尾是2。这时Len=1
然后，把d[2]有序地放到B里，令B[1] = 1，就是说长度为1的LIS的最小末尾是1，d[1]=2已经没用了，很容易理解吧。这时Len=1
接着，d[3] = 5，d[3]>B[1]，所以令B[1+1]=B[2]=d[3]=5，就是说长度为2的LIS的最小末尾是5，很容易理解吧。这时候B[1..2] = 1, 5，Len＝2
再来，d[4] = 3，它正好加在1,5之间，放在1的位置显然不合适，因为1小于3，长度为1的LIS最小末尾应该是1，这样很容易推知，长度为2的LIS最小末尾是3，于是可以把5淘汰掉，这时候B[1..2] = 1, 3，Len = 2
继续，d[5] = 6，它在3后面，因为B[2] = 3, 而6在3后面，于是很容易可以推知B[3] = 6, 这时B[1..3] = 1, 3, 6，还是很容易理解吧？ Len = 3 了噢。
第6个, d[6] = 4，你看它在3和6之间，于是我们就可以把6替换掉，得到B[3] = 4。B[1..3] = 1, 3, 4， Len继续等于3
第7个, d[7] = 8，它很大，比4大，嗯。于是B[4] = 8。Len变成4了
第8个, d[8] = 9，得到B[5] = 9，嗯。Len继续增大，到5了。
最后一个, d[9] = 7，它在B[3] = 4和B[4] = 8之间，所以我们知道，最新的B[4] =7，B[1..5] = 1, 3, 4, 7, 9，Len = 5。
于是我们知道了LIS的长度为5。
!!!!! 注意。这个1,3,4,7,9不是LIS，它只是存储的对应长度LIS的最小末尾。有了这个末尾，我们就可以一个一个地插入数据。虽然最后一个d[9] = 7更新进去对于这组数据没有什么意义，但是如果后面再出现两个数字 8 和 9，那么就可以把8更新到d[5], 9更新到d[6]，得出LIS的长度为6。
然后应该发现一件事情了：在B中插入数据是有序的，而且是进行替换而不需要挪动——也就是说，我们可以使用二分查找，将每一个数字的插入时间优化到O(logN)~~~~~于是算法的时间复杂度就降低到了O(NlogN)～！
代码如下:
update @ 2016-08-21
没想到7年多了还要更新一下……
有几位同学在评论中问到如何给出一个LIS而不仅是计算长度。具体的代码我没有写过，不过大概可以这么实现：更新B[i]的时候，把记下来数字在原来数组中的下标也记下来（被替换的数据保留在一个后备数组中）。等到得出 B[n] 了以后，用贪心算法往前回溯，每次找出B[i-1]对应后备数组中值小于B[i]、下标小于B[i]下标、且在该后备数组中下标最大的那个。
update @ 2017-04-16
补充一下，由于上面那段代码用的是upper_bound，所以实际上求的是最长不下降子序列；如果要求递增子序列，应该改用lower_bound。
看了好久好久，现在终于想明白了。
试着把它写下来，让自己更明白。
最长递增子序列，Longest Increasing Subsequence 下面我们简记为 LIS。
排序+LCS算法 以及 DP算法就忽略了，这两个太容易理解了。
假设存在一个序列d[1..9] = 2 1 5 3 6 4 8 9 7，可以看出来它的LIS长度为5。
下面一步一步试着找出它。
我们定义一个序列B，然后令 i = 1 to 9 逐个考察这个序列。
此外，我们用一个变量Len来记录现在最长算到多少了
首先，把d[1]有序地放到B里，令B[1] = 2，就是说当只有1一个数字2的时候，长度为1的LIS的最小末尾是2。这时Len=1
然后，把d[2]有序地放到B里，令B[1] = 1，就是说长度为1的LIS的最小末尾是1，d[1]=2已经没用了，很容易理解吧。这时Len=1
接着，d[3] = 5，d[3]>B[1]，所以令B[1+1]=B[2]=d[3]=5，就是说长度为2的LIS的最小末尾是5，很容易理解吧。这时候B[1..2] = 1, 5，Len＝2
再来，d[4] = 3，它正好加在1,5之间，放在1的位置显然不合适，因为1小于3，长度为1的LIS最小末尾应该是1，这样很容易推知，长度为2的LIS最小末尾是3，于是可以把5淘汰掉，这时候B[1..2] = 1, 3，Len = 2
继续，d[5] = 6，它在3后面，因为B[2] = 3, 而6在3后面，于是很容易可以推知B[3] = 6, 这时B[1..3] = 1, 3, 6，还是很容易理解吧？ Len = 3 了噢。
第6个, d[6] = 4，你看它在3和6之间，于是我们就可以把6替换掉，得到B[3] = 4。B[1..3] = 1, 3, 4， Len继续等于3
第7个, d[7] = 8，它很大，比4大，嗯。于是B[4] = 8。Len变成4了
第8个, d[8] = 9，得到B[5] = 9，嗯。Len继续增大，到5了。
最后一个, d[9] = 7，它在B[3] = 4和B[4] = 8之间，所以我们知道，最新的B[4] =7，B[1..5] = 1, 3, 4, 7, 9，Len = 5。
于是我们知道了LIS的长度为5。
!!!!! 注意。这个1,3,4,7,9不是LIS，它只是存储的对应长度LIS的最小末尾。有了这个末尾，我们就可以一个一个地插入数据。虽然最后一个d[9] = 7更新进去对于这组数据没有什么意义，但是如果后面再出现两个数字 8 和 9，那么就可以把8更新到d[5], 9更新到d[6]，得出LIS的长度为6。
然后应该发现一件事情了：在B中插入数据是有序的，而且是进行替换而不需要挪动——也就是说，我们可以使用二分查找，将每一个数字的插入时间优化到O(logN)~~~~~于是算法的时间复杂度就降低到了O(NlogN)～！
代码如下:
//在非递减序列 arr[s..e]（闭区间）上二分查找第一个大于等于key的位置，如果都小于key，就返回e+1
int upper_bound(int arr[], int s, int e, int key)
{
int mid;
if (arr[e] <= key)
return e + 1;
while (s < e)
{
mid = s + (e - s) / 2;
if (arr[mid] <= key)
s = mid + 1;
else
e = mid;
}
return s;
}
int LIS(int d[], int n)
{
int i = 0, len = 1, *end = (int *)alloca(sizeof(int) * (n + 1));
end[1] = d[0]; //初始化：长度为1的LIS末尾为d[0]
for (i = 1; i < n; i++)
{
int pos = upper_bound(end, 1, len, d[i]); //找到插入位置
end[pos] = d[i];
if (len < pos) //按需要更新LIS长度
len = pos;
}
return len;
}
int upper_bound(int arr[], int s, int e, int key)
{
int mid;
if (arr[e] <= key)
return e + 1;
while (s < e)
{
mid = s + (e - s) / 2;
if (arr[mid] <= key)
s = mid + 1;
else
e = mid;
}
return s;
}
int LIS(int d[], int n)
{
int i = 0, len = 1, *end = (int *)alloca(sizeof(int) * (n + 1));
end[1] = d[0]; //初始化：长度为1的LIS末尾为d[0]
for (i = 1; i < n; i++)
{
int pos = upper_bound(end, 1, len, d[i]); //找到插入位置
end[pos] = d[i];
if (len < pos) //按需要更新LIS长度
len = pos;
}
return len;
}
update @ 2016-08-21
没想到7年多了还要更新一下……
有几位同学在评论中问到如何给出一个LIS而不仅是计算长度。具体的代码我没有写过，不过大概可以这么实现：更新B[i]的时候，把记下来数字在原来数组中的下标也记下来（被替换的数据保留在一个后备数组中）。等到得出 B[n] 了以后，用贪心算法往前回溯，每次找出B[i-1]对应后备数组中值小于B[i]、下标小于B[i]下标、且在该后备数组中下标最大的那个。
update @ 2017-04-16
补充一下，由于上面那段代码用的是upper_bound，所以实际上求的是最长不下降子序列；如果要求递增子序列，应该改用lower_bound。
May
11
今天不太想做其他事情，所以就跟着acm集训队做了两场在toj上面的个人选拔赛。
早上的那一场做得比较随便，跟师兄聊着聊着就聊过头了，等聊完都过了十几min了。于是没有看statistics，挑了个逆序数的题目做，数据比较大，所以用归并，但是居然WA了。到WOJ的1046去测试了一下，是AC的啊，郁闷。于是去看Ranklist，发现另外一道简单题大部分人都过了，于是去写，很快1AC。然后回到那题，发现它对付超大数据有问题，于是改成long long，AC。然后又看到最后一个简单的题目，大约花了10min（说明我代码速度还是不行啊），1AC。虽然这个时候罚时比较多了，但是出3题的人不多，所以rank还比较靠前。剩下的时间在对付那个概率论的题目。显然[30][30][1000]的数据硬搞是要TLE的，不过对于我这种DPSB而言，还是老老实实先写一个出来再说。看题目就花了不少时间，然后写了个爆搜，算出了题目test case，但是提交上去就MLE了。然后想试试打表，但是在自己机器上都算不完。
比赛结束后发现成绩还是有点囧，Rank17，铜牌之后的两个。。。sigh。
下午的题目比较多，ABCDEFG。都还有点难度，所以大概20多分钟以后才开始写，把那个切割的题目写了（按照二分的模式去模拟就行了），然后看那个tree的问题，其实思路还是比较清晰的，就是DEBUG用了很久，就那么三四十行的代码啊。。。sigh。然后过了三组test case，提交WA。囧啊囧啊囧。想了很久，发现原来node[1]不一定是root。邪恶的测试数据。。再改一下，就AC了。这时候只剩下一个小时。然后去看A的那个题目。那是去年暑训的题目，当时就完全没有思路，这一次稍微有点思路，枚举+列方程求解，但是最后还是没有搞定。赛后看了jieyu的A和E的代码，然后没什么想法，继续搁置那题。。。。。。
比赛结束后Rank18，除掉那个测试帐号，和上午一样，恨。。。
sigh。我发现我始终还是只把acm当作娱乐项目，就这么混过了3年。
早上的那一场做得比较随便，跟师兄聊着聊着就聊过头了，等聊完都过了十几min了。于是没有看statistics，挑了个逆序数的题目做，数据比较大，所以用归并，但是居然WA了。到WOJ的1046去测试了一下，是AC的啊，郁闷。于是去看Ranklist，发现另外一道简单题大部分人都过了，于是去写，很快1AC。然后回到那题，发现它对付超大数据有问题，于是改成long long，AC。然后又看到最后一个简单的题目，大约花了10min（说明我代码速度还是不行啊），1AC。虽然这个时候罚时比较多了，但是出3题的人不多，所以rank还比较靠前。剩下的时间在对付那个概率论的题目。显然[30][30][1000]的数据硬搞是要TLE的，不过对于我这种DPSB而言，还是老老实实先写一个出来再说。看题目就花了不少时间，然后写了个爆搜，算出了题目test case，但是提交上去就MLE了。然后想试试打表，但是在自己机器上都算不完。
比赛结束后发现成绩还是有点囧，Rank17，铜牌之后的两个。。。sigh。
下午的题目比较多，ABCDEFG。都还有点难度，所以大概20多分钟以后才开始写，把那个切割的题目写了（按照二分的模式去模拟就行了），然后看那个tree的问题，其实思路还是比较清晰的，就是DEBUG用了很久，就那么三四十行的代码啊。。。sigh。然后过了三组test case，提交WA。囧啊囧啊囧。想了很久，发现原来node[1]不一定是root。邪恶的测试数据。。再改一下，就AC了。这时候只剩下一个小时。然后去看A的那个题目。那是去年暑训的题目，当时就完全没有思路，这一次稍微有点思路，枚举+列方程求解，但是最后还是没有搞定。赛后看了jieyu的A和E的代码，然后没什么想法，继续搁置那题。。。。。。
比赛结束后Rank18，除掉那个测试帐号，和上午一样，恨。。。
sigh。我发现我始终还是只把acm当作娱乐项目，就这么混过了3年。
May
10
对于一个felix能做出4题的比赛，我想这次的题目实在是够简单了。毕竟是初赛。
A题，服务器173上的A题（据测试，至少有4台独立的服务器170~173跑着POJ的程序）
就是那个求和的程序，那显然应该速战速决1AC——这是我机器上14:01:02写完的程序：
173上的B题，也就是企鹅豆豆的那题，让我想起了打豆豆的笑话。
一眼看过去，觉得是一个超简单的题目，sort一遍，然后O(n^2)遍历求出一个i，比penguin[i]高且力气大的企鹅是最多的。
通过了test case，然后提交，WA。
暂时忽略之，然后看了CDE题的题意，发现还是应该先搞B。
于是回过头来，仔细想了一下，发现自己SB了：
以H(Height)和S(Strength)建立一个直角坐标系，把所有的企鹅放进去
然后对任意两个企鹅a, b: 如果La < Lb 且 Sa < Sb，那么画一条从a到b的有向线段，于是就构成了一张图，或者是一个有交叉的森林，或者又可以叫做拓扑图？反正就是那么一个东西，然后有那么几个点只有出度没有入度（暂且称之为源点），有那么几个点只有入度没有出度（暂且称之为终点），我们要找一条从某一个源点到某一个终点的最长的路线。顺着这个思路，于是就想到了BFS：对每一个点都BFS过去，最后遍历所有的点，找出最大的深度，就是所求结果了。很快code完，提交，TLE。囧。看了一下，发现自己非常SB地在每次BFS以后都把所有的点的depth初始化了。注释掉这一句，提交，AC，14:32:58。
A题，服务器173上的A题（据测试，至少有4台独立的服务器170~173跑着POJ的程序）
就是那个求和的程序，那显然应该速战速决1AC——这是我机器上14:01:02写完的程序：
#include<iostream>
using namespace std;
int main(){
int n, i, t, sum = 0;
scanf("%d", &n);
for (i = 0; i < n; ++i){
scanf("%d", &t);
sum += t;
}
printf("%d\n", sum);
return 0;
}
using namespace std;
int main(){
int n, i, t, sum = 0;
scanf("%d", &n);
for (i = 0; i < n; ++i){
scanf("%d", &t);
sum += t;
}
printf("%d\n", sum);
return 0;
}
173上的B题，也就是企鹅豆豆的那题，让我想起了打豆豆的笑话。
一眼看过去，觉得是一个超简单的题目，sort一遍，然后O(n^2)遍历求出一个i，比penguin[i]高且力气大的企鹅是最多的。
通过了test case，然后提交，WA。
暂时忽略之，然后看了CDE题的题意，发现还是应该先搞B。
于是回过头来，仔细想了一下，发现自己SB了：
以H(Height)和S(Strength)建立一个直角坐标系，把所有的企鹅放进去
然后对任意两个企鹅a, b: 如果La < Lb 且 Sa < Sb，那么画一条从a到b的有向线段，于是就构成了一张图，或者是一个有交叉的森林，或者又可以叫做拓扑图？反正就是那么一个东西，然后有那么几个点只有出度没有入度（暂且称之为源点），有那么几个点只有入度没有出度（暂且称之为终点），我们要找一条从某一个源点到某一个终点的最长的路线。顺着这个思路，于是就想到了BFS：对每一个点都BFS过去，最后遍历所有的点，找出最大的深度，就是所求结果了。很快code完，提交，TLE。囧。看了一下，发现自己非常SB地在每次BFS以后都把所有的点的depth初始化了。注释掉这一句，提交，AC，14:32:58。
