Code

译自:ParsCit: An open-source CRF reference string parsing package (部分)

0 摘要

我们这样描述ParsCit:一个自由，开源的参考文献解析包。ParsCit的核心是一个被训练完成的CRF模型，它被用来标记参考文献字符串的序列。这个启发式的模型对一个纯文本文件进行分割和识别。这个包可以直接运行，或者作为一个web服务器使用。

我们用3个不同的数据集来比较ParsCit，并用它和之前已出版的作品比较。

crf++ 是一个开源工具,是自然语言处理的一把利器。它可以编译为 crf_learn 和 crf_test 两个 bin 文件。测试的结果是将预测的结果和真实的结果进行比对。可惜这东西比对完也不给个统计，真教人不爽。 幸亏，有人做了个 perl 工具 conlleval 可以用来分析测试结果。

和 @Leniy 说到利用 git 自动部署的事情, @Leniy 问了句, 怎么配, 既然有人有兴趣, 我就扯几句.

git 无疑是一个很赞的版本管理系统, 简单易用不伤手. 而如果在 VPS 上部署一个 git, 每次提交后, 直接部署到环境中, 不用 ssh 登进去顶着 XXXms 的延迟穷倒腾. 说明一下, 我只是举个栗子, 实现了"自动部署"的要求, 看官可以做的远不止这些.

前些日子,有人网上说解决了什么最难数独什么的，然后下面一片欢呼 -- 我看了下所谓题目，无非一个普通的9*9的小题目而已，机器完全可以轻松遍历。 感觉很不可思议 -- 在这种信息时代，计算机能轻松遍历的东西，就不算什么难题，让人闲暇时候玩玩就算了，拿来当作学术成就什么来炫耀，实在有些。。。坐什么观什么了。

某个C文件又添加一个新的头文件，rebuild这个工程，结果此C文件报错。

src/xxxx.c: In function ‘foo’:
src/xxxx.c:27:1: error: parameter ‘some_pp’ is initialized
src/xxxx.c:27:1: warning: initialization from incompatible pointer type [enabled by default]

sqlite 关于 string 类型的数据需要转义。

通过查找规则，可以很容易通过switch拼装一个字符串来搞定。 大致规则是，单引号和双引号要变成两个，其他特殊字符为前面加上'/'。

sqlite3使用sqlite3_exec，原型如下：

int sqlite3_exec(
	sqlite3*,                                  /* An open database */
	const char *sql,                           /* SQL to be evaluated */
	int (*callback)(void*,int,char**,char**),  /* Callback function */
	void *,                                    /* 1st argument to callback */
	char **errmsg                              /* Error msg written here */
);

其中有个参数是callback类型的。查询到的数据放在callback中处理。

这东西可以通过修改 theme 的 comment.php (路径: Appearance->Editor->Comments(或者其他类似的))来达到目标。

基本原理是这篇文字的内容。

问题是，现在 WP 的评论框非常之省事:

linux下编辑文件，常用的有vi/vim,emacs,还有gedit -- 当然,还有谁有其他各种喜好。 emacs,vi什么的自然是控制台下搞，干干净净。 但是到了gedit的时候，因为是X display ,所以控制台方面就各种肆无忌惮的放warning。

因为是写代码么，所以常常是shell跑到某个位置，然后vi/emacs/gedit一个命令打开文件，开始编辑。

前几天，对blog的一番网址抒发胸臆，结果造成google大面积404，更重要的是，我自己的书签挂了好几个。不爽。 所以修改.htaccess文件，利用apache服务器的特性进行重定向。

为了网上传输数据，所以数据最好被拆为单位为1byte大小的数组串(unsigned char 类型恰好是这个大小)，然后再进行传输，这样才能不会出现自己无法控制的情况(断网谁都控制不了了当然)。 此外，需要约定好字节序 -- 比如本日志使用的是大端(big endian)，以及编码。这样拆解和重组才不会错乱。

常常使用到各种术语什么的，一个一个解释，其实也就是copy Wikipedia词条上的东西,费时费力不讨好，还不如直接挂个链接完事,但是每次添加链接都是个悲剧的事情,各种数据添加的人都要疯掉了。

现在有两个字符串，我们怎样衡量它们之间的"相似度"呢？比如naxt和exnt哪个和next更加相似呢？这就需要一个统一的衡量准则了。

为了做一个统一的衡量准则，有人提出了编辑距离(Edit distance or Levenshtein distance)这个概念。