1 引

在九月短文 [1] 中, 我们对豆瓣电影评分的一个侧面有了简单认识. 其实, 我们对评分计算规则本身也是很感兴趣的. 这里以豆瓣电影为例作一简单猜想和分析, 音乐图书同理. 题中"策略"是相对"机制"来说的, 所指其实是比较具体的.

2 单个条目

有群众表示, 单个条目的评分计算只是对各个星级打分人数简单的加权平均, 由于页面上显示的评分结果满分是10分, 而打分时只有5个星级, 所以每个星级对应2分, 单个条目评分的计算公式即为:

评分 = (10 x 5星比例) + (8 x 4星比例) + ... + (2 x 1星比例)

抽取部分条目对此假设进行手工验证, 可以发现的确如此.

但是, 这里存在的一个陷阱是, 由于评分数据的特殊性和抽样的限制, 如果我们抽取一部分数据做回归, 结果可能会受到样本的影响而与手工验证的结果产生偏移. 由于1星(很差)和2星(较差)在大量条目样本中所占往往比例非常小, 普通的回归非常容易倾向于使X1, X2, X3的系数减小. 举例来说, 从我看过的443部电影中抽取前400个条目作为样本 [rateSample.csv] 作回归.

回归结果:
Call:
lm(formula = Y ~ . - 1, data = rateSample)

Residuals:
Min 1Q Median 3Q Max
-0.248949 -0.036126 0.001084 0.042101 0.217110

Coefficients:
Estimate Std. Error t value Pr(>|t|)
X5 9.97216 0.01884 529.436 <2e-16 ***
X4 7.98297 0.03287 242.901 <2e-16 ***
X3 5.64024 0.05587 100.962 <2e-16 ***
X2 4.41272 0.29841 14.787 <2e-16 ***
X1 1.38666 0.64675 2.144 0.0326 *
---
Signif. codes: 0 '***' 0.001 '**' 0.01 '*' 0.05 '.' 0.1 ' ' 1

Residual standard error: 0.06798 on 395 degrees of freedom
Multiple R-squared: 0.9999, Adjusted R-squared: 0.9999
F-statistic: 1.053e+06 on 5 and 395 DF, p-value: < 2.2e-16

由于这里的评分人数比例存在四舍五入现象, 所以每个条目5个星级的评分人数比例之和并不一定严格为1, 不过画图可知基本都处于[0.999, 1.001], 存在4个和为0.998, 1.002的样本, 不影响结果.

观察回归结果发现, 样本的这种特殊情况确对X3, X2, X1项有影响, 虽然检验结果是显著的, 但偏离了真实值6, 4, 2很远.

插句题外话, Box(是的, 就是你知道的那个Box)曾曰, Statisticians, like artists, have the bad habit of falling in love with their models.

爱不爱上模特的事情我不是很懂, 不过, 真的不要爱上模型. 原因么, 我们续写一下名句就知道了:

Models are always with their assumptions.

题外话完毕. 使用平行坐标图展示一下这400部的评分数据:

可见大部分样本的整体评分状况. 1, 2星的数量远不及3, 4, 5星.

猜想这种情况可能是两种原因所致:

• 豆瓣的电影推荐让用户更倾向于去看他人评价较高的影片, 越是评分较低的影片越无人光顾, 于是拉高了整体评分;
• 用户可能对那些质量一般的电影疏于打分, 而对自己喜欢的片子倾向于打分. 这就造成了客观上部分低分评分数据的缺失, 特别是在5分制(不同于IMDB的10分制)对于影片的区分度比较低的情况下.

3 豆瓣电影250榜单

豆瓣电影和IMDB都有TOP 250榜单. 关于豆瓣电影250的计算方法, 之前已经有一些讨论 [2]. 一个有趣的问题是, 假设豆瓣的确使用了IMDB公式 [3] 计算得到此榜单, 可否由数据反演出公式中的两个参数?

其实, 这是一个以排序为因变量的回归问题, 既不同于传统的纯回归问题, 又不同于经典的排序学习问题. 事实上, 这个问题对两方面都提出了比较高的要求:

1. 对于传统的回归问题, 这里我们虽然想求得回归系数, 但目标变量是一种排序;
2. 对于经典的排序学习问题, 这里我们虽然目标变量是排序, 但要求针对回归方程求出显式的回归系数;
3. 如果转化为传统的分类问题, 信息会有比较大的损失.

