Jun
16
zz from http://c-faq-chn.sourceforge.net/ccfaq/node206.html#q:12.17
13.15 当我用 "%d\n" 调用 scanf 从键盘读取数字的时候, 好像要多输入一行函数才返回。
可能令人吃惊, \n 在 scanf 格式串中不表示等待换行符, 而是读取并放弃所有的空白字符
@2oo911o8
前些天试了一下，其实所谓\n代表所有空白字符，倒不如说scanf将所有空白字符等同视之：
在这里你用scanf(" "); scanf("\t");效果都是一样的。
13.15 当我用 "%d\n" 调用 scanf 从键盘读取数字的时候, 好像要多输入一行函数才返回。
可能令人吃惊, \n 在 scanf 格式串中不表示等待换行符, 而是读取并放弃所有的空白字符
@2oo911o8
前些天试了一下，其实所谓\n代表所有空白字符，倒不如说scanf将所有空白字符等同视之：
在这里你用scanf(" "); scanf("\t");效果都是一样的。
Jun
14
nth element, 也就是要找出一个数列中排名第n的那个数。
很直观地，把所有的数排序以后，就可以得出这nth element了。
快排测试：4.5s，1千万个int。
仔细想一下，这似乎有点浪费：其实只要找出最大的n个就行了。
如果n比较小，我们可以直接用选择排序。
这个程序太简单了，懒得测试。
然后再仔细想一下，发现还是有点浪费，其实前n个数不需要排序。
于是可以用最小堆来实现。
测试结果：3.02s，1千万个int，n = 500。
然后你可能会发现，STL里面有个函数，叫做nth_element，就是用来做这个的
测试一下：3.4s，1千万个int, n = 500。
如果想要深入了解，那么实际上这个nth_element使用的算法是快速划分。
它其实就是不完全的快速排序，只要递归地排序需要排序的部分就可以了。
自写代码测试：3.4s，1千万个int, n = 500。
------
从上面可以看出，在k=500（N = 10,000,000)时，最小堆是最快的，其次是快速划分，快排当然最慢。
最小堆的时间复杂度是 O( N * log(k) )
快速划分虽然平均时间复杂度是O(C*N)（但是C比较大），但是最坏时间复杂度是O(N^2)（所以随机化很重要！可以避免RPWT！）
快排就不用说了，撑死 O(N * log(N) )，最坏时间复杂度也可能是O(N^2)。
似乎最小堆是最快的，快速划分慢些，但是它们各有自己的适用范围：
当 k 接近 N / 2时，最小堆的时间复杂度其实就相当于一个堆排，事实上还不如快排。
所以最小堆的适用范围是k << N时的情况，或者当k 很接近N， 可以转化成 N-k << N的情况。
而快速划分的算法本身决定了其复杂度和 k 的大小无关，所以当 k 接近 N/2 时，快速划分显然更优。
可是还有另一种情况，也是大公司面试的时候很可能会问到的题目：
给你200亿个整数，找出TOP500000。
第一次遇到这个问题，估计大多数人直接口突白沫了吧。
200亿，对一般PC而言，内存显然存不下，需要保存在辅存中，而辅存的IO速度。。。
所以你应该尽可能少地扫描。
于是这时候最小堆就是最优解决方案：只扫描一遍，就可以得出结果。
------
代码如下：
很直观地，把所有的数排序以后，就可以得出这nth element了。
快排测试：4.5s，1千万个int。
仔细想一下，这似乎有点浪费：其实只要找出最大的n个就行了。
如果n比较小，我们可以直接用选择排序。
这个程序太简单了，懒得测试。
然后再仔细想一下，发现还是有点浪费，其实前n个数不需要排序。
于是可以用最小堆来实现。
测试结果：3.02s，1千万个int，n = 500。
然后你可能会发现，STL里面有个函数，叫做nth_element，就是用来做这个的
测试一下：3.4s，1千万个int, n = 500。
如果想要深入了解，那么实际上这个nth_element使用的算法是快速划分。
它其实就是不完全的快速排序，只要递归地排序需要排序的部分就可以了。
自写代码测试：3.4s，1千万个int, n = 500。
------
从上面可以看出，在k=500（N = 10,000,000)时，最小堆是最快的，其次是快速划分，快排当然最慢。
最小堆的时间复杂度是 O( N * log(k) )
快速划分虽然平均时间复杂度是O(C*N)（但是C比较大），但是最坏时间复杂度是O(N^2)（所以随机化很重要！可以避免RPWT！）
快排就不用说了，撑死 O(N * log(N) )，最坏时间复杂度也可能是O(N^2)。
似乎最小堆是最快的，快速划分慢些，但是它们各有自己的适用范围：
当 k 接近 N / 2时，最小堆的时间复杂度其实就相当于一个堆排，事实上还不如快排。
所以最小堆的适用范围是k << N时的情况，或者当k 很接近N， 可以转化成 N-k << N的情况。
而快速划分的算法本身决定了其复杂度和 k 的大小无关，所以当 k 接近 N/2 时，快速划分显然更优。
可是还有另一种情况，也是大公司面试的时候很可能会问到的题目：
给你200亿个整数，找出TOP500000。
第一次遇到这个问题，估计大多数人直接口突白沫了吧。
200亿，对一般PC而言，内存显然存不下，需要保存在辅存中，而辅存的IO速度。。。
所以你应该尽可能少地扫描。
于是这时候最小堆就是最优解决方案：只扫描一遍，就可以得出结果。
------
代码如下：
Jun
14
回忆一下tx的二面，有一道题是这样的：
假设有1kw个身份证号，以及他们对应的数据。身份证号可能重复，要求找出出现次数最多的身份证号。
一个很显然的做法是，hash之，O(n)搞定。这前提是内存中可以存下。
如果是中国的13亿人口，内存中存不下呢？借用磁盘，多次扫描？磁盘IO的速度慢得能让你疯掉。
这时候你终于感受到，中国人口真TMD多阿。。。
--
然后再看看今天的astar复赛第一题：
假设有1kw个身份证号，以及他们对应的数据。身份证号可能重复，要求找出出现次数最多的身份证号。
一个很显然的做法是，hash之，O(n)搞定。这前提是内存中可以存下。
如果是中国的13亿人口，内存中存不下呢？借用磁盘，多次扫描？磁盘IO的速度慢得能让你疯掉。
这时候你终于感受到，中国人口真TMD多阿。。。
--
然后再看看今天的astar复赛第一题：
Jun
14
算是续上篇文章吧。
上篇文章最后我有一个不是太好的总结（当然，在上一篇应该成立）：
我们知道vector和数组在基本操作上都是同一数量级的，而且事实上它们的常数也没有多少差别
所以我们可以放心地用vector来替换数组，不仅如此，他们在存储效率上，几乎也没有差别
一个简单的测试程序表明，存储1kw个整数，使用vector，整个程序消耗38.4MB空间，使用array，消耗38.2MB空间。
所以在这里我们可以放纵我们的迷信。
但是迷信也有限度的，就像上帝可以创造万物，但是不能创造自己。
然后进入本篇的主题：map/set的效率。
众所皆知，map/set底层数据结构是RB Tree，虽然不是真正的平衡树
但是其查找效率在统计上是比AVL等平衡树效率更高的，都能达到O(logN)的水平。Excellent。
于是我就迷信了，导致了自己对map的滥用，导致了很挫的结果。
究其原因，我忽略了那个确实很容易被忽略的东西，因为在提及复杂度的时候一般都不讲它。
——它就是传说中的那个常数。（我是不是很挫? =.=）
废话少说，数据说话：
map/set + 1,000,000个int的插入：
real 0m2.153s
user 0m1.812s
sys 0m0.056s
vector + 1,000,000个int的插入 + sort()：
real 0m0.581s
user 0m0.436s
sys 0m0.016s
改成堆排sort_heap()：
real 0m0.628s
user 0m0.492s
sys 0m0.016s
差别已经很明显了。
-----
然后再看看内存占用：
map: 19.4MB
vector: 4.1MB
so, hash + map用来构建hash table是我至今为止干过的最挫的事情之一了。——还不如用个vector。
上篇文章最后我有一个不是太好的总结（当然，在上一篇应该成立）：
引用
结论：在大多数情况下，我们可以迷信STL之父对效率的迷信。
我们知道vector和数组在基本操作上都是同一数量级的，而且事实上它们的常数也没有多少差别
所以我们可以放心地用vector来替换数组，不仅如此，他们在存储效率上，几乎也没有差别
一个简单的测试程序表明，存储1kw个整数，使用vector，整个程序消耗38.4MB空间，使用array，消耗38.2MB空间。
所以在这里我们可以放纵我们的迷信。
但是迷信也有限度的，就像上帝可以创造万物，但是不能创造自己。
然后进入本篇的主题：map/set的效率。
众所皆知，map/set底层数据结构是RB Tree，虽然不是真正的平衡树
但是其查找效率在统计上是比AVL等平衡树效率更高的，都能达到O(logN)的水平。Excellent。
于是我就迷信了，导致了自己对map的滥用，导致了很挫的结果。
究其原因，我忽略了那个确实很容易被忽略的东西，因为在提及复杂度的时候一般都不讲它。
——它就是传说中的那个常数。（我是不是很挫? =.=）
废话少说，数据说话：
map/set + 1,000,000个int的插入：
real 0m2.153s
user 0m1.812s
sys 0m0.056s
vector + 1,000,000个int的插入 + sort()：
real 0m0.581s
user 0m0.436s
sys 0m0.016s
改成堆排sort_heap()：
real 0m0.628s
user 0m0.492s
sys 0m0.016s
差别已经很明显了。
-----
然后再看看内存占用：
map: 19.4MB
vector: 4.1MB
so, hash + map用来构建hash table是我至今为止干过的最挫的事情之一了。——还不如用个vector。
Jun
14
看过《STL之父访谈录》，了解了STL之父对效率的极度迷信，因而我对STL容器的效率也是很迷信的。
但是某一次和feli聊到vector的效率问题，他说，有时候在比赛的时候用vector会TLE，换成自己写的单链表就AC了。
可惜当时是在永和门口争论的，无法验证，后来某天想到这个问题，于是验证之：
1. vector和数组的效率对比：
对一个含有100,000,000个元素的int数组进行循环10遍的写入，测试结果(使用linux下的time命令统计)为：
Array:
real 0m3.801s
user 0m3.136s
sys 0m0.568s
Vector:
real 0m4.210s
user 0m3.548s
sys 0m0.520s
可以看出，vector和Array相比，至少在acm程序中，效率损失几乎是可以忽略的。
还需要声明一点，这里的vector是在运行时动态申请的空间，而array则是预分配的。
测试程序后附。
2. 单链表的效率和STL的list效率对比：
添加10,000,000个元素，测试结果为：
单链表:
real 0m0.836s
user 0m0.620s
sys 0m0.204s
list<int>:
real 0m1.202s
user 0m1.024s
sys 0m0.168s
可以看出来，完全没必要和vector对比的，接近两个数量级的差距阿。
单链表比STL的list快并不是因为STL效率损失，而是因为STL的list是一个双向链表，可能还有更多的底层细节（具体我就不了解了）。
---------------------
所以很显然的，vector比手写的单链表快。快很多。非常多。至于原因，我觉得主要有2：
1。链表是基于指针访问的，不仅需要更多的访存，而且cache命中率会比较低。
而vector的存储空间是连续的，在连续访问的情况下，命中率会高很多。
2。链表的内存是动态申请的，每一次都使用new/malloc从系统维护的堆中进行申请，效率很低。
当然，STL的list使用了优秀的allocator，但是效率仍然和vector无法比拟，所以说明第一条才是关键。
结论：在大多数情况下，我们可以迷信STL之父对效率的迷信。
--------------------
下附测试代码：
但是某一次和feli聊到vector的效率问题，他说，有时候在比赛的时候用vector会TLE，换成自己写的单链表就AC了。
可惜当时是在永和门口争论的，无法验证，后来某天想到这个问题，于是验证之：
1. vector和数组的效率对比：
对一个含有100,000,000个元素的int数组进行循环10遍的写入，测试结果(使用linux下的time命令统计)为：
Array:
real 0m3.801s
user 0m3.136s
sys 0m0.568s
Vector:
real 0m4.210s
user 0m3.548s
sys 0m0.520s
可以看出，vector和Array相比，至少在acm程序中，效率损失几乎是可以忽略的。
还需要声明一点，这里的vector是在运行时动态申请的空间，而array则是预分配的。
测试程序后附。
2. 单链表的效率和STL的list效率对比：
添加10,000,000个元素，测试结果为：
单链表:
real 0m0.836s
user 0m0.620s
sys 0m0.204s
list<int>:
real 0m1.202s
user 0m1.024s
sys 0m0.168s
可以看出来，完全没必要和vector对比的，接近两个数量级的差距阿。
单链表比STL的list快并不是因为STL效率损失，而是因为STL的list是一个双向链表，可能还有更多的底层细节（具体我就不了解了）。
---------------------
所以很显然的，vector比手写的单链表快。快很多。非常多。至于原因，我觉得主要有2：
1。链表是基于指针访问的，不仅需要更多的访存，而且cache命中率会比较低。
而vector的存储空间是连续的，在连续访问的情况下，命中率会高很多。
2。链表的内存是动态申请的，每一次都使用new/malloc从系统维护的堆中进行申请，效率很低。
当然，STL的list使用了优秀的allocator，但是效率仍然和vector无法比拟，所以说明第一条才是关键。
结论：在大多数情况下，我们可以迷信STL之父对效率的迷信。
--------------------
下附测试代码：
Jun
13
花了一点时间测试使用semaphore和pthread_mutex这两个东西，很赞。
#include<semaphore.h>
sem_init()
sem_wait()
sem_post()
#include<pthread.h>
pthread_mutex_init()
pthread_mutex_lock()
pthread_mutex_unlock()
@ 2009-06-14 0:00 p.s.
居然还有 pthread_spinlock_t .... Orz了。
pthread_spin_init()
pthread_spin_lock()
pthread_spin_unlock()
#include<semaphore.h>
sem_init()
sem_wait()
sem_post()
#include<pthread.h>
pthread_mutex_init()
pthread_mutex_lock()
pthread_mutex_unlock()
@ 2009-06-14 0:00 p.s.
居然还有 pthread_spinlock_t .... Orz了。
pthread_spin_init()
pthread_spin_lock()
pthread_spin_unlock()
Jun
1
1。
很happy，哈哈。
刚刚看 /usr/include/c++/4.3/bits/stl_stack.h
发现原来stack和queue使用的底层容器默认是deque，名字是c, 而且是protected
@ 2009-06-29 p.s.
其实这是件很挫的事情，STL容器的析构函数不是虚函数，继承自他们的子类的析构函数不会被调用，有可能导致内存泄露。
2。
看侯捷大神的《STL源码剖析》以及GCC的STL源码后凑出来的这一段代码。调用 printBufSize() 后输出应该是512。
这个要追溯到一周前和sandy的一个小争论。
记得以前看到过deque的底层实现是分多段连续空间的，以达到高效的首尾增删以及可以接受的随机访问效率
输出的这个512就是SGI STL的默认分段大小。
但是sandy却说，所谓的“分段连续”实际上是分成两段 （听起来就觉得不太对头 -__- )
于是今天特地翻出这本书膜拜一下。当然，不排除其他STL实现使用分两段的可能性，但是这个效率恐怕就不太对劲了。
class mystack: public stack<int>{
public:
int & operator[](unsigned int i){
return c[i];
}
};
public:
int & operator[](unsigned int i){
return c[i];
}
};
很happy，哈哈。
刚刚看 /usr/include/c++/4.3/bits/stl_stack.h
发现原来stack和queue使用的底层容器默认是deque，名字是c, 而且是protected
@ 2009-06-29 p.s.
其实这是件很挫的事情，STL容器的析构函数不是虚函数，继承自他们的子类的析构函数不会被调用，有可能导致内存泄露。
2。
class t: public deque<char>{
public:
void printBufSize(){
std::cout << __deque_buf_size(sizeof(char)) << endl;
}
};
public:
void printBufSize(){
std::cout << __deque_buf_size(sizeof(char)) << endl;
}
};
看侯捷大神的《STL源码剖析》以及GCC的STL源码后凑出来的这一段代码。调用 printBufSize() 后输出应该是512。
这个要追溯到一周前和sandy的一个小争论。
记得以前看到过deque的底层实现是分多段连续空间的，以达到高效的首尾增删以及可以接受的随机访问效率
输出的这个512就是SGI STL的默认分段大小。
但是sandy却说，所谓的“分段连续”实际上是分成两段 （听起来就觉得不太对头 -__- )
于是今天特地翻出这本书膜拜一下。当然，不排除其他STL实现使用分两段的可能性，但是这个效率恐怕就不太对劲了。
May
31
东华比赛总结 By Felix021 @ 70km??
首先批一下主办方。。。整个比赛过程都好挫，包括比赛的衣服、证书、没有队牌、不发餐券、让参赛选手站在赛场外面等、打印很麻烦、工作人员不太负责、发的点心是很挫的饼干而且还是比赛快结束了才发下来（以及水）、比赛结束后就散了，证书也不知道怎么着、题目非常囧。。。。。。（400米的报名费阿，相当相当地不值得）
然后批一下自己吧。。。整个比赛过程也好挫，纠结在一道最后才有一只队伍出的数学题目上，WA了5次最后还是没过。。。严重失误，嗯。
正式过程是这样的，首先是练习赛，A+B不说了，接下来一道很麻烦的模拟题，写了100多行的代码调了半天还没调对头就结束了- -|| 不过新版本的PC^2做的很不错阿，可以直接compile & run & test，题目也直接显示在侧边，用起来很方便。
12点开始正式比赛，10道题目，我看ABCD，jieyu看EFG，yihong看HIJ。A题是求生成树的数量，yihong和jieyu都看过那篇论文，但是忘了具体怎么做。B是一个SB题，看到有队伍AC了，马上写，提交，AC。C题是一个计算几何，给出一个圆的半径和三角形的三条边，求二者可能交叉的最大面积，这题只有6提交，0AC。D题是一个概率论的题目，数学盲飘过。。E题也很囧，给你一个n，要求用加减乘除最后能组合出多少种不同的算式，0提交。F题就是我们一直纠结的那道数学题了，因式分解(x^n-1)，我和yihong想得非常深了，已经几乎完全确定没有问题了，但是最后还是WA了，非常无语。G题是一个简单的模拟，暴力一下就行了，jieyu写的，WA了一次很郁闷，我看了下他的代码，发现是边界条件写错了，改了两个地方，AC。H题比较像是线段树的题目，但是在具体实现上感觉又很困难，我写了一点写不下去了（其实根本就不该写，另一个失误），最后的rank显示这题是84提交0AC。I题是另一个数学题，要求[a,b]之间所有数字化成最小底数后的幂的和，数据量太大，没有想法。最后J题，算是计算几何吧：求钟表指针的重心从time1到time2经过的路程；这描述一看就觉得太TM复杂了，这是怎样一个弧线，算个毛阿。于是就一直没去想，但是3个小时左右的时候收到一个说明，每一秒内的运动按直线算----其实这样的话这提就比较简单了，最后AC率超过50%，不过当时一直在想F，所以没有去看那题，又一个大失误。
于是最后只出2题，Rank35，按照10%,20%,30%的比例，108支队伍，我们应该就是铜牌开始的那几个了，sigh。
总的来说这次比赛结果不太好，有两个原因：
1。偏题：题目都靠近计算几何、数学题，看不到经典的DP和图论，于是我们三个都挂了。
2。决策失误，以上详细说明了，很遗憾，否则我们至少应该能出3题。
首先批一下主办方。。。整个比赛过程都好挫，包括比赛的衣服、证书、没有队牌、不发餐券、让参赛选手站在赛场外面等、打印很麻烦、工作人员不太负责、发的点心是很挫的饼干而且还是比赛快结束了才发下来（以及水）、比赛结束后就散了，证书也不知道怎么着、题目非常囧。。。。。。（400米的报名费阿，相当相当地不值得）
然后批一下自己吧。。。整个比赛过程也好挫，纠结在一道最后才有一只队伍出的数学题目上，WA了5次最后还是没过。。。严重失误，嗯。
正式过程是这样的，首先是练习赛，A+B不说了，接下来一道很麻烦的模拟题，写了100多行的代码调了半天还没调对头就结束了- -|| 不过新版本的PC^2做的很不错阿，可以直接compile & run & test，题目也直接显示在侧边，用起来很方便。
12点开始正式比赛，10道题目，我看ABCD，jieyu看EFG，yihong看HIJ。A题是求生成树的数量，yihong和jieyu都看过那篇论文，但是忘了具体怎么做。B是一个SB题，看到有队伍AC了，马上写，提交，AC。C题是一个计算几何，给出一个圆的半径和三角形的三条边，求二者可能交叉的最大面积，这题只有6提交，0AC。D题是一个概率论的题目，数学盲飘过。。E题也很囧，给你一个n，要求用加减乘除最后能组合出多少种不同的算式，0提交。F题就是我们一直纠结的那道数学题了，因式分解(x^n-1)，我和yihong想得非常深了，已经几乎完全确定没有问题了，但是最后还是WA了，非常无语。G题是一个简单的模拟，暴力一下就行了，jieyu写的，WA了一次很郁闷，我看了下他的代码，发现是边界条件写错了，改了两个地方，AC。H题比较像是线段树的题目，但是在具体实现上感觉又很困难，我写了一点写不下去了（其实根本就不该写，另一个失误），最后的rank显示这题是84提交0AC。I题是另一个数学题，要求[a,b]之间所有数字化成最小底数后的幂的和，数据量太大，没有想法。最后J题，算是计算几何吧：求钟表指针的重心从time1到time2经过的路程；这描述一看就觉得太TM复杂了，这是怎样一个弧线，算个毛阿。于是就一直没去想，但是3个小时左右的时候收到一个说明，每一秒内的运动按直线算----其实这样的话这提就比较简单了，最后AC率超过50%，不过当时一直在想F，所以没有去看那题，又一个大失误。
于是最后只出2题，Rank35，按照10%,20%,30%的比例，108支队伍，我们应该就是铜牌开始的那几个了，sigh。
总的来说这次比赛结果不太好，有两个原因：
1。偏题：题目都靠近计算几何、数学题，看不到经典的DP和图论，于是我们三个都挂了。
2。决策失误，以上详细说明了，很遗憾，否则我们至少应该能出3题。