翻箱倒柜, 发现KDD10'的一片文章中, 来自Google的D. Sculley提出了一种方法 [4] (给出了现成工具 [5], 还有人port了R包 [6]) 来处理这类问题, 但由于这里的问题是非线性的, 不好直接处理.

不过不要对生活失去信心. 由于维度较低, 最终仍然有一种方法是可行的: 我们可以估计出参数所在的大致区间, 然后针对某种排序准确性的测度(这里单纯地采用了街区距离和欧氏距离), 暴力搜索这些区间组成的空间, 最后取排序结果最准确的点或点集. 按这个思路做了一下, 在使用这个公式的假设下, 可以估计取得数据时 (2011/12/26) 的参数C约为[6.0, 6.1], 参数m大致在[2900, 3100].

由于豆瓣电影250的榜单并非实时更新, 而榜单中的评分人数和得分却是实时更新的, 且网格的密度有限, 猜解结果理应存在误差. 我们猜测, 这种现实情况可能对于位于榜单后半部分的影片产生更强的影响, 而榜单上排名靠前的影片则会相对稳定. 对各个元素所在位置与其真实位次产生的偏移做分位回归 [7]:

红色虚线为最小二乘估计, 灰色实线为0.1, 0.25, 0.75, 0.9五个分位点处的分位回归估计, 黑色实线为0.5分位点.

看图说话:

• 榜单偏后部分的偏移比前半部分稍强;
• 不同分位点的样本点偏移程度受其所在榜单位置的影响稍有不同.

有兴趣的同学还可以跟踪观察榜单更新时得到的计算结果将有何变化.

4 结

有益的思考:

1. 单个条目的评分就是单纯的对5个得分进行加权平均. 此法尚有修正空间, 如果未考虑不同用户的评分权重, 则容易引入恶意评分问题;
2. 豆瓣250榜单的计算可能借鉴了IMDB公式, 也可能对其设计进行了修改. 关于这个公式本身, 存在一些评论 [8], 或可对其进行修正;
3. 在使用这个公式的假设下, 可以根据豆瓣电影250榜单的变化情况即时猜解参数, 从而了解当时(设定的)所有电影的平均分和上榜最低评分人数标准. 由这两个参数, 结合现有榜单所含信息, 我们可以在榜单更新延迟时, 提前推得某个条目在有一定评价人数(>m)时, 达到某个位置所需的最低得分; 或保持一定得分前提下, 分析上榜所需的最少评分人数.

存在的问题:

1. 如果实际上未使用原始公式, 则以上估计是几乎没有什么意义的;
2. 如果榜单有人为因素的干预, 例如只计算经常打分的用户的打分, 将对这种估计造成影响 [8];
3. 排序准确性测度有待商榷;
4. 这种解法虽然给出了全局最小, 但这个全局最小并不一定与真实参数等价, 真实参数也有可能隐匿在其它较小值的集合中.

最后, 有代码有真相. [dbrank.R]

参考

[1] R2S. 豆瓣用户对不同类型影片的打分是否真的有倾向性?

[2] 麻油四. 豆瓣250算法浅析.

[3] Wikipedia. Internet Movie Database.

[4] D. Sculley. Combined Regression and Ranking. Proceedings of the 16th Annual SIGKDD Conference on Knowledge Discover and Data Mining, 2010.

[5] D. Sculley. sofia-ml - Suite of Fast Incremental Algorithms for Machine Learning.

[6] Michael King and Fernando Cela Diaz. (2011). RSofia: Port of sofia-ml to R.

[7] Roger Koenker (2011). quantreg: Quantile Regression.

[8] Corrected IMDb Movie Rankings.

1. Getting used to writing articles that begin with a section named 'Introduction' or end up with section 'Conclusions'.
2. Always cites several references in any type/length of essays; strongly believes that without the citations, the work will not be recognized by anybody.
3. Hates magazines with huge pictures and imprecise textual materials; has a special fondness for two-column, small font, tight dissertations with formulas, three-line tables, and stylish, dot-and-line formed scalable graphics.
4. Uses a reference manager, instead of regular tools such as Google Calendar, to organize daily life.
5. Blogs academic topics constantly for 2.5+ years, or has set up a stand-alone blog about current research.
6. Talks academic in 50%+ Twitter/Facebook status in last 2 years, or has pure academic purpose social accounts.
7. Used to have at least one horrible nightmares about a B+ ruined perfect straight As, just like Lisa Simpson did.
8. Once encountered some data from the middle of nowhere, always considers what its underlying patterns look like; imagines constructing a quantitative model for it, very seriously.
9. When saw a problem, couldn't help diving into scholar databases to retrieve related papers, thoroughly read the references and dug recursively; Gigabytes of papers are storaged in the hard-drive eventually.
10. Blogs academic paranoia and doesn't feel anything, until now.

Studying the networks of online software community is fascinating. CPAN Explorer is a typical project aiming at analyzing the relationships in CPAN community [1]. CRAN package dependency network is another excellent source for this type of research. A state-of-art visualization is usually required to understand the network [2].

A common problem of conventional hairball style network visualization is: the graph becomes uninterpretable when it meets very large networks [3]. Researchers developed techniques such as hierarchical edge bundles [4] to tackle this problem. However, that's just too ideal for real world visualization problems. When it's emphasizing the strong connections in the network, the less strong part and the key details could possibly be ignored. Conventional visualization methods have constrained us to take a further step: revealing more hidden information of the internal structure (vertices, connectivity, etc.) in the network.

2 Hive Plots

Martin Krzywinski, author of the circular style genome visualization tool circos, proposed the hive plots in 2010 [5]. The most significant difference between hive plots and traditional layout is: its graphic design is based on the network's meaningful properties (vertices' degree, connectivity, centrality, etc.) instead of aesthetics. This design makes the graph interpretable and thus simplifies the presentation of relational data.

3 The Visualization

We selected 27 representative packages and visualize every three of them in one hive plot to make a 3x3 hive panel. Each panel represents a specific research field. Each node of the network is mapped on the axes by its degree information: green axis represents out-degree, orange axis represents in-degree, and purple axis combines in/out-degrees together. On each axis, outer nodes have higher degrees. The white connections, as the background, show us the overall connectivity of the network: the nodes have higher out-degrees are heavily depended by all ranges of nodes in the network, and the brighter parts of the arcs tend to indicate potential cluster patterns.

Click here to see a larger version.

Click here to see a larger version.

Meanwhile, we highlight three of the interested packages in each research field in one panel with three different colors to reveal its specific connection patterns. For the first panel, green connections represents lattice package. It's a fundamental package for graphic design in R, which is heavily depended by packages of all degrees. The purple connections represent the rgl package. It depends a little but it's depended by much more packages that distributed more discretely on the orange axis than lattice was. Orange lines represent the gplots package, which contains various miscellaneous tools for plotting. Obviously, the dependency patterns indicate its different role between the previous ones: it's more of a handy toolset for plotting, rather than a core package. The upper right panel shows us three of the data import/export packages: DBI, RODBC and RSQLite. Amazingly, althought they play different roles in the whole community, their dependency patterns are almost the same, except for a little difference between their degrees. The central panel, which highlights the finance-related packages fBasics, fOptions, and fGarch, reveals similar features.

Hive plots are relatively much more informative and comprehensive than conventional hairball-style visualizations, especially for large networks. You could discover much more interesting patterns in other panels yourself with this visualization.

The selected packages (ordered by panel 11, 12, 13, 21, 22 …) are:

• Graphics: lattice / rgl / gplots (Green / Purple / Orange)
• Programming: tools / rJava / Rcpp
• Data Import/Export: DBI / RODBC / RSQLite
• GUI Dev Tools & Framework: tcltk / gWidgets / Rcmdr
• Finance: fBasics / fOptions / fGarch
• Machine Learning: e1071 / rpart / randomForest
• Regression Analysis: car / leaps / quantreg
• Spatial and Geo Statistics: sp / maps / fields
• Time Series Analysis: forecast / timeDate / tseries

4 Details

The creation of this visualization is really simple; highly reproducible for anyone who has a little knowledge of SNA [6]:

1. The original data was retrieved from
   http://cran.r-project.org/bin/windows/contrib/2.13/PACKAGES
   on September 14, 2011. We only extracted the 'Depends' section of each package. After parsing and a bit of cleaning, a network consisted of 2,500 vertices and 5,900 arcs was constructed.
2. To shrink the network, perform k-core analysis and extract the 4-6 cores partition to form a new network, a denser one, with less noise. Now it's reduced to about 600 vertices and 2,500 arcs.
3. Draw the shrinked network permuted by degree information with Martin's linnet tool. Each single panel implies a package's degree and dependency distribution properties. Combine the 9 separated hive plots to form a complete hive panel.

References

[1] Julian Bilcke. CPAN Explorer - An Interactive Exploration of the Perl Ecosystem. http://cpan-explorer.org/, 2009.
[2] Xiao Nan. R2S - PKU Vis Summer School. http://www.road2stat.com/cn/statistics/pku_vis_summer_school.html, 2010.
[3] Koon-Kiu Yana, Gang Fanga, Nitin Bhardwaja, Roger P. Alexandera, Mark Gerstein. Comparing Genomes to Computer Operating Systems in Terms of the Topology and Evolution of their Regulatory Control Networks. Proceedings of the National Academy of Sciences, 107 (20): 9186 - 9191, 2006.
[4] Danny Holten. Hierarchical Edge Bundles: Visualization of Adjacency Relations in Hierarchical Data. IEEE Transactions on Visualization and Computer Graphics (TVCG; Proceedings of Vis/InfoVis 2006), Vol. 12, No. 5, 741 - 748, 2006.
[5] Martin Krzywinski. Hive Plots - Linear Layout for Network Visualization - Visually Interpreting Network Structure and Content Made Possible. http://www.hiveplot.com/, 2010.
[6] Wouter de Nooy, Andrej Mrvar, Vladimir Batagelj. Exploratory Social Network Analysis with Pajek. Cambridge University Press, 2005.
[7] J.R. Heard. World Economic Forum Hive Plot. http://www.visualizing.org/visualizations/world-economic-forum-hive-plot/, 2010.

在豆瓣上为数不少的恐怖/惊悚片的讨论中, 我们常常可以发现类似于这样的说法 [1]:

像这部片子
也有吸引人看下去的地方
为什么分数总是那么低?

那么, 豆瓣用户对这类影片的打分上, 是否真的存在普遍低于其他类型的影片的情况? 为了验证这个猜想, 我们不妨利用豆瓣提供的评分数据来简单分析一下.

2 承

首先明确问题的定义. 这里我们不去比较恐怖片和其他所有类型片的总体. 其实, 更让人感兴趣的问题是, 将恐怖片与其他同级别类型的影片分别进行两两比较, 结果会如何.

豆瓣的电影条目是采用tag来进行分类的. 此时样本的选取成了一个问题. 总的来说, 要保证各类型影片的类型特征区别要尽量大, 比如恐怖片和惊悚片之间的差别没有恐怖片和励志片的差别明显, 又如有可能一部影片既有"爱情"标签, 也有"喜剧"标签, 也就是说, 各类型的影片将存在交集. 同时, 也要保证各类样本在其他方面的差别尽量小, 如不同类型影片的总体规模差距不能过于悬殊等等.

我是这样做的.

2.1 选取分类

参考IMDB的Genre分类, 在豆瓣电影标签页面选取8个比较主流的Genre, 标准是各类含有个数的差别不能过大, 因此剔除了动作/爱情/科幻等远超过100万部的类别. 同时, 各类之间的类型区别要明晰. 这8类和各类中的条目数分别为:

纪录 (592406)
励志 (579749)
犯罪 (545789)
恐怖 (524562)
科幻 (1463871)
战争 (480216)
文艺 (471861)
动画短片 (432140)

2.2 提取条目链接

各类按标注次数排序(type=O), 各类分别提取1600部(20部/页 x 80页)的条目链接:

1
2
3
4
5
6
7
8
9
10
11
12

require(XML)
idParser = function(genre, start) {
	url = paste("http://movie.douban.com/tag/", 
                    genre, "?start=", start, "&type=O", sep = '')
	idPage = htmlTreeParse(url, useInternal = TRUE)
	x = rep(NA, 20)
	for (i in seq(22, 61, 2)) {
	x[(i/2-10)] = xpathApply(idPage, path = "//a", 
                                 xmlGetAttr, "href")[[i]]
	}
	return(x)
}

这里考虑了评价人数的问题: 评分人数过少的条目不予入选. 豆瓣的评分计算方法中虽然像IMDB一样考虑了评分人数多少的问题 -- 评分人数少的条目虽然得分不会特别高或特别低, 但从反映主流观影口味角度, 选取观看人数较少的影片毕竟存在着较大风险. 同时不难发现, 每类在1600条处基本都有1000+左右的标注, 评分人数能够得到保证, 可以认为样本的评分比较公正.

2.3 剔除冗余条目

8类之间两两比较, 首先剔除本类中重复的条目(的确存在!), 然后剔除掉同时属于多类的条目. 此时每类剩余约1100 - 1300部互无任何交集的影片.

2.4 抽样

在剩余样本中, 每类随机抽取1000个条目.

2.5 读取评分

利用豆瓣API [2] 读取1000 x 8 = 8000个评分数据(平均分).

1
2
3
4
5
6
7

rateParser = function(id) {
	url = paste("http://api.douban.com/movie/subject/", id, 
				"?apikey={your api key}", sep = '')
	moviePage = htmlTreeParse(url, useInternal = TRUE)
	return(as.numeric(xpathApply(moviePage, 
	path = "//rating", xmlGetAttr, "average")[[1]]))
}

读数据时要注意, 即使申请了豆瓣的API key以后也有40次请求/分钟的限制. 我用的是最简单的方法: 把请求嵌入到循环中, 每请求一次后Sys.sleep(1.5)一下, 以保证每分钟请求不会超过40次. 我们可以在shell中开一个tail -f filename来实时监视文件写入情况.

3 转

有了数据先画图.

3.1 散点图

先画个散点图(由于是一维变量, 可称为strip plot)热身, 看一下各类评分的分布情况. 由于给出的评分值只精确到小数点后一位, 重复值很多, 先在原始数据上增加随机值把点打散, 同时使用alpha混合让点部分透明, 以争取避免叠加时产生的问题.

纪录片的绝大部分平均分都集中在7以上, 明显有别于其他Genre. 而8分以上的恐怖片则显得比较稀有. 所以, 在豆瓣看到8分以上的恐怖片, 就收了吧 ... 同时可以发现有一部励志片得分为0(事实上, 评价人数也为0)却能在tag标记人数方面上榜, 是哪部影片如此诡异呢? 此处略去不表 ...

由于样本量比较大, overplotting的情况比较严重, 散点图的效果实际上非常一般, 能够提取的信息有限.

3.2 核密度估计

对评分作核密度估计后画图.

各panel中的评分密度基本上都是单峰, 形状大致相同. 战争片/励志片是如此类似, 纪录片和文艺片也十分相像, 只是纪录片峰值处对应的评分要稍高于文艺片. 所以, 在豆瓣看到很多8-9分的纪录片, 不要惊讶.

3.3 箱线图

作箱线图.

可以看到带有文艺/犯罪标签的影片的评分分布最为稳定, 离群点很少, 可能也在一定程度上说明了这类影片的同质化比较严重. 恐怖片的中位数位置的确低于其他类型的影片, 高分也很少.

3.4 小提琴图

作小提琴图.

小提琴图综合了箱线图和核密度估计图的特点, 不过在这里的效果不算很理想, 不多说了.

4 合

最后, 是欢乐的统计检验环节. 由于分布的具体类型未知, 我们也不好随便假设, 所以还是用非参方法检验中位数吧.

设
u_1: 恐怖片评分的中位数
u_2: 其他某类影片评分的中位数
H_0: 豆瓣用户对恐怖片的打分与其他类无区别 u_1 = u_2
H_1: 豆瓣用户对恐怖片的打分比其他某类偏低 u_1 < u_2

作两样本Wilcoxon(Mann-Whitney)检验, 该检验需要的唯一假定就是两个总体的分布有类似的形状. 由前述核密度估计图以及小提琴图可知, 各总体分布的形状的确大致相同, 可以认为满足要求.

结果呢?

7次检验都拒绝了原假设.

恐怖片导演的确不好混, 一方面是想要拍出好的恐怖片的确不容易, 而且一不小心就被打上B级/cult的烙印. 知名导演很少会去拍纯粹的恐怖片, 尤其是多年以前的《电锯惊魂》这样的小成本惊悚/恐怖片出现以后, 近年涌现了越来越多的小制作影片和新人导演试水惊悚/恐怖类影片. 另一方面, 是不是人在看了比较精彩的恐怖片以后, 也被吓得倾向于打低分了呢? 不能不说, 这是一个有趣的问题.

参考

[1] 为什么恐怖片在豆瓣上的评分普遍很低.
[2] 豆瓣API参考手册.
[3] Deepayan Sarkar. Lattice: Multivariate Data Visualization with R. pp. 37-52.
[4] 吴喜之. 统计学: 从数据到结论. pp. 266-269.

Blekko的logo好像在前些日子由原来的beta升级为beta^2了, 页面正下方出现了一个名为"3 engine monte"的游戏. 玩法是, 输入"关键词 /Monte", 即可平行显示去格式后的Blekko, Google, Bing三方搜索结果, 用户可以根据经验猜测哪个结果是来自Blekko的, 点选以后即可显示猜测是否正确:

这里我以R为关键词进行搜索, 三个结果虽然都只有一页, 不过各有千秋. Google的结果明显偏重技术, bing的结果很杂, 不太靠谱. 而Blekko的结果的人为控制痕迹则比较明显, 基本上是一些比较权威信息源的首页.

有一种主流评论是, 你会发现Google和Bing的结果中往往会出现spam/内容农场等等无意义内容, 而Blekko的结果则相对干净. 而我想, 这或许会是一个不错的用户行为数据采集方式: 用户有意识作出的选择直接体现了他们更想要的搜索结果, 有了这些选择记录, 理论上可以更有针对性地改进搜索结果, 而宝贵的数据就这么到手了, 思路很好, 应该给Rich Skrenta发朵小红花. 一个不太恰当的比方, 想想整个过程在表面上有点像无监督学习向有监督学习的转化, 我更想将Blekko的做法叫做"人肉学习". 其实有时候, 无监督是迫不得已的无监督, 缺因变量的数据, 你真真儿的伤不起.

为了验证Skrenta大人是不是真的这么想的, 用Live HTTP Headers看了一下, 用户选择结果似乎的确是有跟踪的:

三种点选结果分别指向:

http://blekko.com/a/monteguess?q=R /monte &g=blekko
http://blekko.com/a/monteguess?q=R /monte &g=bing
http://blekko.com/a/monteguess?q=R /monte &g=google


打开以后一片空白, 感觉上应该是个tracker.

如果这个游戏的设计目的真是人肉学习, 那么不难让人联想到那个传说中的《最佳路径》的故事. 似乎这故事还入选了我朝某小学语文课本, 不过我用"Gropius Disney"之类的关键词Google了半天也没找到原始出处, 要么这故事是生编硬套的伪作, 要么就是我英文搜索水平太差了. 暂且不论真假, 先贴上来瞧瞧:

世界建筑大师格罗培斯设计的迪斯尼乐园，经过3年的精心施工，马上就要对外开放了，然而各景点之间的道路该怎样设计还没有具体的方案。施工部打电报给正在法国参加庆典的格罗培斯大师，请他赶快定稿。

格罗培斯从事建筑研究40多年，攻克过无数个建筑方面的难题，然而建筑学中最微不足道的一点——路径设计却让他大伤脑筋。对迪斯尼乐园各景点之间的道路安排，他已修改了50多次，没有一次是让他满意的。接到催促电报，他心里更加焦躁。巴黎的庆典一结束，他就让司机驾车带他去了地中海海滨。他想清理一下思绪，争取在回国前把方案定下来。

汽车在法国南部的乡间公路上奔驰，这儿是法国著名的葡萄产区，漫山遍野都是当地农民的葡萄园。一路上他看到许多园主把摘下来的葡萄提到路边，向过往的车辆和行人吆喝，但却很少有停下来的。

当他们的车子拐入一个小山谷时，发现那儿停着许多车辆。原来这儿是一个无人看管的葡萄园，你只要在路旁的箱子里投入5法郎就可以摘一篮葡萄上路。据说这是一位老太太的葡萄园，她因年迈无力料理而想出这个办法。起初她还担心这种办法是否能卖出葡萄，谁知在这绵延上百里的葡萄产区，总是她的葡萄最先卖完。她这种给人自由，任其选择的做法使大师深受启发，他下车摘了一篮葡萄，就让司机调转车头，立即返回了巴黎。
回到住地，他马上给施工部拍了封电报：撒下草种，提前开放。

施工部按要求在乐园撒下草种。没多久，小草长出来了，整个乐园的空地被绿草所覆盖。在迪斯尼乐园提前开放的半年里，草地被踩出许多小道，这些踩出的小道有宽有窄，优雅自然。第二年，格罗培斯让人按这些踩出的痕迹铺设了人行道。

其实我想说, 这故事简直就是技术流心灵鸡汤啊. 要真的不是伪作的话, 那Walter Gropius还真是思无邪.

这是Springer Statistics and Computing丛书中《Graphics of Large Datasets: Visualizing a Million》一书的第11章. 内容是对InfoVis 2005会议竞赛单元所提供数据集的可视化和分析. 作者之一的Martin Theus也是R的交互式图形包iPlots和R的Java GUI前端JGR的作者.

单独将这章提出来的原因是, 一般相关书籍和资料比较偏重理论, 例证比较零散, 不够系统, 往往缺乏对现实数据集完整的分析. 这样贴近现实而详尽的材料相对难得.

半年前做了一部分, 这两天放假又整理了一下就放上来了. 图形提取自原书电子版, 在内容和版式上尽力保持了原书风貌.

值得一提的是, 竞赛结果中位列1st的两队之一是来自IAState的Heike Hofmann, Hadley Wickham, Dianne Cook, Junjie Sun, Christian Röttger, 而本书的三位作者之一是Heike Hofmann. 本书也是本章的两位作者所在队位居2nd.

PDF, 3.3 MB

Prof. Michael McGuffin的热心让人感动. 当Michael问我"... You want to visualize something?"而我只能巨汗地回答"Just want to learn the basic things well ..."时, 我体会到以后还真是需要好好学一下计算几何了 .. Gary对大家都很有教益的Color Science .. 内敛的Patrignani的内敛的意式英语 .. 可爱老头Inselberg的极其无敌极其牛x闪闪的平行坐标 .. 周围低调的群牛 .. 都很值得回味. 感谢和我在同在一个group的Zhang, Wang, Chen三位同学, 你们优秀的想法给了我很多启发. 考虑到自己只是打酱油+纯路过的本质, 其他什么的就不多写了. 最后特别感谢高涛同学的友情食宿赞助.

Slides 1 - Group3: Plan(s)

Slides 2 - Final Presentation: Visualization of CRAN Package Dependency Network

最后的Name Cards偷了谢老大的创意 .. 脸红ing ..

原来暑假就要这么华丽丽的没了 ...

匹配字符串的开始(位置):  ^

匹配字符串的开始(不受处理多行选项影响):  A

匹配字符串的结束(位置):  $

匹配字符串的结束(不受处理多行选项影响):  z

匹配字符串的开始/结束(位置):  b

匹配字符串的结束/行尾(不受处理多行选项影响):  Z

匹配数字/字母/下划线/汉字:  w

匹配(阿拉伯)数字:  d

匹配空白符(空格/全角空格/制表符/换行符):  s

匹配横向制表符:  t

匹配竖向制表符:  v

匹配回车:  r

匹配换行符:  n

匹配换页符:  f

匹配任意字符(除换行符n):  .

前述表达式重复任意次:  *

2. 元字符转义 (查找元字符本身)

.  *  \  ^  $  等.

3. 字符类 (自定义的元字符):  [ ]

e.g. [13579] 匹配1或3或5或7或9中的任意一个数字.

4. 限定符 (规定表达式重复次数)

重复至少0次:  *

重复至少1次:  +

重复0次或1次:  ?

重复n次:  {n}

重复n次或更多次:  {n,}

重复m到n次:  {m,n}

e.g. d{2,9} 匹配2-9位阿拉伯数字.

5. 分枝:  |

p.s. 分枝条件按照从左到右的顺序测试. 如果已满足了某个分枝, 则匹配结束. 故使用分枝条件时, 一定要反复斟酌各个条件的书写顺序.

6. 反义

对于元字符, 把元字符里的字母小写换为大写即表示反义. 对于字符类, [^13579] 匹配除了1或3或5或7或9以外的任意字符. 一个不错的例子:

<a[^>]+> 匹配用尖括号括起来的以a开头的字符串

7. 分组:  ( )

和编程写公式时多加括号防止写错有点类似. 不过这里的现实意义强得多, 可以用来写出比较复杂的表达式.

8. 贪婪/懒惰

在正则表达式中, [最先开始的匹配] 拥有最高优先权. 其次才是默认的贪婪匹配原则. 与之对应的懒惰匹配原则:

重复0次或1次:  ??

重复至少1次:  +?

重复m到n次:  {m,n}?

重复n次以上:  {n,}?

重复任意次:  *?

9. 零宽断言

(1) 零宽度正预测先行断言:  (?=exp)

断言此位置之后能匹配表达式exp

e.g. bw+(?=lyb) 匹配以ly结尾的字符串的前面部分.

(2) 零宽度正回顾后发断言:  (?<=exp)

断言此位置之前能匹配表达式exp

e.g. (?<=bpre)w+b 匹配以pre开头的字符串的后面部分.

(3) 零宽度负预测先行断言:  (?!exp)

断言此位置之后不能匹配表达式exp

e.g. b((?!exe)w)+b 匹配不包含连续字符串exe的字符串.

(4) 零宽度负回顾后发断言:  (?<!exp)

断言此位置之前不能匹配表达式exp

e.g. (?<!010)d{8} 匹配前面不是010的8位数字.

10. 注释

(?#注释内容)

图1 2010年2月青海地区地震分布

图2 2010年3月青海地区地震分布

图3 2010年4月青海地区地震分布

童鞋们对比一下2、3月份与4月的分布概况图, 不难辨识出青海省玉树藏族自治州的位置. 4月的数据截至22日, 图中所示的经纬度范围约为: 31°-39°N, 94°-103°E. 灾难无情, 愿那些已在天堂的人们安息.

我一向很崇拜那些做可视化的人们, 至少那么多复杂的图形控制参数是难倒我了. 吾生性迟钝, 只能隐约感觉到, 可视化方法在过去, 现在和未来探索某些尚未发现深层次规律问题时, 都是一个极其重要的方法.

最近有一种说法是, 京津地区将在某某天发生破坏性地震, 据说还是某些位神人日观天象偶然看到了一种特殊的云而得出的结论, 和人教社的初中语文课文中所谓的“看云识天气”颇有几分相似. 我们暂且不说这种说法的来源有多不靠谱, 首先, 且看这种说法的一个重要论据是, 有xx次国内外的破坏性地震之前, 天空中都出现了特殊形状的云. 但是, 这样的论据显然是文不对题的. 实际上, 正确的论据应该指出, 在多少出现了这种云的情况下发生了破坏性地震. 以贝叶斯的观点看, 这两个概率没有确定的关系, 也无法相互替代. 其次, 在我看来, 这种提法在统计中最多只能算是一种假设，即使经过严格的检验, 也不能断定其成立. 而且, 这个假设描述非常模糊, 以致几乎无法加以有效的检验. 再次, 有些人说, 出现了某种云, 导致发生了地震, 实际上是提出了一个因果模型: 出现某某云 → 发生地震. 对初等的数理统计知识有所了解以后, 我们就会知道, 用统计方法建立一个因果模型是一件多么困难的事情, 何况是这种要数据没有, 样本量更小到可以忽略的情况. 我的概率论学得不好, 数理统计也还没入门, 多说无益, 就不再斗胆细究了. 不过, 我所知道的一个情况是, “预言”这件事情其实有点像押宝, 言中了算运气好, 就算没言中, 也只是被人逐渐淡忘而已. 但从道德角度讲, 对于一些缺乏独立思考能力和精神的人来说, 这大抵可以算得上是一种伤害. 关于这类问题一个有趣的例子, 可以参考[3]中对青少年问题的探讨.

扩展阅读

[1] 从实例看RgoogleMaps包的使用

[2] 《最近一周中国及周边版图地震情况》之卫星地图版与动画实现

[3] 王小波. 摆脱童稚状态. 读书, 1993, 6.