Dedication

【转载】使用 Elasticsearch 做一个好用的日语搜索引擎及自动补全

Fri, 29 Dec 2023 00:00:00 GMT

【编者按】此文转载自 https://avnpc.com/。由于原网站链接已经失效，但此文内容非常有价值，故本博客对此文及其相关链接全文转载。本文著作权由 AlloVince 所有。

最近基于 Elastic Stack 搭建了一个日语搜索服务，发现日文的搜索相比英语和中文，有不少特殊之处，因此记录下用 Elasticsearch 搭建日语搜索引擎的一些要点。本文所有的示例，适用于 Elastic 6.X 及 7.X 版本。

日语搜索的特殊性

以 Elastic 的介绍语「Elasticsearchは、予期した結果や、そうでないものも検索できるようにデータを集めて格納するElastic Stackのコア製品です」为例。作为搜索引擎，当然希望用户能通过句子中的所有主要关键词，都能搜索到这条结果。

和英文一样，日语的动词根据时态语境等，有多种变化。如例句中的「集めて」表示现在进行时，属于动词的连用形的て形，其终止形（可以理解为动词的原型）是「集める」。一个日文动词可以有 10 余种活用变形。如果依赖单纯的分词，用户在搜索「集める」时将无法匹配到这个句子。

除动词外，日语的形容词也存在变形，如终止形「安い」可以有连用形「安く」、未然性「安かろ」、仮定形「安けれ」等多种变化。

和中文一样，日文中存在多音词，特别是人名、地名等，如「相楽」在做人名和地名时就有 Sagara、Soraku、Saganaka 等不同的发音。

同时日文中一个词还存在不同的拼写方式，如「空缶」 = 「空き缶」。

而作为搜索引擎，输入补全也是很重要的一个环节。从日语输入法来看，用户搜索时输入的形式也是多种多样，存在以下的可能性：

平假名，如「検索 -> けんさく」
片假名全角，如「検索 -> ケンサク」
片假名半角，如「検索 -> ｹﾝｻｸ」
汉字，如「検索」
罗马字全角，如「検索 -> ｋｅｎｎｓａｋｕ」
罗马字半角，如「検索 -> kennsaku」

等等。这和中文拼音有点类似，在用户搜索结果或者做输入补全时，我们也希望能尽可能适应用户的输入习惯，提升用户体验。

Elasticsearch 文本索引的过程

Elasticsearch （下文简称 ES）作为一个比较成熟的搜索引擎，对上述这些问题，都有了一些解决方法

先复习一下 ES 的文本在进行索引时将经历哪些过程，将一个文本存入一个字段 (Field) 时，可以指定唯一的分析器（Analyzer），Analyzer 的作用就是将源文本通过过滤、变形、分词等方式，转换为 ES 可以搜索的词元（Term），从而建立索引，即：

graph LR Text --> Analyzer Analyzer --> Term

一个 Analyzer 内部，又由 3 部分构成

enter image description here

字符过滤器 (Character Filter): ，对文本进行字符过滤处理，如处理文本中的 html 标签字符。一个 Analyzer 中可包含 0 个或多个字符过滤器，多个按配置顺序依次进行处理。
分词器 (Tokenizer): 对文本进行分词。一个 Analyzer 必需且只可包含一个 Tokenizer。
词元过滤器 (Token filter): 对 Tokenizer 分出的词进行过滤处理。如转小写、停用词处理、同义词处理等。一个 Analyzer 可包含 0 个或多个词项过滤器，多个按配置顺序进行过滤。

引用一张图说明应该更加形象

ES 已经内置了一些 Analyzers，但显然对于日文搜索这种较复杂的场景，一般需要根据需求创建自定义的 Analyzer。

另外 ES 还有归一化处理器 (Normalizers)的概念，可以将其理解为一个可以复用的 Analyzers, 比如我们的数据都是来源于英文网页，网页中的 html 字符，特殊字符的替换等等处理都是基本相同的，为了避免将这些通用的处理在每个 Analyzer 中都定义一遍，可以将其单独整理为一个 Normalizer。

快速测试 Analyzer

为了实现好的搜索效果，无疑会通过多种方式调整 Analyzer 的配置，为了更有效率，应该优先掌握快速测试 Analyzer 的方法，这部分内容详见如何快速测试 Elasticsearch 的 Analyzer，此处不再赘述。

Elasticsearch 日语分词器 (Tokenizer) 的比较与选择

日语分词是一个比较大的话题，因此单独开了一篇文章介绍和比较主流的开源日语分词项目。引用一下最终的结论

	算法/模型	实现语言	词典	处理速度	ES 插件	Lisence
MeCab	CRF	C++	可选	最高	有	GPL/LGPL/BSD
Kuromoji	Viterbi	Java	可选, 默认 ipadic	中	内置	Apache License v2.0
Juman++	RNNLM	C++	自制	高	无	Apache License v2.0
KyTea	SVM 等	C++	UniDic	中	有	Apache License v2.0
Sudachi	Lattice LSTM	Java	UniDic + NEologd	中	有	Apache License v2.0
nagisa	Bi-LSTM	Python	ipadic	低	无	MIT

对于 Elasticsearch，如果是项目初期，由于缺少数据，对于搜索结果优化还没有明确的目标，建议直接使用 Kuromoji 或者 Sudachi，安装方便，功能也比较齐全。项目中后期，考虑到分词质量和效率的优化，可以更换为 MeCab 或 Juman++。本文将以 Kuromoji 为例。

日语搜索相关的 Token Filter

在 Tokenizer 已经确定的基础上，日语搜索其他的优化都依靠 Token filter 来完成，这其中包括 ES 内置的 Token filter 以及 Kuromoji 附带的 Token filter，以下逐一介绍

Lowercase Token Filter (小写过滤)

将英文转为小写，几乎任何大部分搜索的通用设置

POST _analyze
{
  "tokenizer": "kuromoji_tokenizer",
  "filter": ["lowercase"],
  "text": "Ironman"
}

Response
{
  "tokens": [
    {
      "token": "ironman",
      "start_offset": 0,
      "end_offset": 7,
      "type": "word",
      "position": 0
    }
  ]
}

CJK Width Token Filter (CJK 宽度过滤)

将全角 ASCII 字符转换为半角 ASCII 字符

POST _analyze
{
  "tokenizer": "kuromoji_tokenizer",
  "filter": ["cjk_width"],
  "text": "ｋｅｎｎｓａｋｕ"
}

{
  "tokens": [
    {
      "token": "kennsaku",
      "start_offset": 0,
      "end_offset": 8,
      "type": "word",
      "position": 0
    }
  ]
}

以及将半角片假名转换为全角

POST _analyze
{
  "tokenizer": "kuromoji_tokenizer",
  "filter": ["cjk_width"],
  "text": "ｹﾝｻｸ"
}

{
  "tokens": [
    {
      "token": "ケンサク",
      "start_offset": 0,
      "end_offset": 4,
      "type": "word",
      "position": 0
    }
  ]
}

`ja_stop` Token Filter (日语停止词过滤)

一般来讲，日语的停止词主要包括部分助词、助动词、连接词及标点符号等，Kuromoji 默认使用的停止词参考lucene 日语停止词源码。在此基础上也可以自己在配置中添加停止词

POST _analyze
{
  "tokenizer": "kuromoji_tokenizer",
  "filter": ["ja_stop"],
  "text": "Kuromojiのストップワード"
}

{
  "tokens": [
    {
      "token": "Kuromoji",
      "start_offset": 0,
      "end_offset": 8,
      "type": "word",
      "position": 0
    },
    {
      "token": "ストップ",
      "start_offset": 9,
      "end_offset": 13,
      "type": "word",
      "position": 2
    },
    {
      "token": "ワード",
      "start_offset": 13,
      "end_offset": 16,
      "type": "word",
      "position": 3
    }
  ]
}

`kuromoji_baseform` Token Filter (日语词根过滤)

将动词、形容词转换为该词的词根

POST _analyze
{
  "tokenizer": "kuromoji_tokenizer",
  "filter": ["kuromoji_baseform"],
  "text": "飲み"
}

{
  "tokens": [
    {
      "token": "飲む",
      "start_offset": 0,
      "end_offset": 2,
      "type": "word",
      "position": 0
    }
  ]
}

`kuromoji_readingform` Token Filter (日语读音过滤)

将单词转换为发音，发音可以是片假名或罗马字 2 种形式

POST _analyze
{
  "tokenizer": "kuromoji_tokenizer",
  "filter": ["kuromoji_readingform"],
  "text": "寿司"
}

{
  "tokens": [
    {
      "token": "スシ",
      "start_offset": 0,
      "end_offset": 2,
      "type": "word",
      "position": 0
    }
  ]
}

POST _analyze
{
  "tokenizer": "kuromoji_tokenizer",
  "filter": [{
     "type": "kuromoji_readingform", "use_romaji": true
   }],
  "text": "寿司"
}

{
  "tokens": [
    {
      "token": "sushi",
      "start_offset": 0,
      "end_offset": 2,
      "type": "word",
      "position": 0
    }
  ]
}

当遇到多音词时，读音过滤仅会给出一个读音。

`kuromoji_part_of_speech` Token Filter (日语语气词过滤)

语气词过滤与停止词过滤有一定重合之处，语气词过滤范围更广。停止词过滤的对象是固定的词语列表，停止词过滤则是根据词性过滤的，具体过滤的对象参考源代码。

POST _analyze
{
  "tokenizer": "kuromoji_tokenizer",
  "filter": ["kuromoji_part_of_speech"],
  "text": "寿司がおいしいね"
}

{
  "tokens": [
    {
      "token": "寿司",
      "start_offset": 0,
      "end_offset": 2,
      "type": "word",
      "position": 0
    },
    {
      "token": "おいしい",
      "start_offset": 3,
      "end_offset": 7,
      "type": "word",
      "position": 2
    }
  ]
}

`kuromoji_stemmer` Token Filter (日语长音过滤)

去除一些单词末尾的长音，如「コンピューター」 => 「コンピュータ」

POST _analyze
{
  "tokenizer": "kuromoji_tokenizer",
  "filter": ["kuromoji_stemmer"],
  "text": "コンピューター"
}

{
  "tokens": [
    {
      "token": "コンピュータ",
      "start_offset": 0,
      "end_offset": 7,
      "type": "word",
      "position": 0
    }
  ]
}

`kuromoji_number` Token Filter (日语数字过滤)

将汉字的数字转换为 ASCII 数字

POST _analyze
{
  "tokenizer": "kuromoji_tokenizer",
  "filter": ["kuromoji_number"],
  "text": "一〇〇〇"
}

{
  "tokens": [
    {
      "token": "1000",
      "start_offset": 0,
      "end_offset": 4,
      "type": "word",
      "position": 0
    }
  ]
}

日语全文检索 Analyzer 配置

基于上述这些组件，不难得出一个完整的日语全文检索 Analyzer 配置

PUT my_index
{
  "settings": {
    "analysis": {
      "analyzer": {
        "ja_fulltext_analyzer": {
          "type": "custom",
          "tokenizer": "kuromoji_tokenizer",
          "filter": [
            "cjk_width",
            "lowercase",
            "kuromoji_stemmer",
            "ja_stop",
            "kuromoji_part_of_speech",
            "kuromoji_baseform"
          ]
        }
      }
    }
  },
  "mappings": {
    "my_type": {
      "properties": {
        "title": {
          "type": "text",
          "analyzer": "ja_fulltext_analyzer"
        }
      }
    }
  }
}

其实这也正是 kuromoji analyzer 所使用的配置，因此上面等价于

PUT my_index
{
  "mappings": {
    "my_type": {
      "properties": {
        "title": {
          "type": "text",
          "analyzer": "kuromoji"
        }
      }
    }
  }
}

这样的默认设置已经可以应对一般情况，采用默认设置的主要问题是词典未经打磨，一些新词语或者专业领域的分词不准确，如「東京スカイツリー」期待的分词结果是「東京/スカイツリー」，实际分词结果是「東京/スカイ/ツリー」。进而导致一些搜索排名不够理想。这个问题可以将词典切换到 UniDic + NEologd，能更多覆盖新词及网络用语，从而得到一些改善。同时也需要根据用户搜索，不断维护自己的词典。而自定义词典，也能解决一词多拼以及多音词的问题。

至于本文开始提到的假名读音匹配问题，很容易想到加入 kuromoji_readingform，这样索引最终存储的 Term 都是假名形式，确实可以解决假名输入的问题，但是这又会引发新的问题：

一方面，kuromoji_readingform 所转换的假名读音并不一定准确，特别是遇到一些不常见的拼写，比如「明るい」-> 「アカルイ」正确，「明るい」的送りがな拼写「明かるい」就会转换为错误的「メイ・カルイ」

另一方面，日文中相同的假名对应不同汉字也是极为常见，如「シアワセ」可以写作「幸せ」、「仕合わせ」等。

因此kuromoji_readingform并不适用于大多数场景，在输入补全，以及已知读音的人名、地名等搜索时，可以酌情加入。

日语自动补全的实现

Elasticsearch 的补全(Suggester)有 4 种：Term Suggester 和 Phrase Suggester 是根据输入查找形似的词或词组，主要用于输入纠错，常见的场景是”你是不是要找 XXX”；Context Suggester 个人理解一般用于对自动补全加上其他字段的限定条件，相当于 query 中的 filter；因此这里着重介绍最常用的 Completion Suggester。

Completion Suggester 需要响应每一个字符的输入，对性能要求非常高，因此 ES 为此使用了新的数据结构：完全装载到内存的 FST(In Memory FST)，类型为 completion。众所周知，ES 的数据类型主要采用的是倒排索引(Inverse Index)，但由于 Term 数据量非常大，又引入了 term dictionary 和 term index，因此一个搜索请求会经过以下的流程。

graph LR TI[Term Index] TD[Term Dictionary] PL[Posting List] Query --> TI TI --> TD TD --> Term Term --> PL PL --> Documents

completion 则省略了 term dictionary 和 term index，也不需要从多个 nodes 合并结果，仅适用内存就能完成计算，因此性能非常高。但由于仅使用了 FST 一种数据结构，只能实现前缀搜索。

了解了这些背景知识，来考虑一下如何构建日语的自动补全。

和全文检索不同，在自动补全中，对读音和罗马字的匹配有非常强的需求，比如用户在输入「銀魂」。按照用户的输入顺序，实际产生的字符应当是

gin
ぎん
銀
銀 t
銀 tama
銀魂

理想状况应当让上述的所有输入都能匹配到「銀魂」，那么如何实现这样一个自动补全呢。常见的方法是针对汉字、假名、罗马字各准备一个字段，在输入时同时对 3 个字段做自动补全，然后再合并补全的结果。

来看一个实际的例子，下面建立的索引中，创建了 2 种 Token Filter，kuromoji_readingform可以将文本转换为片假名，romaji_readingform则可以将文本转换为罗马字，将其与kuromoji Analyzer 组合，就得到了对应的自定义 Analyzer ja_reading_analyzer 和 ja_romaji_analyzer 。

对于 title 字段，分别用不同的 Analyzer 进行索引：

title: text 类型，使用 kuromoji Analyzer，用于普通关键词搜索
title.suggestion: completion 类型，使用 kuromoji Analyzer，用于带汉字的自动补全
title.reading: completion 类型，使用 ja_reading_analyzer Analyzer，用于假名的自动补全
title.romaji: completion 类型，使用 ja_romaji_analyzer Analyzer，用于罗马字的自动补全

PUT my_index
{
  "settings": {
    "analysis": {
      "filter": {
        "katakana_readingform": {
          "type": "kuromoji_readingform",
          "use_romaji": "false"
        },
        "romaji_readingform": {
          "type": "kuromoji_readingform",
          "use_romaji": "true"
        }
      },
      "analyzer": {
        "ja_reading_analyzer": {
          "type": "custom",
          "filter": [
            "cjk_width",
            "lowercase",
            "kuromoji_stemmer",
            "ja_stop",
            "kuromoji_part_of_speech",
            "kuromoji_baseform",
            "katakana_readingform"
          ],
          "tokenizer": "kuromoji_tokenizer"
        },
        "ja_romaji_analyzer": {
          "type": "custom",
          "filter": [
            "cjk_width",
            "lowercase",
            "kuromoji_stemmer",
            "ja_stop",
            "kuromoji_part_of_speech",
            "kuromoji_baseform",
            "romaji_readingform"
          ],
          "tokenizer": "kuromoji_tokenizer"
        }
      }
    }
  },
  "mappings": {
    "my_type": {
      "properties": {
        "title": {
          "type": "text",
          "analyzer": "kuromoji",
          "fields": {
            "reading": {
              "type": "completion",
              "analyzer": "ja_reading_analyzer",
              "preserve_separators": false,
              "preserve_position_increments": false,
              "max_input_length": 20
            },
            "romaji": {
              "type": "completion",
              "analyzer": "ja_romaji_analyzer",
              "preserve_separators": false,
              "preserve_position_increments": false,
              "max_input_length": 20
            },
            "suggestion": {
              "type": "completion",
              "analyzer": "kuromoji",
              "preserve_separators": false,
              "preserve_position_increments": false,
              "max_input_length": 20
            }
          }
        }
      }
    }
  }
}

插入示例数据

POST _bulk
{ "index": { "_index": "my_index", "_type": "my_type", "_id": 1} }
{ "title": "銀魂" }

然后运行自动补全的查询

GET my_index/_search
{
    "suggest": {
    "title": {
      "prefix": "gin",
      "completion": {
        "field": "title.suggestion",
        "size": 20
      }
    },
    "titleReading": {
      "prefix": "gin",
      "completion": {
        "field": "title.reading",
        "size": 20
      }
    },
    "titleRomaji": {
      "prefix": "gin",
      "completion": {
        "field": "title.romaji",
        "size": 20
      }
    }
  }
}

可以看到不同输入的命中情况

gin: 命中 title.romaji
ぎん: 命中 title.reading 和 title.romaji
銀: 命中 title.suggestion, title.reading 和 title.romaji
銀 t: 命中 title.romaji
銀たま: 命中 title.reading 和 title.romaji
銀魂: 命中 title.suggestion, title.reading 和 title.romaji

References

【转载】日语分词器的介绍与比较

Fri, 29 Dec 2023 00:00:00 GMT

对于搜索引擎来说，分词器的质量是对搜索结果影响最大的一个环节，日语分词（形態素解析）经过多年的发展也有了一些比较成熟的分词系统，下面介绍并比较目前主流的开源日语分词系统。

日语分词词典

在介绍分词器之前，有必要先介绍词典，因为词典是分词的基础，词典的质量直接决定了分词器的质量，而分词系统内部采用哪个词典，也是对分词器效果评估的重要参考。

说到日文词典，可能首先想到是知名的商业词典，如「広辞苑」、「大辞林」等，然而由于商业词典等存在版权和授权问题，一般都无法用于开源项目。其次这类商业词典一般以词义解释为主，而对于分词来说，词汇的释义并不是最重要的，而是词性、词根等，所以也并不是所有的商业词典都适用于分词。

因此开源项目一般都采用具备开源许可证的免费词典，目前使用比较多的有：

UniDic: 由国立国语研究所推出，主要用于分词问题研究的词典，质量非常优秀，并且按照现代、近代、古代，书面语、口语等划分了多个专门词典，License 也有 GPL/LGPL/BSD 多个选择，可以说是日语分词研究的首选词典了。
ipadic: 这个词典首先是由「奈良先端科学技術大学院大学松本研究室」所开发的分词软件 ChaSen 整理并使用的，词汇的来源是「情報処理振興事業協会(IPA)」所编著的「IPA 品詞体系(THiMCO97)」，由于 ChaSen 这个软件已经停止更新，因此这个词典的最后一个版本也停止在 2.7.0，更新时间是 2007 年。从应用角度来看 ipadic 并不适合使用在实际产品中，但是胜在体积小巧，适合用于个人学习或 demo，总词条数约 14W 条。
NAIST-jdic : 由于 ipadic 停止更新，NAIST-jdic 就是在 ipadic 继续整理并将词条数增补至 30W，许可证 BSD。最后更新时间为 2008 年。
mecab-ipadic / mecab-jumandic 由知名项目 MeCab (下文详细介绍) 按照自己项目的格式整理而成的词典
mecab-ipadic-NEologd 由工程师 @overlast 个人维护的项目，并得到的 LINE 公司的赞助，主要在 mecab-ipadic 的基础上增补了很多互联网的新词

可以通过这个网页比较几个日语分词词典的差异。

在对日语分词词典有了一定了解后，下面逐一介绍日语分词器

MeCab

MeCab 是京都大学信息专业和日本电信电话株式会社通讯研究所共同研究的项目，模型基于 CRF(条件随机场) ，基于 C++实现，主要作者是「工藤拓」，是日本自然语言研究领域大拿，就职于 Google 负责日语输入法相关项目。

MeCab 主要特点有：

不依赖特定词典，因此其他语言如中文、韩语也可以使用
性能较好
多语言接口
整理了若干好用的词典

MeCab 无论在学术方面，还是工程方面，都是非常优秀的，可以看到其他很多日语分词相关的项目，或多或少都受到了 MeCab 的影响或使用了 MeCab 的算法、词典等。

Kuromoji

Kuromoji 由位于东京的 Atilika 公司开发，基于 Java 实现。目前已经捐赠给了 Apache 软件基金会，并内置在 Lucene 和 Solr 中作为默认的日文分词器。

Kuromoji 基本支持前文提到的所有词典，如果未指定的话，默认使用 ipadic。

Kuromoji 的分词算法基于 Viterbi Algorithm，因此可以看做是基于 HMM (隐马尔科夫模型) 的分词。

由于 Atilika 是一个纯商业公司，因此 Kuromoji 也更偏向作为日语分词的工程实现，作为 Java 开源项目，与主流的 Java 搜索项目如 Lucene，Elastic 有很好的匹配，工程方面比较规范，容易上手。而在学术方面的贡献就比较少了。

Juman++

Juman 和 Juman++ 都是京都大学信息专业在 NLP 方面的研究成果，分词模型使用了 RNNLM（递归神经网络语言模型），即采用了深度学习技术。开发采用 C++ 实现，Github 页面也给出了已经训练好的模型。

Juman 除了采用自己整理的词典外，还引入了来自 Wikipedia 的词汇。 Juman 的输出除了标准的分词结果外，还可以输出词汇的分类，从而可以对句子做更好的标签和归类。

不过由于文档较少，想要使用 Juman 训练自己的模型或者更换自己的词典还是比较困难的，整体是一个比较偏学术的项目。

KyTea

KyTea 是由卡内基·梅隆大学的 Graham Neubig 主导研究的项目，实现语言是 C++，算法方面融合了 SVM 和逻辑回归等多个模型，默认使用的词典是 UniDic。

作者的方向偏学术，因此 KyTea 更多也只是作为研究成果的展示，版本早已停止更新，实际应用的项目也较少。

Sudachi

Sudachi 由 Works Applications 公司开发，和 Kuromoji 非常类似，都是 Java 实现的商业开源项目，对比 Kuromoji， Sudachi 可以调整的参数更细致一些，默认词典同时包括了 UniDic 和 NEologd，算法使用的应该是 Lattice LSTM。

项目开源仅 2 年，更新维护比较勤快，官方提供了 Elasticsearch 插件，对开发者比较友好。

nagisa

nagisa 是 NTT DOCOMO 的「池田大志」个人开发的基于 RNN 的项目，训练好的模型可以直接使用 pip 安装后使用，不过由于是 Python 开发，运行效率上就远远比不了上述的 C++项目了。

nagisa 整体代码较少，并给出了完整的训练代码和语料库，如果是以学习日语 NLP 为目的的话，是一个不错的选择。

其他

janome 纯 Python 实现的 Lattice LSTM

日语分词器的横向比较

将以上所有介绍的日语分词器做一个横向比较，可以根据实际需要自行选择。

| | 算法/模型 | 实现语言 | 词典 | 处理速度 | ES 插件 | Lisence |
|—|—|—|—|—|—|—|—|
| MeCab | CRF | C++ | 可选 | 最高 | 有 | GPL/LGPL/BSD |
| Kuromoji | Viterbi | Java | 可选, 默认 ipadic | 中 | 内置 | Apache License v2.0 | | Juman++ | RNNLM | C++ | 自制 | 高 | 无 | Apache License v2.0 | | KyTea | SVM 等 | C++ | UniDic | 中 | 有 | Apache License v2.0 | | Sudachi | Lattice LSTM | Java | UniDic + NEologd | 中 | 有 | Apache License v2.0 | | nagisa | Bi-LSTM | Python | ipadic | 低 | 无 | MIT |

References

【转载】如何快速测试 Elasticsearch 的 Analyzer

Fri, 29 Dec 2023 00:00:00 GMT

使用 Elasticsearch 搭建搜索引擎的过程中，免不了会反复测试 Analyzer 的效果，如果每次都建立一个索引，配置索引的 Analyzer，插入 Document，无疑效率会很低。ES 提供了 _analyze 接口，可以无需创建索引快速测试 Analyzer，推荐搭配 Kibana 中的 Dev Tools 一同使用。

测试 Tokenizer

POST _analyze
{
  "tokenizer": "icu_tokenizer",
  "text":      "你好世界"
}

Response

{
  "tokens" : [
    {
      "token" : "你好",
      "start_offset" : 0,
      "end_offset" : 2,
      "type" : "<IDEOGRAPHIC>",
      "position" : 0
    },
    {
      "token" : "世界",
      "start_offset" : 2,
      "end_offset" : 4,
      "type" : "<IDEOGRAPHIC>",
      "position" : 1
    }
  ]
}

测试 Character Filter

由于 Analyzer 必须指定一个 Tokenizer，因此可以使用Keyword这个特殊的 Tokenizer, 即不做任何分词，从而可以看到 Character Filter 的效果。

POST _analyze
{
  "char_filter": [ "html_strip" ],
  "tokenizer": "keyword",
  "text":      "<p>Hello <b>World</b>!</p>"
}

Response

{
  "tokens" : [
    {
      "token" : """

Hello World!

""",
      "start_offset" : 0,
      "end_offset" : 26,
      "type" : "word",
      "position" : 0
    }
  ]
}

测试 Token filter

POST _analyze
{
  "tokenizer": "icu_tokenizer",
  "filter": [{
    "type": "stop", "stopwords": ["am"]
  }],
  "text": "I am ironman"
}

Response

{
  "tokens" : [
    {
      "token" : "I",
      "start_offset" : 0,
      "end_offset" : 1,
      "type" : "<ALPHANUM>",
      "position" : 0
    },
    {
      "token" : "ironman",
      "start_offset" : 5,
      "end_offset" : 12,
      "type" : "<ALPHANUM>",
      "position" : 2
    }
  ]
}

测试已经创建的索引

而对于已经创建的索引，可以通过 ${index}/_analyze 接口来调用某个已经创建好的 Analyzer，或者预览某个 Field 对于文本的分析结果。如创建如下索引

PUT my_index
{
  "settings": {
    "analysis": {
      "analyzer": {
        "my_analyzer": {
          "char_filter": [
            "html_strip"
          ],
          "tokenizer": "icu_tokenizer",
          "filter": [
            "my_stop_filter"
          ]
        }
      },
      "filter": {
        "my_stop_filter": {
          "type": "stop",
          "stopwords": [
            "am"
          ]
        }
      }
    }
  },
  "mappings": {
    "my_type": {
      "properties": {
        "title": {
          "type": "text",
          "analyzer": "my_analyzer"
        }
      }
    }
  }
}

调用这个索引中已经创建的 Analyzer my_analyzer

POST my_index/_analyze
{
  "analyzer": "my_analyzer",
  "text": "<p>I am <b>Ironman</b>!</p>"
}

或者预览 title 字段的分析结果

POST my_index/_analyze
{
  "field": "title",
  "text": "<p>I am <b>Ironman</b>!</p>"
}

而对于已经索引的数据，可以通过

GET /${index}/${type}/${id}/_termvectors?fields=${fields_name}

来查看实际存储的数据，如

POST _bulk
{ "index": { "_index": "my_index", "_type": "my_type", "_id": 1} }
{ "title": "<p>I am <b>Ironman</b>!</p>" }

GET my_index/my_type/1/_termvectors?fields=title
{
  "_index": "my_index",
  "_type": "my_type",
  "_id": "1",
  "_version": 1,
  "found": true,
  "took": 2,
  "term_vectors": {
    "title": {
      "field_statistics": {
        "sum_doc_freq": 2,
        "doc_count": 1,
        "sum_ttf": 2
      },
      "terms": {
        "I": {
          "term_freq": 1,
          "tokens": [
            {
              "position": 0,
              "start_offset": 3,
              "end_offset": 4
            }
          ]
        },
        "Ironman": {
          "term_freq": 1,
          "tokens": [
            {
              "position": 2,
              "start_offset": 11,
              "end_offset": 22
            }
          ]
        }
      }
    }
  }
}

下一代 Bangumi Research 架构设计

Mon, 11 Oct 2021 00:00:00 GMT

Bangumi Research，即众所周知的 https://ranking.ikely.me，是一个展示 Bangumi 动画科学排名的网站。然而仅仅展示科学排名并不能充分填充这个 title 的 scope。事实上，我们希望它能做更多的事情，但是既有的网站架构限制了它唯一能做的事情就是展示科学排名。如果你查看过它的代码，你会发现它所做的事情仅限于从一个 Azure FileShare 里面定时读取最新的排名，如果发现排名更新了它就下载它并替换已有的排名。如果我想要做更多复杂的东西，比如说点开每个番组并查看它的 details，我是不是还得让它再读取一个文件？所以你可以看到这个网站的运作逻辑是非常简单的。

那么我希望 Bangumi Research 是一个什么样的网站？在我的理想中，它应该：

展示科学排名
展示每个番组的详细资料并包括一些有趣的数据（which requires extra data mining
使用 tag 系统把每个番组连接起来
……

但是目前为止，我还没有把 Bangumi Research 设计成一个可以登陆的客户端的打算。

经过若干周末的努力，下一代 Bangumi Research https://chii.ai 渐成雏形。chii.ai 来源于 Bangumi 的域名 chii.in。以下是这个新的网站的工程设计：

后端设计

用户访问 Bangumi Research 并不会发生写操作，而且用户最主要的目的就是访问我们的科学排名。除此之外，用户还可能会查看番组的详细信息，以及进行 tag 搜索。我不需要关心查看番组信息的 API，因为可以直接复用 Bangumi API。我主要关注以下三个 API 的设计（这只是概念上的展示，实际实现有所不同）：

/api/rank

这个API 应该返回一个数组，其数据结构为
```
[{
  int id;
  DateTime date;
  string name;
  string nameCN;
  int rank; // Bangumi原排名
  int sciRank; // 科学排名
  string type;
  int votenum; // 评分人数
  int favnum; // 收藏人数
  List<Tag> tags;
}]
```
这个就包含了番组一些基本信息以及连带的 tags。这么设计 API 纯粹就是 Bangumi API 没有返回番组 tags，所以我需要自己设计系统返回 tags。

Tag 的数据结构为：
```
{
  string Tag;
  int TagCount;
  int UserCount;
  double Confidence;
}
```
其中 TagCount是该番组被标注为该标签的次数，UserCount是所有参与用标签标注该番组的人数。Confidence是一个事先用某种机器学习算法算出来的值，它表示该标签隶属于该番组的确信度。用户实际在查看番组下的标签的时候，这个字段会用于隐藏某些标签。

/api/tags

这个 API 返回所有已有的 tags。其数据结构为：

[{
  string Tag;
  int Coverage; // 该标签被标注到的番组个数
}]

/api/relatedtags

这个 API 返回所有与被搜索标签有关的 tags。其数据结构同上。
/api/searchbytags

这个 API 返回所有与标签相关联的条目。其数据结构不再赘述。

那么我们需要数据库支持这样的操作。理论上两张表：Subject 表和 Tag 表。Subject 表存储所有番组条目信息，以番组 id 为主键。Tag 表存储标签信息。咋一看标签与条目属于多对多的关系，但是在上面的 API 设计中每个标签在不同的番组中有不同的 Confidence，这就使得我们要把标签与条目设计成多对一的关系：在 Tag 表中，每个标签由其标签内容和关联条目唯一确定。另外，Subject 表应该存放科学排名。但是在 Bangumi Spider 中科学排名被生成为一个单独的文件，为了兼容这种历史遗留问题我们就把科学排名也作为一张表，以一对一的关系与 Subject 表以外键连接。

chii.ai 继续沿用 ASP .Net Core 开发后端。有 Linq 和 EntityFramework 的技术支持使得开发体验良好。该 web server 提供若干 restful API 接口。

为了接入 Bangumi API，我另外使用了一个 node 服务把数据库 API 与 Bangumi API 整合成一个 unified API 接口。当然，我也可以用一个 nginx 服务器代理 Bangumi API 的服务，但是我真正的意图是想在前端使用 GraphQL。所以，这个 node 服务是一个 Apollo GraphQL Server，提供整合的 schema 和 API 接口。

前端设计

为什么要用 GraphQL？如果仅仅是“用 GraphQL 那套接口开发”这无疑就会降低我选择这个技术的可能性，毕竟它可能还没有 Restful API 方便。但是 Apollo GraphQL 的生态系统是如此之成熟，这使得选用 GraphQL + Apollo Client 成为一个非常有吸引力的选项。

我最喜欢 Apollo Client 对 Query 的自动缓存功能。想象一下当载入 https://chii.ai 主页面的时候，它首先会载入所有的动画排名。用户可能会点到别的页面再点回来，由于在第一次 Query 的时候我已经缓存了排名结果，我就不需要再向服务器发送一次请求了。听上去是不是很有吸引力？而 Apollo Client 使得这一切都 work under the hood！

这套缓存系统是如何运作的呢？Apollo Client 对每个发出的 Query 都做了缓存。这听上去挺荒唐，因为以每一个 Query 作为 key 结果直接作为 value 可能占用太多内存了。实际上，GraphQL 里面我们知道返回的数据结构。而不同的Query可能共享同样的数据结构，只不过内容不同。这时候 Apollo Client 将实际返回的数据的 id 和数据结构类型作为 key，返回的数据作为 value。在最理想的情况，每个数据结构里面的子数据结构都有 typename 和 id，这样可以彻底 normalize 所有返回的数据。以 typename 和 id 作为缓存的 key 和直接以 Query 本身作为 key 相比可以大大减少内存占用。

这里面还有一些精妙的东西。比如说你用查询排名的 Query 返回了一连串动画。然后用户点进去其中一个动画，这会发出第二个 Query 请求请求这个动画的 details。第一个 Query 返回动画这个数据结构的列表，第二个 Query 返回一个动画数据结构。由于这个动画具有唯一的 ID，它在缓存里的 key 也是唯一的。那么第二次 Query 的结果实际上会对第一次 Query 里面那个列表里面的动画进行一次更新——它会覆盖先前的值。这么做是自然的，因为两者同属一个数据结构，自然在后端返回的东西应该是一致的。如果你的后端不是这样（比如说某些 API 返回部分 field，另一些 API 又返回另一些 field，甚至同一 field 的内容还不同），那么你会遇到一些 bug。

这个缓存系统听上去挺先进。但是实际上我观察到它也有一些缺点：因为缓存要建 Hash Table，与不缓存的方案相比，它会带来一些时间上的 cost，甚至会造成页面卡顿！这在 fabric 架构下的 React 应用程序简直就是不可忍受的。

有了 Apollo Client 前端的开发其实还不够现代。我们还需要 graphql-codegen 辅助我们自动从 GraphQL Schema 生成可以执行的 Apollo Client Query。那么实际的开发流程就变成了：我需要什么 Query/Mutation，我先写出来，连带上会返回的 schema。我还需要一个 graphql-codegen 配置文件告诉它 server side schema 在哪里。通过一次 yarn generate，我就可以得到直接可以在 Javascript 里 import 的 typed schema，typed query/mutation。这样就可以作为 Typescript 开发的一个良好起点。

毫无疑问，前端全部使用 React Hooks 编写。我使用了微软下一代 UI 库 fluentui northstar。但是其使用还是不如 ant-design 方便，以至于我不得不把 Table 和 Pagination 两个组件按照 antd 的接口通用化了一下下。

整体架构

如上图所示，该站整体架构分成五个部分。首先，由 .Net Core 和 Postgers server 构成了后端逻辑的核心。其次，Apollo Server 作为 GraphQL server，运行在 Node 上，其接收前端请求并向真正的后端发出 API 请求。Apollo Server 实际上也封装了某些 Bangumi API，使得其成为一个 API 的 hub。为了减轻后端压力，Apollo Server 后接 Redis 作为 cache。前端是一个 React Application，部署在 Nginx 里面。该网站开发时使用 docker compose，部署在 Azure Kubernetes Service 上。

一些反思

这个架构是否就是最好的架构？恐怕并不是的。我的 GraphQL 服务器并不是原生的 GraphQL 服务，这其实造成了一些 latency：发送一个请求需要通过 GraphQL server 再转接到 .Net Core 的 server。这么做的背后逻辑其实是我想用 GraphQL 那一套生态系统开发，这就产生了后端既有 Restful API 也有 GraphQL 的情形。

如何避免这种用 node server 做 GraphQL server 转接的方式发生？最理想的想法就是后端所有逻辑使用 node 重写。但是我后端主要代码逻辑都在 .Net Core 里面，这样做太浪费时间了。

一种想法是，Apollo Server 所做的主要事情就是一个 resolver。我是否可以在前端使用一个 service worker，把 resolver 作为一个单独的进程，前端主进程只要与这个 service worker 相通信就可以了呢？这样实际上就把一段后端逻辑搬到了前端，而且后端又简化了不少。这需要我深入研究 service worker 的使用方式。

目前的想法暂时就是这些。前端的代码在这里，后端的代码在这里。各位看官如果还有什么问题，欢迎在评论里面提出。

Review the year 2020(存目)

Sat, 09 Jan 2021 00:00:00 GMT

https://treehole.ikely.me/Review-the-year-2020/

Bangumi Spider 的历史遗留问题及基于 GitHub Actions 的解决方案

Fri, 03 Jan 2020 00:00:00 GMT

在我的 GitHub 页面里，Bangumi Spider 这个基于 scrapy 的爬虫恐怕是维护时间最久的东西了。从 2015 年为了写 Chi （Bangumi 的好友同步率——推荐系统）开始，这个东西就一直维护到今天。顾名思义，它的主要作用就是爬取所有的用户、所有的条目和用户标记条目的记录。今天，Bangumi Spider 的主要作用是服务于 https://ranking.ikely.me，每月爬取所有标记记录并计算动画排名。动画排名应该每个月第 1 + n 天会更新，n 取决于爬虫爬取速度。

Overall technical background of ranking.ikely.me

在此图中，左边是理想中的爬虫部分。定时任务首先每月向爬虫服务器 scrapyd 发送爬取请求，爬取后的数据以文本形式放在 Azure Blob 里。然而这时候还是 raw data，需要一个 postprocessing job 对爬取后的数据进行处理形成最后可以直接被 ranking.ikely.me serve 的数据。看上去很简单，是不是？然而在多年的技术发展中，该项目背负了沉重的技术债。

首先，在很久以前，这套东西为了能运行，爬虫服务和应用服务是在同一台虚拟机上的。第一版应用服务用的还是 flask + jinja 一套 SSR。postprocessing job 在 2016 年的时候还是我线下手动生成的，于是在之后的三年里 ranking.ikely.me 一直都没有更新是因为我忘记了线下生成数据的格式。终于在 2018 年，这一套应用用 dotnet core 重写了一遍，并封装成 docker image。scrapyd 被移出虚拟机封装成 docker image。于是该虚拟机就成了 ranking web application docker container instance + reverse proxy。同时为了能自动化生成排名数据，postprocessing job 被移到了该虚拟机里面。postprocessing job 运行时所需要的内存巨大，在去年大约要 10 GB 内存（在今年涨到了 14 GB）。crontab job 也被写在了该虚拟机里面。这一套系统运行了六个月，然后又不能自动更新排名了，因为 Bangumi 页面样式更新使得某些数据无法爬取。这里面存在的问题有：

Azure 虚拟机高配置而长时间空转，浪费 budget；
scrapyd container instance 在爬取数据过后还会重启，丢失已部署的爬虫，经调查有不法人士黑入该 instance；
ranking web application 并非 continuously deployed，需要手动更新；

在理想的状况下，每一个部件应该自动化运行并充分利用现有 budget。而 GitHub Actions 的出现，为实现这种理想提供了便利（当然，需要指出的是，GitHub Actions 并未唯一实现这种自动化的手段）。在图的每一个被标记的部分都应该有自动化：

crontab job 自动化
自动按需启动 scrapyd server 并在运行结束关闭
自动按需启动 postprocessing job 并在运行结束关闭
随着爬虫的更新，postprocessing job 也应该更新

即使不能做到 100% 自动化，能大幅降低服务空置率也是对宝贵 budget 的一种有效利用。此外，我希望将 ranking web application 移出虚拟机，用 Azure web service (Linux) + container 的技术去 serve，以降低成本。

GitHub Actions

GitHub Actions ，据官方描述，能够极大简化你的 CI/CD 流程。但实际上它能做的事情不仅局限于 CI/CD。在这篇文章中，我将介绍 Bangumi Spider 新添加的 GitHub Actions 如何实现自动化部署和排名自动化更新。

在 Bangumi Spider 里面，有一个叫做 scrapyd 的 folder 存放了 Bangumi Spider 专属 scrapyd dockerfile，其和普通的 scrapyd 不同之处在于使用 nginx 在访问前进行一次验证。在这个 workflow 里面，GitHub Actions 先 build docker image，再 publish 到 Docker Hub，最后更新 Azure container image。

正如上文所述，我不希望 scrapyd 在不执行爬虫任务的时候运行，所以我在最后关闭了它。在另一个定时 workflow 里面，我启动相应的 Azure container service，在线部署爬虫并运行爬取用户记录番组的数据和番组数据的 jobs。

另一个叫 postprocess 的 folder 存放了对已爬取进行后处理的 Dockerfile。其执行任务净是一堆脚本文件，以单机有限资源处理百万行数据。这是一个有艺术性的话题，但是我不想讲。针对这个 Docker image 的构建 workflow 被描述在这个文件里。相应地，我在另一个 workflow 定时启动相应的 Azure container service，运行完成就结束。

需要指出的是，在这里我发现了 GitHub Actions 是可以支持每次 commit 所触动的文件而出发 Actions 的——倒不如说我发现 Travis CI 不支持这项功能。这样我每次提交的时候我就可以通过检查修改的文件是否涉及 scrapyd 和 postprocess 两个 folder 而 conditionally update docker images。就这项功能而言，我觉得 Travis CI 已经完全落伍了。

Azure Web App Service

Azure 提供 App Service 的服务，并附带一个 Azure 的证书，而且也可以绑定到自己的域名。关键是这个服务的价格比自己 host 虚拟机要便宜（如果用 Basic plan 的话）。App Service 最好的地方在于支持 docker image 和 docker-composed images，于是我把 dotnet core 的服务也使用 docker image 部署在其上。https://ranking.ikely.me 使用 CloudFlare 做 CDN 并由其提供证书，关于如何把 CloudFlare 的证书导入到 Azure App Service 的操作参见这篇文章。

Achievements

通过这么一番操作，我们已经：

100% 实现了全自动无人干预更新排名（除非 Sai 老板再次更新 Bangumi 页面导致爬虫需要连带更改）
Conditionally update docker image
大幅削减预算：从每月七十多刀的虚拟机削减到十四刀左右。
增强了 scrapyd 的安全性。

My Kaggle Days China experience

Sat, 26 Oct 2019 00:00:00 GMT

I have been a Kaggle fan for a long time. A community of data scientists and engineers devoting for pioneer data science practice has always been attractive for me. Though I’m not a dedicated Kaggler, I would still devote several month’s weekends per year to some Kaggle competitions after work, to grasp the spirit of dedication and religious attitude. That’s why I registered it the first time when I received the registration notification email.

Besides the lectures and GrandMasters, another thing that specifically attracts me is the offline data science competition. I have been curious about the authentic ability of offline coding, since in my opinion, most Kagglers online are fed by public Kernels. What would be their real performance without Kernels? Though I’m only a linear model Kaggler, I’m certain that I am somewhat experienced than others in feature selection, so there might be a chance for me to win.

I checked the previous Kaggle days before this event, and all the offline competitions are about tabular data. So I tried to get me familiar with all common EDA APIs and code snippets of pandas feature generation and scikit-learn compatible cross-validation. I know deeply that my skills in traditional machine learning cannot achieve high place on leaderboard in the age of deep learning, so I invited one of my colleague, Lihao, who is a deep learning expert, to join me.

DAY 1

Opening of Kaggle Days China

The first day of the event was all about lectures and workshops. There were several interesting workshops for you to attend, but you must register first. The first thing I regreted was that there was an lecture about LightGBM that I really wanted to attend, but it conflicted with a workshop about modeling pipeline. In fact, I attended that lecture when it was about to end, and even so, I still learned something insightful from that. I may need to go review the lecture videos later.

Someone mentioned before that all the things to do when attending a technical meeting is to chat with people: no need to attend lectures, no workshops, just communicating. And I have to say this is the best part of the Kaggle Day. I did talk with a lot of people. However, I was still too shy during the meeting because it wasn’t me who tried to get to know others first. I have to say everybody in Expert group have their domain knowledge, not all of them are necessarily experienced Kagglers, but they know AI industries in China very well. As a SDE working in a small city, Suzhou, I have not felt this excitement of communicating with industry experts for a long time ever since I left Beijing in 2015.

Announce of competition title on day 2

At the end of the day, the organizer disclosed the title of tomorrow’s data science competition. Though I had expected that it should be another tabular data competition, the title indicated that it would be a computer vision competition. It reminds me of a previous competition classifying astronomical objects, but it may not necessarily be in the same form. Having no practical knowledge of contemporary computer vision, in which deep learning has dominated, I regretted I didn’t follow my domestic advisor Lianwen Jin well when I was in graduate school. My working experience also could not contribute to this competition since I’m working in NLP group. Fortunately, when we were about to leave, a guy came to us, asking if he can join us. He said he had some CV background. Perhaps this was the best news I received that day, so I was grateful for him.

DAY 2

I had decided from yesterday’s night that if the competition was really a computer vision competition, I would resort to fast.ai. I leaned about it this summer, and this was the only thing I know how to use in modern deep learning based CV. It turned out it is. This competition requires us to classify images into two classes, so it’s a typical binary classification problem.

CV requires GPU equipped machines, and on the night before competition, we were required to configure our machines on specified service provided by UCloud. It was actually a Jupyter Notebook backended by 8 GPUs. However, without proper configuration, that machine is almost unusable. It has tf 2.0 alpha installed, not final release version nor stable tf 1.14. So Lihao spent a lot of time configuring the machine in the morning.

I originally thought that one need to perform EDA and do proper train/test split first, but soon I discarded this idea for this CV competition. However, Williame Lee, the guy I mentioned above, spent some time inspecting data first. He tried to find out some patterns of the image. But in my opinion, features are extracted automatically by deep neural networks, and even if I concluded some patterns, we don’t know where to feed it if I use deep neural network to extract feature.

Kaggle offline competition ongoing

The core spirit of fast.ai is using pre-trained networks to classify images, and fine-tune them at the end. This turned out to be a very successful idea. I used the whole morning to build the pipeline, and it works! My first classifier, which is using ResNet34 as pretrained model, works as well as baseline. Later, Lihao trained this model further to push it to 0.85, and we tried several other models like ResNet18 and ResNet50. Even NN simple as RetNet18 can achieve good results at 0.82 after fine-tunning. Williame also developed a neural net using mobile net which is achieving 0.81 on public leaderboard.

Meanwhile at the same time, Fengari shared his 0.88 baseline, which is using EfficientNet. You can imagine that this fed many competitors attending this competition. Lihao then switched to this new baseline and adapted its cross-validation scheme. At last, we merged our three ResNet pretrained models and two EfficientNet adaptations as final result. That placed us at 17th over the whole leaderboard (34 teams). Not too bad for me as my first CV competition experience!

Day 2’s experience is like thrown in to a swimming pool (I don’t know how to swim, really) and learn to swim by myself. I have successfully trained a deep neural network targeting computer vision for the first time. Now I’m not fearing CV any more!

The organizer soon announced the winners, who are sitting in-front of us face-to-face during the whole competition. They are using multi-tasking to improve our model, which is a key technique that Williame implied in the morning. Their solution is here: https://github.com/okotaku/kaggle_days_china

Before this Kaggle Day, my ambition was to stand on the winning stage. But unfortunately, I still have many things to learn to achieve this goal. I asked Lihao later if this is the ideal tech venue that he likes, his answer was no, but he still prized the core spirit of this Kaggle community. I hope next year, I would find someone who bear the same mindset as me and debut together. ~~If I could cross-dress the next time, the best!~~

Saving the React novice: update a component properly

Thu, 01 Aug 2019 00:00:00 GMT

Front end development in React is all about updating components. As the business logic of a webpage is described in render() and lifecycle hooks, setting states and props properly is the core priority of every React developer. It relates to not only the functionalities but also the rendering effectiveness. In this article, I’m going to tell from the basics of React component update, then we will look at some common errors that React novice would often produce. Some optimizing techniques will also be described to help novice set up a proper manner when thinking in React.

Basics

A webpage written in React consists of states. That is to say, every change of a React component will lead to a change in the appearance of a webpage. Since state can be passed down to child components as props, the change of state and props are responsible for the variation of view. However, there are two key principles pointed out by React documentation:

One can not change props directly.
One can only update state by using setState() .

These two constraints are linked with how React works. React’s message passing is unidirectional, so one can not mutate props from child component to parent component. setState() is related to a component’s lifecycle hooks, any attempt to change state without using setState() will bypass lifecycle hooks’ functionality:

React lifecycle hooks diagram, referring to http://projects.wojtekmaj.pl/react-lifecycle-methods-diagram/

However, during my development experiences, I have observed numerous cases where these two principles are broken. A major part of those misbehaved patterns can be traced back to the selective ignorance of a important property of JavaScript.

Assignment: reference or value?

Assignment to const value

Let’s look at the example above. We all know const allows us to declare a variable that cannot be assigned a second time, so there’s no doubt why when we are trying to assign temp with 3 a TypeError is thrown. However, const does not imply constness to the internal field of an object. When we are trying to mutate the internal field of obj , it just works.

Assigned object is an reference to original

This is another common operation. From the script we know a and b are two non-object variables, and re-assignment to b leads to a !== b . However, when we are trying to assign d as c, which is an object, mutating the internal field does not change the equal relationship between the two. That implies that d is a reference of c.

So we can conclude two observations from the above:

const does not mean constness to object’s field. It certainly cannot prevent developer from mutating its internal field.
Assigning an object to another variable would pass on its reference.

Having acknowledged of the above, we can go on to the following code:

class SomeProblematicComponent extends React.Component {
  constructor(props) {
    super(props)
    this.state = {
      data = props.data // props.data is an Array of objects
    }
  }
  onChange = (arg) => {
    const prevData = this.state.data
    let nextData = []
    prevData.forEach(itm => {
      itm.a = arg
      //some manipulations on copied prevData's internal objects
      nextData.push(itm)
      //after manipulation, push the modified object to nextData
    }
    this.setState({
      data: nextData
    })
  }
  render() {
    // it would call onChange somewhere
  }
}

View original gist

As you read the code, you are clearly aware of the intention of the author: onChange is a place where this.state is changed: it is changed according to incoming parameters. The author get a copy of original data first, then modify its value, then push to nextData. At last, the author calls this.setState to update.

If this code’s pattern appears in your projects and it works, it is normal. According to React’s component lifecycle, the this.state.data is changed to nextData , and it will eventually effect the render()’s return value. However, there are a series of flaws in this code that I have to point out. If you fully understand and agree with the two observations I mentioned above, you will find the following points making you uncomfortable:

data=props.data in line 5 is assigning this.props.data’s reference to this.state.data, which means changing this.state.data directly COULD mutate this.props.data.
prevData is assigned as a reference to this.state.data in line 10. However, as you read through the code, you will realize that this is not the real intention of the author. He wants to “separate” prevData from this.state.data by using const. However, this is a totally misunderstanding of const.
In line 13, each item in prevData is mutated by assigning its field a to another value. However, as we mentioned before, prevData is a reference to this.state.data, and this.state.data is a reference to this.props.data. That means by doing so, the author changed the content of this.state.data without using setState and modified this.props.data from child component!
In line 18–20, the author finally calls setState to update this.state.data. However, since he has already changed the state in line 13, this is happening too late. (Perhaps the only good news is that this.state.data is no longer a reference to this.props.data now.)

Well, someone may clam: so what? My page is working properly! Perhaps those people do not understand the functionalities of lifecycle hooks. Usually, people write their business logic in lifecycle hooks, such as deriving state from props, or to perform a fetch call when some props changes. At this time, we may write like the following:

componentDidUpdate(prevProps){
  if (this.props.data !== prevProps.data) {
    // business logic
  }
}

Every time a component finished its update, it will call componentDidUpdate. This happens whenever setState is called or props is changed.

Unfortunately, if a novice developer unintentionally mutated this.state or this.props , these lifecycle hooks will not work, and will certainly cause some unexpected behaviors.

How to make every update under control?

If you are an lazy guy and like the natural thinking of using a temporary variable separating itself from original, as I displayed above, you are welcomed to use immer. Every time you are trying to update state, it would provide you a draft, and you can modify whatever you want on that before returning. An example is given by its documentation.

However, you should know that the most proper way to update a state field without modifying it directly through reference is to perform a clone. The clone sometimes needs to be deep to make sure every field is a through copy of the original one, not reference. One can achieve that goal by deepClone from lodash. But I do not recommend that since it may be too costy. Only in rare cases you will need deepClone.

Rather, I recommend using Object.assign(target, …sources) . What this function does is updating target by using elements from sources. It will return target after update is complete, but its content will be different from those of sources. So updating object should be like:

const newObj = Object.assign({}, this.state.obj, {a: 1})

The actual programming can be more easy: you should know that there’s spread syntax available for you to expand an object or array. Using spread syntax, you can easily create an new object or array by writing:

const newObj = {...this.state.obj}
const newArray = [...this.state.data]

That allows you to copy the original content of an object/an array into a new object/array. The copy behavior at this point is shadow copy, which means only the outer most object/array is changed, and if there’s an object inside the field of the original object, or an object at some position of an index, that inner object will be copied as a reference. This avoids the costy operations inside deepClone. I like this, because it gives you precise control on what you need to change.

So the proper component I gave above should be like this:

class SomeProblematicComponent extends React.Component {
  constructor(props) {
    super(props)
    this.state = {
      data = [...props.data]
    }
  }
  onChange = (arg) => {
    this.setState(prev => {
      const data = [...prev.data]
      return {data: data.map(itm => {...itm, a:arg})}
    }
  }
  render() {
    // it would call onChange somewhere
  }
}

View original gist

Some further advice

I would suggest all components you write from now on should be changed to React.PureComponent. This is no different from React.Component except it has its default shouldComponentUpdate function: it performs a shadow comparision of its states and props to check whether it should be updated, meanwhile React.Component would always return true if you do not provide custom logic. This would not only improve page’s performance but will also help you realize the unexpected rendering when you made the mistake I mentioned above.

If you need similar functionality on function components, you can try React.mono() which is available since React 16.6.

RegExp.test() returns true but RegExp.exec() returns null?

Wed, 10 Jul 2019 00:00:00 GMT

Consider the following Javascript script:

const regex = /<(\w+)>/g
const testString = "<location>"
// Check whether testString contains pattern "<slot>"
// If yes, extract the slot name

if (regex.test(testString)) {
  console.log(regex.exec(testString)[1])
}

It seems to be a perfect logic extracting the tag name of the tag string: one uses test to prevent the situation that testString does not match. However, it would throw an error:

TypeError: regex.exec(...) is null

It just violates our intuition: the string do match the regex, but it could not be matched. So why does this happen?

As MDN has stated, invoking test on a regex with flag “global” set would set “lastIndex” on the original regex. That lastIndex allows user to continue test the original string since there may be more than one matched patterns. This is affecting the exec that comes along. So the proper usage of a regex with “g” flag set is to continue executing the regex until it returns null, which means no other pattern could be found in the string.

This behavior is sometimes undesirable, since in the above scenario, I just want to know whether the string matches the predefined pattern. And the reason I don’t want to create the regex on the fly is to save the overhead of creating an object.

One obvious solution is to remove “g” flag. But sometimes, we do want to keep the “g” flag to find if a string matches the given pattern, and we don’t wish to modify the internal state of regex. In that case, one can switch to string.search(regex) , which would always returns the index of first match, or -1 if not matched.

Write a reusable modern React component module

Fri, 03 May 2019 00:00:00 GMT

今天这篇文章主要讲怎么用一种科学、优雅的方式开发一个可复用的 React Component，其实实际上不仅限于 React Component，如果想要写任何一个可以被 npm install 的模块都是可以适用的！

听起来很简单？这个事情的结论是可以用一句话概括的，在我研究了半个月之后发现确实是的（，我们走了一些弯路）。为了照顾那些大忙人，可以直接下拉到文章最底端，使用我推荐的库就行了，我可以保证那个库和它背后的模板是 best practice。

有人说，既然你已经给出了答案，那么还要读这篇文章干什么呢？因为写一个 js module 有很多种写法。可是要做到可复用还要做一些额外的工作。以最简单的方式，我写一个 mymodule.js，在最下方写上 export default MyModule，然后在另一个调用其的文件里面写上 import MyModule from ‘./mymodule’ 这个事情就算完了。我可以对外宣称，这是一个可复用的组件！真的吗？

我担心的事情有：

这个组件依赖于 React， React-dom，怎么让用户知道他们也必须用这两个东西呢？
如果用户在自己的应用上面用了 React 16.2，但是我的组件使用了 React 16.8，用户在使用我的组件的时候会出现兼容性问题吗？会不会为了兼容性问题而装两个版本的 React 呢？
用户调用我的包，是通过文件直接调用的，怎么才能把我的包放在 node_modules 里，即，通过 npm install 的形式安装？
我的包使用了某些先进的语言特性。通过文件直接调用是无法通过 babel 转义为较低版本的 Javascript 的。甚至，用户都不能通过 import MyModule from './mymodule' 的形式调用！

但是在使用 npm 上面的包的时候，我似乎完全不用担心上面这些问题。所以为了写一个可复用的模块还需要某些额外的操作。

第一个实例

如果我们在 Google 上搜索 “write a reusable react component module” 等词语，我们可以找到一些号称自己是模板的东西，比如说这个 rinse-react，它是一个可以作为 boilerplate 的项目。让我们去看看它为了让 rinse-react 模块化做了哪些工作。

如果你去你的任何一个项目里的 node_modules 里看，你会发现 package.json 至关重要，因为它指定了一个模块的入口点，那就是 main 这个 field。对于 rinse-react 这个模块，其入口点是 dist/rinse.js，可以猜出这个文件是经由 webpack 打包后输出的。

于是我们打开 webpack.config.js, 里面的输入和各种 loader 同正常的 SAP 配置大同小异。但是需要重点指出的是 output.libraryTarget，它的含义就是把 src/index.js 里的返回值以怎样的形式作为模块输出。这里面要指定的值与模块会被怎样调用有关。我们除了 import MyModule from 'mymodule' 这种方式，还可能以 var MyModule = require('mymodule') CommonJS 的形式调用，也可能会以 define('MyModule', [], function() { ... }) 的 AMD 形式调用。为了兼容所有的调用方式，在 rinse-react 里面设置 output.libraryTarge = 'umd' ，这样被 webpack bundle 之后的模块就可以以任何一种形式调用。

对模板的优化

一部分人可以欢呼了，因为看起来找到了一个可以拿来用的模板。但是有没有发现其中的问题？

它看上去也把当前版本的 react, react-dom 和 styled-components 打包了进去，增加了库的大小；
它实际上是先通过 babel 的转译再被下游应用调用的模块，所以下游应用使用 ES6 的 import 的时候，并不会有真正的 tree-shaking （所谓 tree-shaking，就是 ES6 通过分析 import 和 export 判定哪些代码被真正地调用，从而在执行前就把不被调用的代码给去掉）。
我也没有必要在下游应用 bundle 的时候对源模块进行二次 bundling。

对于第一个问题，在 package.json 里面可以使用 peerDependencies 解决。在 peerDependencies 里面的东西，应该是下游应用也同时依赖的东西。如果你不把依赖放在peerDependencies 而是放在 dependencies 里（就像 rinse-react 一样），它们就会成为私有的依赖。

那么自然地，有没有 peerDependencies 在模块里的版本和下游应用的版本不匹配的情况呢？当然会有。这时候如果出现了不可兼容的版本，npm install 的时候会有提示，而在实际开发中，我发现安装的是最高指定版本。

但是我们还没有解决如何真正地实现 tree-shaking 特性。幸运的是，最佳实践告诉我们，rollup.js 正是为了解决这一问题而来的。rollup 也是一种打包工具，但是和 webpack 的目的不同，rollup 的初衷是为了尽量把模块的依赖打平并且高效地利用 tree-shaking。从这一出发点来讲，编写可复用的模块应该使用 rollup.

在 rollup 打包的过程中，在 package.json 里面会提供两个入口：传统的 main 指向打包后兼容 UMD 的打包内容；前卫的 module 应该会指向一个类似于 main.es.js 的文件：它使用 ES6 的先进特性。这样，在一个实际应用试图 import 一个模块的时候，它会先查看 package.json 是否有 module，如果有的话就以 module 指向的文件作为入口，避免了 babel 转译并且最大限度利用 tree-shaking. 如果应用在 build 的时候不支持 module，就 fallback 到 main 所指向的 UMD.

一个基于 rollup 的库模板

由于很偶然的原因，在我试图研究 Ant Design 如何开发出如此优雅的组建库的同时，我发现了一个可以自动生成基于 rollup bundling 的库模板生成器。这个东西基本上解决了我上面所有的困惑。我诚邀各位试一试这个 create-react-library，并且劝退那些想要研究 Ant Design 的人，他们家自己研发的 rc-init 连文档都没有且都没有人维护的。

当然，在我使用这个模板生成器的时候，他们只能生产出基于 babel 6 的配置。为了与实际开发环境匹配，我又手动修改到了 babel 7。

剩下的问题

看来怎样开发一个 js 库这个问题到现在算是解决了。但是这样的库真的能与 Ant Design 相媲美了吗？在实际下游应用开发过程中会有按需加载的需要，为了能让用户按需加载 Ant Design，babel-plugin-import 应运而生。怎样优雅地面向按需加载开发是一个需要研究的问题。

参考文献

Rinse-react: https://rinsejs.io/
Webpack: output.libraryTarget: https://webpack.js.org/configuration/output/#outputlibrarytarget
Writing Reusable Components in ES6 https://www.smashingmagazine.com/2016/02/writing-reusable-components-es6/
CommonJS vs AMD vs RequireJS vs ES6 Modules https://medium.com/computed-comparisons/commonjs-vs-amd-vs-requirejs-vs-es6-modules-2e814b114a0b
你的 Tree-Shaking 并没什么卵用 https://juejin.im/post/5a5652d8f265da3e497ff3de
Webpack and Rollup: the same but different https://medium.com/webpack/webpack-and-rollup-the-same-but-different-a41ad427058c

Release of rankit v0.3 and roadmaps for future bangumi ranking

Sun, 21 Apr 2019 00:00:00 GMT

After several years (really!) of development, I’m pleased to announce that rankit has been upgraded to v0.3. The version of previous major release is v0.1, which was made in 2016. So what has changed during these three years?

At the time when rankit v0.1 was developed, it was aimed to implement all fascinating algorithms mentioned in a beautiful ranking book and provide an alternative ranking solution to Bangumi. The programming interface designed at that time is far from practical. As I was looking into more ranking algorithms, the more I felt that rankit should include some popular ranking algorithms that are based on time series. One of them is Elo ranking, which has a simple implementation in rankit v0.2. But the usage scenario is limited: updating ranking is tedious and its interfaces are not compatible with existing ranking algorithms.

In v0.3, following updates are made to address those problems mentioned above:

Split rankers to “Unsupervised ranker” and “Time series ranker”. Each of those two rankers have their own interface, and they both consume the Table object to keep records.
Introduced Elo ranker, Glicko 2 ranker and TrueSkill ranker (only paired competition record is supported)
Updated interface to make it more user-friendly. For unsupervised ranker, only rank method is provided since it needs no update. For time series ranker, user should provide one use update to accumulate new record data and one can retrieve latest leader board by invoking leaderboard after each update.

The documentation of rankit has also been updated.

One side product of rankit is the “Scientific animation ranking for Bangumi”. For a long time, the ranking is not updated and it is gradually forgotten. I gave it a refresh last year and it is now having a completely new look with faster response and simple search functionality. More importantly, the ranking will be updated monthly. I would invite you all to have a try it here: https://ranking.ikely.me

The latest scientific animation ranking also involves minor algorithm changes. It is often witnessed that at certain time, users with peculiar intention would pour into Bangumi to rate one specific animation with certain high or low score. This impacted the proper order of rating. In previous version of scientific ranking, one can neglect those users who rate one anime and leave permanently, but could not handle those users who rate multiple animations. I adjusted the scores user rated overall and made several normalization according to the distribution of users’ rating, and all versions of normalized scores are fed into rankit to calculate latest rank. The final rank is still merged using Borda count.

But could this be solved from another perspective? One thing I have been thinking about is how to involve time series ranking into current ranking scheme. Ideally, time series ranking should act to combat ranking manipulation behavior in a way other than pairwise ranking. As I was reading about TrueSkill ranking, their brilliant idea to inference ranking using linear chain graph stroke me. Actually, TrueSkill is a generative graph model that organized in a order same as competition score. Another issue that need to resolve is to help users adjust historical ratings automatically: a user would rate an animation with wider range before, but his or her rating criteria may change with the evolvement of time. How to propagate recent rating criteria to historical ratings? All these should be supported in the next version of rankit. That is, to enable ranking for multiple players in a match, and power to propagate recent competition result to historical data.

Mangaki data challenge 1st place solution

Mon, 02 Oct 2017 00:00:00 GMT

Mangaki data challenge is an otaku-flavor oriented data science competition. It’s goal is to predict user’s preference of an unwatched/unread anime/manga from two choices: wish to watch/read and don’t want to watch/read. This competition provides training data from https://mangaki.fr/ which allows users to favorite their anime/manga works. Three major training tables are provided as described as follows:

Wish table: about 10k rows

User_id	Work_id	Wish
0	233	1
…	…	…

Record table: for already watched/read anime/manga. There are four rates here: love, like, neutral and dislike.

User_id	Work_id	Rate
0	22	like
2	33	dislike
…	…	…

Work table: detailed information of available anime/manga. There are three categories: anime, manga and album. There is only one album in this table, all the others are anime (about 7k) and manga (about 2k)

Work_id	Title	Category
0	Some_anime	anime
1	Some_manga	manga
…	…	…

For the testing data, one should predict 100k user/work pair on whether the user wish or not wish to watch/read an anime/manga. As you can see, the testing data is much larger than training data. Besides, during my analysis of this dataset, it is also not ensured that all users or works appeared in test set are contained in training set.

Traditional recommendation system methods (that I know)

Recommendation system building has long been studied and there are various methods in solving this particular problem. For me, I also tried to build a recommender for https://bgm.tv several years ago (you can read technical details here). The simplest solution is SVD (actually, a more simple and intuitive solution is by using KNN), then one can move on to RBM, FM, FFM and so on. One assumption that holds firm in all these methods is that users should have an embedding vector capturing their preferences, and works should also have their embedding vector capturing their characteristics. It is reasonable that we should be constrained in this embedding-dotproduct model?

Recently, the common practice on Kaggle competition is by using GBDT to solve (almost all except computer vision related) questions. As long as a model can handle classification, regression and ranking problem very well, it can be applied in all supervised machine learning problems! And by using model ensembing under stacknet framework, one can join different characteristics of models altogether to achieve the best result.

In this competition, my solution is quite fair and straightforward: feature engineering to generate some embeddings, and use GBDT/Random Forest/Factorization Machine to build models from different combinations of features. After all, I used a two-level stack net to ensemble them, in which level two is a logistic regression model.

Feature Engineering

From wish table:

Distribution of user’s preference on anime/manga (2d+2d)
Distribution of item’s preference (2d)
Word2vec embedding of user on wish-to-watch items (20d)
Word2vec embedding of user on not-wish-to-watch items (10d)
Word2vec embedding of item on wish-to-watch users (20d)
Word2vec embedding of item on not-wish-to-watch users (10d)
Lsi embedding of user (20d)
Lsi embedding of item (20d)

From record table:

Distribution of user’s preference on anime/manga (4d+4d)
Distribution of item’s preference (4d)
Mean/StdErr of user’s rating (2d)
Mean/StdErr of item’s rating (2d)
Word2vec embedding of user on loved and liked items (32d)
Word2vec embedding of user on disliked items (10d)
Word2vec embedding of item on loved and liked users (32d)
Word2vec embedding of item on disliked users (10d)
Lsi embedding of user (20d)
Lsi embedding of item (20d)
Lda topic distribution of user on love, like and neutral items (20d)
Lda topic distribution of item on love, like and neutral ratings (20d)
Item categorial (1d, categorial feature)
User Id (1d, only used in FM)
Item Id (1d, only used in FM)

Model ensembing

The first layer of stack net is a set of models that should have good capability of prediction but with different inductive bias. Here I just tried three models: GBDT, RF (all backended by lightGBM) and FM (backended by FastFM). I trained models from record table feature and training table feature separately, and one can further train different models using different combinations of features. For example, one can use all features (except user id and item id) in record table feature. But since GBDT would keep eye on most informative feature if all feature were given, it would be helpful to split features into several groups to train model separately. In this competition, I did not split too much (just because I don’t have too much time). I just removed the first four features (because I see from the prediction result that they have having a major effect on precision) and trained some other models.

Model stacking

The stack net requires one to feed all prediction result from the first layer as feature to second feature. The stacking technique requires one to do KFold cross-validation at the beginning, and then to predict each fold’s result based on all other folds as training data on the second level. Here is the most intuitive (as far as I think) description of model stacking technique: http://blog.kaggle.com/2017/06/15/stacking-made-easy-an-introduction-to-stacknet-by-competitions-grandmaster-marios-michailidis-kazanova/

In this competition, by using a single GBDT and all the features from record table one can reach 0.85567 on LB. By leveraging model stacking technique, one can reach to 0.86155, which is my final score.

Is this the ultimate ceiling?

Definitely not. One can push the boundary much further:

I did not tune the embedding generation parameters very well. In fact, I generated those features using default parameters gensim provided. The dimension of embeddings are just get by my abrupt decision, no science involved. Maybe one can enlarge the sliding window of word2vec or use more embedding dimensions to achieve better results.
I only used lightGBM to build GBDT. One can also use xgboost. Even though they all provides GBDT, lightGBM is a leaf-wise tree growth algorithm based model, while xgboost is depth-wise tree growth. Even though two models are all CART based GBDT, they behaves differently.
I did not introduced any deep model generated features. GBDT is such a kind of model that relies on heavy feature engineering while deep model would learn features automatically. By combining them altogether in stacking model one can obtain much higher AUC definitely.
I did not use more complex features. Sometimes, population raking would also effect user’s behavior. A user would select those animes ranked high as “wish to watch”. I did not tried this idea out.

Conclusion

I must say this competition is very interesting because I see no other competition targets on anime/manga prediction. Another good point of this competition is that the training data is very small, so that I could do CV efficiently on my single workstation. And before this competition, I have never tried stack net before. This competition granted me some experience in how to do model stacking in an engineering experience friendly way.

One thing to regret is that too few competitors were involved in this competition. Though I tried to call for participants to join on Bangumi, it seems still not many people joined. The competition holder should make their website more popular next time before holding next data challenge!

One more thing: one may be interested in the code. I write all my code here but they are not arranged in an organized way. But I think the most important files are: “FeatureExtraction.ipynb” and “aggregation.py”. They are files about how to do feature engineering and how to partition features. “CV.ipynb” gives some intuition on how to train models.

Console as a SQL interface for quick text file processing

Fri, 14 Apr 2017 00:00:00 GMT

最近在处理业务上的某些事情时，会发现这样的问题:为了调试某个程序，会 dump 出一堆中间文件的 log，去查找哪些地方发生了异常。这种文件都是 tsv 文件，即使用 TAB 分割的列表文件。一种最简单的做法就是在文本编辑器中打开这些文件，然后通过观察去查看异常，可以配合编辑器的搜索功能。在这方面 sublime text 最为适合，因为只有这个能打开大文件。但是，这样每一次打开都需要很长的时间，而且我去搜索某个字符串的时候，每输入一个字符编辑器就会停顿很长时间。

于是我希望能有这么一种东西，对文本文件这种没有被某种结构化工具存储的、没有明确定义 schema 的东西进行快速的查找、计算。简单地借用 SQL 中的术语，我希望能在不导入数据的情况下进行 SELECT、 WHERE、 ORDER、 LIMIT、 JOIN 等基本功能。幸运的是，最近发现了以前打印出来一直都没看的讲义，一些最基本的 Unix command 就基本上涵盖了我所希望的对文本文件处理的功能。本文就按照这些 SQL 功能语句把这些命令进行梳理。

本文进行处理的数据对象是在 2 月用 Bangumi_Spider 爬取的 Bangumi Data，这包括用户、条目和收藏记录：

head user-2017-02-17T12_26_12-2017-02-19T06_06_44.tsv -n 5
head record-2017-02-20T14_03_27-2017-02-24T10_57_16.tsv -n 5
head subject-2017-02-26T00_28_51-2017-02-27T02_15_34.tsv -n 5

uid  name  nickname  joindate  activedate
7  7  lorien.  2008-07-14  2010-06-05
2  2  陈永仁  2008-07-14  2017-02-17
8  8  堂堂  2008-07-14  2008-07-14
9  9  lxl711  2008-07-14  2008-07-14
name  iid  typ  state  adddate  rate  tags
2  189708  real  dropped  2016-10-06
2  76371  real  dropped  2015-11-07
2  119224  real  dropped  2015-03-04
2  100734  real  dropped  2014-10-09
subjectid  authenticid  subjectname  subjecttype  rank  date  votenum  favnum  tags
1  1  第一次的親密接觸  book  1069  1999-11-01  57  [7, 84, 0, 3, 2]  小説:1;NN:1;1999:1;国:1;台湾:4;网络:2;三次元:5;轻舞飞扬:9;国产:2;爱情:9;经典:5;少女系:1;蔡智恒:8;小说:5;痞子蔡:20;书籍:1
2  2  坟场  music  272    421  [108, 538, 50, 18, 20]  陈老师:1;银魂:1;冷泉夜月:1;中配:1;银魂中配:1;治愈系:1;银他妈:1;神还原:1;恶搞:1;陈绮贞:9
4  4  合金弹头7  game  2396  2008-07-17  120  [14, 164, 6, 3, 2]  STG:1;结束:1;暴力:1;动作:1;SNK:10;汉化:1;2008:1;六星:1;合金弹头:26;ACT:10;NDS:38;Metal_Slug_7:6;诚意不足:2;移植:2
6  6  军团要塞2  game  895  2007-10-10  107  [15, 108, 23, 9, 7]  抓好社会主义精神文明建设:3;团队要塞:3;帽子:5;出门杀:1;半条命2:5;Valve:31;PC:13;军团要塞:7;军团要塞2:24;FPS:26;经典:6;tf:1;枪枪枪:4;2007:2;STEAM:25;TF2:15

由于爬虫的性质，这些数据有以下缺陷：

非实时。我所说的“实时”并不是今天是 4 月 16 日而数据只是 2 月的，而是我无法保证数据是在某一个时间点上的快照。对于用户数据，由于爬取一次需要两天的时间，在这两天的时间里，可能用户修改了他们的昵称和用户名而在爬取的数据上未反映出来。更为严重的问题是，对于收藏数据，可能会出现在爬取数据的时候用户进行了收藏的操作，导致爬取的数据出现重复或缺失。而且由于用户数据和收藏数据是分开爬取的，我无法保证通过用户名能把两个 table 一一对应地 join 起来。
非顺序。可以从预览的数据中看到。
爬虫本身缺陷。由于我对于 Bangumi 出现 500 错误没有在处理上体现出来，所以会导致某些数据有所缺失。

在下面的文章里，我们将一边使用 Unix Command 对数据进行类似于 SQL 语句的操作，一边阐述 Bangumi_Spider 产生的 data 的各种特点和后续处理需要注意的问题。

1. SELECT … WHERE … ORDER BY …

筛选 2017 冬季番组

现在我们有了条目数据，而条目数据是记录了标签信息的，我们可以从标签信息中抽取出 2017 年冬季番组。这个标签是“2017 年 1 月”。我们可以用一个 grep 语句取出这些番组：

grep "2017年1月" subject-2017-02-26T00_28_51-2017-02-27T02_15_34.tsv | grep "anime" | wc -l

然而这个抽取方式有很大的缺陷。我们没有指定应该在数据的哪一列上查找“anime”或“2017 年 1 月”！如果有一部音乐条目的名字里面就有 anime 这个词，而又被打上了 2017 年 1 月的标签呢？这显然不是我们希望得到的。实际上，需要指定列的话，最好的方式就是使用 awk：

awk -F "\t" '$9 ~ /[;\t]2017年1月:/ && $4=="anime"' subject-2017-02-26T00_28_51-2017-02-27T02_15_34.tsv > anime_selection.tsv
wc -l anime_selection.tsv
head anime_selection.tsv -n 5

85 anime_selection.tsv
122772  122772  六心公主  anime    2016-12-30  26  [19, 41, 1, 1, 4]  17冬:1;原创:1;PONCOTAN:4;2016年:2;广桥凉:1;TVSP:1;池赖宏:1;原优子:1;mebae:1;TV:4;日本动画:1;片山慎三:1;Studio:1;STUDIOPONCOTAN:4;2016:5;TVA:1;短片:2;上田繁:1;搞笑:4;中川大地:2;岛津裕之:2;种崎敦美:1;2017年1月:1;テレビアニメ:1;オリジナル:1;SP:1;6HP:2;村上隆:10;未确定:1
125900  125900  锁链战记～赫克瑟塔斯之光～  anime  3065  2017-01-07  88  [66, 24, 216, 20, 60]  山下大辉:3;17冬:1;原创:1;游戏改:47;CC:1;花泽香菜:7;TV:22;未确定:2;グラフィニカ:2;佐仓绫音:4;2017年1月:61;锁链战记:1;2017:10;锁链战记～Haecceitas的闪光～:15;热血:2;チェインクロ:1;石田彰:22;声优:2;2017年:4;Telecom_Animation_Film:1;十文字:1;柳田淳一:1;战斗:2;内田真礼:2;剧场版:1;奇幻:17;2017·01·07:1;工藤昌史:3;2015年10月:1;TelecomAnimationFilm:9
126185  126185  POPIN Q  anime    2016-12-23  10  [134, 11, 3, 3, 0]  荒井修子:1;黒星紅白:4;原创:3;黑星红白:1;2016年:5;_Q:1;日本动画:1;2016年12月:2;未确定:1;小泽亚李:1;2017:2;2016:5;动画电影:1;2017年:5;Q:3;东映动画:1;种崎敦美:1;2017年1月:1;宫原直树:1;POPIN:6;東映アニメーション:12;剧场版:24;东映:4;萌系画风:1;濑户麻沙美:5
129805  129805  混沌子  anime  2910  2017-01-11  197  [264, 24, 764, 60, 67]  上坂すみれ:3;ブリドカットセーラ恵美:2;季番:2;黑暗推理向慎入:2;2016年:3;CHAOS:5;游戏改:67;SILVER_LINK.:2;悬疑:5;游戏:9;TV:73;未确定:9;伪:4;GAL改:106;2017:28;科幻:2;志倉千代丸:4;SILVERLINK.:34;SLIVERLINK.:70;2017年:10;志仓千代丸:4;2017年1月:170;5pb.:112;混沌子:3;反乌托邦:16;剧透禁止:27;极权主义世界:8;松冈祯丞:3;神保昌登:6;CHILD:5
131901  131901  神怒之日  anime    2017-10-01  0  [79, 1, 0, 3, 1]  GENCO:3;2017年10月:2;TV:4;未确定:2;2017年:2;GAL改:4;游戏改:4;LIGHT:2;2017:3;エロゲ改:3;2017年1月:1

可以看到，我们提升了一些 precision。awk 的思想就是把一个文本文件按行处理，然后在单引号里面对行进行编程。你可以看到，我们使用内部变量 $9 指定第 9 列的内容（你可以看到，是从 1 开始标号的），这一列是标签。我们使用正则表达式对 $9 进行匹配，正则表达式需要用斜杠包围。同时，我们指定第四列的内容是 anime。这样就可以将满足我们需求的条目筛选出来。顺便说一句，$0 是整行的内容。

按照在看人数排序

我们在条目中用一个数组记录了想看、看过、在看、搁置和抛弃的人数。这个数组用方括号所包围。我现在希望对我刚才抽取的冬季番组按照在看人数从大到小排序。这需要我们抽取出第八列，然后从该列中抽取出在看人数。使用以下命令可以达到我的目的：

awk -F "\t" '{match($8, /\[([0-9]+), ([0-9]+), ([0-9]+), ([0-9]+), ([0-9]+)\]/, m); printf("%d\t%s\t%s\t%d\t%d\t%d\t%d\t%d\n", $1, $3, $4, m[1], m[2], m[3], m[4], m[5])}' < anime_selection.tsv | sort -t$'\t' -k6,6 -nr | sed 5q

179949  小林家的龙女仆  anime  157  84  2065  19  46
185792  小魔女学园  anime  245  51  1471  30  29
174043  为美好的世界献上祝福！ 第二季  anime  297  63  1431  21  28
174143  人渣的本愿  anime  271  51  1381  60  133
188091  珈百璃的堕落  anime  126  46  1366  22  73

按照管道切割，第一个语句还是使用 awk，但是执行的功能不是筛选，而是构造新表。在这个构造新表的过程中，观看人数的抽取使用了 match 函数。被抽取的对象存储在变量 m 里，是 match 的第三个变量。第一个变量是目标匹配字符串，第二个变量是正则表达式。注意需要将匹配的对象用圆括号括起来。

awk 的函数有很多，具体的可以直接参考 awk 手册（我估计没人会看的）或是这里。很多都是 C 语言的内置函数。

对于排序功能我们需要调用 sort 命令。首先需要指定输入文件的分隔符（注意这里有点 hacky，必须是 -t$'\t'）。由于我们希望对在看人数从大到小排序，我们必须指定按照第 6 列排序，即 -k6,6。同时我们指定 -nr 表明视第六列为数字并倒序。

结果显示了在二月某个时刻收看番组的前五个。Very reasonable。

抽取标签列表

既然我们已经爬取了标签，能不能对爬取的标签列表进行展开？这时候要使用 awk 的 split 函数和 array 类型了：

awk -F "\t" '{split($9, tags, ";");for(i in tags){ split(tags[i], itm, ":"); printf("%d\t%s\t%s\t%d\n", $1, $3, itm[1], itm[2]);};}' < anime_selection.tsv | sort -t$'\t' -k1,1n -k4,4nr | head -n 20

122772  六心公主  村上隆  10
122772  六心公主  2016  5
122772  六心公主  PONCOTAN  4
122772  六心公主  STUDIOPONCOTAN  4
122772  六心公主  TV  4
122772  六心公主  搞笑  4
122772  六心公主  2016年  2
122772  六心公主  6HP  2
122772  六心公主  中川大地  2
122772  六心公主  岛津裕之  2
122772  六心公主  短片  2
122772  六心公主  テレビアニメ  1
122772  六心公主  オリジナル  1
122772  六心公主  17冬  1
122772  六心公主  2017年1月  1
122772  六心公主  mebae  1
122772  六心公主  SP  1
122772  六心公主  Studio  1
122772  六心公主  TVA  1
122772  六心公主  TVSP  1
sort: write failed: standard output: Broken pipe
sort: write error

由于标签列表是按照分号分隔的，我们首先使用 split($9, tags, ";") 把分割后的字符串存储在 array tags 里。接着在 for(i in tags) 里，i 实际上是 index，对于每一个 tag 我们再次使用 split，得到具体的 tag 和 tag 人数。可以看到，可以使用 C 语言的方式写 awk 的行处理逻辑。在写的时候是可以隔行的，虽然我都写在了一行。

在此之后，我们首先对条目的 id 排序，再在条目中对 tag 的标记人数排序。这里 sort 需要使用两个 -k 选项指定排序顺序。同时我们把 -nr 的条件写在每个排序列的后面，这样可以对列按照不同的排序逻辑排序。

2. Aggregation

计数

我们更为关心的是收藏数据中的一些统计数据，如平均分、活跃人数等。最基本的统计数据形式就是计数。虽然可以使用 awk 完成，但是这个比较特殊，有更为简单的方法。

比如说，我们想在上文抽取出来的冬季番组标签中统计每个番组会有多少标签。鉴于我们已经把标签对每个动画展开了，我们就可以对每个动画出现的次数进行统计，就可以得到该动画对应的标签数量：

cut -f1,2 < anime_taglist.tsv| uniq -c | sed 10q

     29 122772  六心公主
     30 125900  锁链战记～赫克瑟塔斯之光～
     25 126185  POPIN Q
     30 129805  混沌子
     11 131901  神怒之日
     30 143205  南镰仓高校女子自行车社
     29 146732  碧蓝幻想
     30 148037  伤物语III 冷血篇
     30 148099  刀剑神域：序列之争
     30 148181  飙速宅男 新世代

其中，cut 命令对我们抽取出来的标签列表的第一列和第二列单独取出，然后送给 uniq。 uniq 会对每行进行 de-duplication 的操作，并且加上 -c 的选项会给出每行出现的个数。在输出的内容中，第一列就是每个动画对应的标签数量。

需要重点强调的是，uniq 只能对已经排序的输入有效。

可以看到，在一个条目页面，标签数量最多只有 30 个。

最大、最小值

有时候我们会对列表的某几项求取最大、最小值。下面显示了如何求取每一部动画标记人数最多的 tag。当然，我们也是用 awk 完成的。

awk -F "\t" '$1!=prev {print $0; prev=$1}' <anime_taglist.tsv | sed 10q

122772  六心公主  村上隆  10
125900  锁链战记～赫克瑟塔斯之光～  2017年1月  61
126185  POPIN Q  剧场版  24
129805  混沌子  2017年1月  170
131901  神怒之日  GAL改  4
143205  南镰仓高校女子自行车社  2017年1月  34
146732  碧蓝幻想  A-1Pictures  38
148037  伤物语III 冷血篇  剧场版  80
148099  刀剑神域：序列之争  剧场版  87
148181  飙速宅男 新世代  2017年1月  36

请注意，受了 uniq 的启发，这里的处理也是需要输入已经排好序。

平均值

既然有了 awk，我们就可以做更多的复杂计算。这里我们用平均值举一个例子：我们希望对爬取的收藏记录挑出动画和有评分的，计算其平均值。我还是希望能在有序输入上计算，于是先生成有序输入：

sed 1d record-2017-02-20T14_03_27-2017-02-24T10_57_16.tsv | awk -F "\t" '$6 && $3=="anime"' | sort -k2,2n | cut -f7 --complement > anime_record.tsv
head anime_record.tsv

103122  2  anime  do  2012-10-18  9
103909  2  anime  collect  2012-11-06  8
104394  2  anime  collect  2012-12-28  9
110320  2  anime  collect  2012-12-11  10
112414  2  anime  collect  2012-12-26  7
118090  2  anime  collect  2013-01-31  7
125406  2  anime  collect  2013-03-04  8
165363  2  anime  collect  2013-10-10  6
183190  2  anime  collect  2014-02-01  8
207963  2  anime  collect  2014-07-21  8

然后按照下式计算每个动画的平均值，并把平均值从高到低排序。

awk -F "\t" '{cnt[$2]+=1; cum[$2]+=$6}; END {for(i in cnt){printf("%d\t%f\t%d\n", i, cum[i]/cnt[i], cnt[i]);}}' < anime_record.tsv | sort -t$'\t' -k2,2nr -k3,3nr | head

202419  10.000000  4
186960  10.000000  3
143694  10.000000  2
158396  10.000000  2
193619  10.000000  2
11121  10.000000  1
127124  10.000000  1
127125  10.000000  1
127597  10.000000  1
137405  10.000000  1
sort: write failed: standard output: Broken pipe
sort: write error

需要注意的是，这里又使用了 awk 里面的字典数据结构（associative array）。你可以看作是一个 python 里面的 dict。我们使用了两个变量：cnt 和 cum 存储每一个动画 id 的评分人数和评分总和。在最后，我们在 END 包围的代码块里面生成最后的结果。这时候 END 里面的语句是在文件遍历之后执行的。

3. Union, intersection and except

在用户记录中丢失的用户

在前文我们讲过，用户数据可能会因爬虫爬取时出现 500 错误而丢失，但是条目记录可能保留了这部分数据。而且，由于用户数据爬取的时间先于收藏数据，会出现用户在其间改了用户名、还有新的注册用户加入 Bangumi 等问题。这里我们试着查看有多少这类在用户数据中丢失的用户。

首先我们用用户数据生成用户 id 和 username 的列表：

sed 1d user-2017-02-17T12_26_12-2017-02-19T06_06_44.tsv| cut -f1,2 | sort -t$'\t' -k1,1n > user_list.tsv
tail user_list.tsv

321167  321167
321168  321168
321169  321169
321170  321170
321171  321171
321172  321172
321173  321173
321174  321174
321175  321175
321176  321176

还有条目数据中的用户列表：

sed 1d record-2017-02-20T14_03_27-2017-02-24T10_57_16.tsv | cut -f1 | sort -t$'\t' -k1,1 | uniq > record_user.tsv
head record_user.tsv

这实际上就是求 record_user 对于 user_list 中 user 的差集。如果是这样的话，我们可以使用 comm 命令：

cut -f2 user_list.tsv| sort | comm -13 - record_user.tsv > user_failure.tsv
head user_failure.tsv

comm 命令对每个文件的行操作，同时它的先验要求是文件已经排过序。它可以给出三列数据：仅在第一个文件中出现的行；仅在第二个文件中出现的行；在两个文件中同时出现的行。可以看出，这个就是求差集和并集的操作。通过指定 -13,我们指定只输出仅在第二个文件中出现的行，也就是在 user_list.tsv 中没有爬到的用户。

4. Join

获得收藏数据中的用户 id

在收藏数据中，我们记录下了用户的用户名，却没有记录用户 id 和用户昵称！这个是爬虫在设计时候的缺陷。这时候只能通过和用户数据 join 来弥补了。可是怎么在文本文件中进行 join 的操作呢？

首先，我们抽取两组数据：

sed 1d record-2017-02-20T14_03_27-2017-02-24T10_57_16.tsv| sort -t$'\t' -k1,1 > record.sorted.tsv
head record.sorted.tsv

100004  10380  anime  collect  2012-09-30  10  标签:;中二病;花泽香菜;嘟嘟噜;牧瀬紅莉栖;Steins
100004  10440  anime  collect  2012-10-02  9  标签:;あの日見た花の名前を僕達はまだ知らない
100004  10639  anime  collect  2012-10-02    标签:;虚渊玄;奈绪蘑菇;梶浦
100004  16235  anime  collect  2012-10-02  8  标签:;未来日记;我妻由乃
100004  18635  anime  collect  2012-10-02  7  标签:;罪恶王冠;泽野弘之
100004  23684  anime  collect  2012-09-30  9  标签:;黑子的篮球;基
100004  23686  anime  do  2012-10-01    标签:;刀剑神域;2012年7月;SAO;川原砾;梶浦由纪
100004  2453  anime  collect  2012-10-02  7  标签:;BRS;Black★RockShooter
100004  2463  anime  collect  2012-10-02  8  标签:;デュラララ!!
100004  265  anime  collect  2012-09-30  10  标签:;EVA;庵野秀明;神作;Evangelion;补完

sed 1d user-2017-02-17T12_26_12-2017-02-19T06_06_44.tsv| cut -f1,2,3 | sort -t$'\t' -k2,2 > user_list.sorted.tsv
head user_list.sorted.tsv

10  10  ＭｏＭｏ.
100  100  Jacob
10000  10000  漠漠
100000  100000  natalie_1204
100001  100001  七堂伽蓝
100002  100002  宇
100003  100003  二的二次方
100004  100004  从不卖萌的K
100005  100005  Astrid
100006  100006  tsiaben

需要注意的是，我们希望对用户的用户名进行 join，其前提是我们的列表需要对被 join 的列进行排序。我们已经在上面进行了对用户名列的排序操作。

接着，我们可以使用 join 了。我们可以首先进行 INNER JOIN：

# inner join
join -t$'\t' -1 2 -2 1 user_list.sorted.tsv record.sorted.tsv | wc -l

join -t$'\t' -1 2 -2 1 user_list.sorted.tsv record.sorted.tsv | sed 5q

100004  100004  从不卖萌的K  10380  anime  collect  2012-09-30  10  标签:;中二病;花泽香菜;嘟嘟噜;牧瀬紅莉栖;Steins
100004  100004  从不卖萌的K  10440  anime  collect  2012-10-02  9  标签:;あの日見た花の名前を僕達はまだ知らない
100004  100004  从不卖萌的K  10639  anime  collect  2012-10-02    标签:;虚渊玄;奈绪蘑菇;梶浦
100004  100004  从不卖萌的K  16235  anime  collect  2012-10-02  8  标签:;未来日记;我妻由乃
100004  100004  从不卖萌的K  18635  anime  collect  2012-10-02  7  标签:;罪恶王冠;泽野弘之
join: write error: Broken pipe

可以看到我们已经 join 了一些有价值的东西。被 join 的那个字段总是在第一列。

如果使用 LEFT OUTER JOIN 或是 RIGHT OUTER JOIN，我们需要用 -a 指定哪个文件需要全部输出：

# left outer join
join -t$'\t' -1 2 -2 1 -a 1 user_list.sorted.tsv record.sorted.tsv | wc -l

join -t$'\t' -1 2 -2 1 -a 1 user_list.sorted.tsv record.sorted.tsv | head

10  10  ＭｏＭｏ.
100  100  Jacob
10000  10000  漠漠
100000  100000  natalie_1204
100001  100001  七堂伽蓝
100002  100002  宇
100003  100003  二的二次方
100004  100004  从不卖萌的K  10380  anime  collect  2012-09-30  10  标签:;中二病;花泽香菜;嘟嘟噜;牧瀬紅莉栖;Steins
100004  100004  从不卖萌的K  10440  anime  collect  2012-10-02  9  标签:;あの日見た花の名前を僕達はまだ知らない
100004  100004  从不卖萌的K  10639  anime  collect  2012-10-02    标签:;虚渊玄;奈绪蘑菇;梶浦
join: write error: Broken pipe

# right outer join
join -t$'\t' -1 2 -2 1 -a 2 user_list.sorted.tsv record.sorted.tsv | wc -l

这里我们可以看到使用 RIGHT OUTER JOIN 的时候，对于没有被 join 上的用户就是在 user_list 中没有出现的用户。这时候没有被 join 上用户名和用户昵称的记录应该和 user_failure.tsv 的内容是一样的。

join -t$'\t' -1 2 -2 1 -a 2 user_list.sorted.tsv record.sorted.tsv | sort > record.complete.tsv
join -t$'\t' -1 2 -2 1 user_list.sorted.tsv record.sorted.tsv | sort > record.inner.tsv

comm -13 record.inner.tsv record.complete.tsv| cut -f1 | uniq | diff - user_failure.tsv

140d139
< sdf4
141a141
> sdf4

可以看到两个文件在实际内容上，除了顺序有所差别，并没有本质上的变动。这一定程度上证明了 JOIN 的正确性。

当然，我们既然有了 join，就会有人问怎么进行多个 column 的 join？遗憾的是，目前 join 只支持一列的 join。对于多列的 join 可以参考这个。

5. Conclusion and future plan for Bangumi Spider

依据现有的技术，我们可以通过配合 awk 与 sort 进行文本文件操作从而组合成各种我们想要的类似于 SQL 语句的功能，这个给我们线下调试带来了很大的方便。同时我们可以使用 cat、comm 达到交集、并集和差集的功能，使用 join 可以把两个文件通过指定的列 join 起来。在懒得使用 pandas 或数据库的时候，这些命令给我们带来了很大的方便。

同时，我觉得目前 Bangumi Spider 问题太多。我计划从一下方面入手将 Bangumi Spider 升级：

废除 user spider，更新 record spider 使之记录 user spider 目前所记录的所有信息，在爬虫结束任务之后，通过 raw record spider 生成 record 记录和 user 记录。后期处理还要力求 record spider 不能重复爬取条目。
修改 Bangumi Spider 对 Bangumi 主站 500 错误的处理。
保留 subject spider 的部分功能，特别是 infobox 那边的功能，去掉 tag 信息。 subject 要和 record 相 join 解决条目重定位的问题。

机器学习的疯狂三月——NCAA 男篮预测竞赛

Sat, 18 Mar 2017 00:00:00 GMT

这篇文章我们讨论 NCAA 一级男子篮球锦标赛的比赛结果预测。这同样是一个 Kaggle 例行举行的算法竞赛。这篇文章所要讲的就是我的解题思路。不过鉴于这是赛前预测，真正的结果需要到四月才能得知，众看官在察觉这是一口毒奶之后大可拿真正比赛结果打我脸。

数据

这个算法竞赛给出了如下数据：从 1985 年到 2017 年所有常规赛季的得分记录和 2003 年到 2017 年所有常规赛季的详细记录。详细记录包括一堆复杂的篮球统计数字，由于敝人并不会打篮球所以也不知道中文翻译成什么合适。同时也包括 1985 年到 2016 年所有锦标赛季的得分记录和从 2003 到 2016 的锦标赛季详细。所要预测的是 2017 年进入锦标赛的所有 68 支队伍的所有可能组合的获胜概率——由于每一支队伍都已经标上了序号，预测的是每一对组合中序号较小的队伍的获胜概率。所以需要预测 $\frac{68 \times 67}{2} = 2278$ 种情况。该比赛的目标函数是使得比赛实际出现的组合的获胜情况的 log loss 最小。

LogLoss = - \frac{1}{n} \sum_{i = 1}^{n} [y_{i} \log ({\hat{y}}_{i}) + (1 - y_{i}) \log (1 - {\hat{y}}_{i})]

其中 n 是实际会发生的比赛的次数。

思路

由于我对体育比赛一无所知，经过论坛的讨论观察，我决定仅拿当年的常规赛季预测当年的锦标赛季结果。如果你去读了 NCAA 的比赛规则之后，你会发现一个最明显的 feature：seed。Seed 一定程度上包含了比赛队伍的排名强弱信息。在论坛里有人告诉我们，如果仅仅拿 seed 进行一个简单的预测：seed 小的一方必定会赢过 seed 大的一方，就已经能够得到 72.75% 的准确率了。然而 accuracy 与 logloss 还是有很大差别的，这个数字也只是给人们一个选取 feature 的直观感受而已。经过实验，如果单单使用两队 seed 之差一个 feature 进行 logistic regression 的 training，使用 2003-2012 的数据作为 training set，2013-2016 的数据作为 test set，可以得到 0.62 左右的 logloss。（论坛里有人拿到了 0.55 左右的 logloss，这是事后预测结果，不可应用于事前预测。）

当然这个结果就是给人保个底。之后就可以在这个基础之上进行模型增强了。经过多方挖掘，我又发现了一些奇妙的统计数据：Four Factors of Basketball Success. 把这些 feature 加入之后，使用 LR 可以得到 0.60 左右的 logloss. 其实还可以自己造一些类似的 feature，比如说 $\frac{A s s i s t}{F G A + 0.44 \times F T A + A s s i s t}$ 。这些也有益于提升模型性能。但是这些提升聊胜于无，让我深感失望。

我决定使用我写的无监督排序库 rankit 提升模型性能。在 rankit 里，我提供了 Massey rank, Colley rank, Point difference rank, Markov Rank, Offence-Defence rank 还有 Keener rank. 光是这些 rank 方法在得分上堆砌起来就能获得很多 feature 了。rating 比 ranking 能提供更多的信息，所以我使用两队的 rating 之差作为 feature. 至于 normalization, 我对每一个 feature 的 Cumulative distribution function 把所有 feature normalize 到 [0, 1]. 到这里，如果使用 MPN，可以获得 0.58 左右的 logloss.

然而 rankit 仅仅是对比赛得分进行排名，也太浪费了。我们有那么多统计数据，我们可以对那么多的统计数据每个进行一次 rating 的计算，可以得到更有价值的信息。如果我们对两支队伍的防守篮板进行 rating 计算，和对进攻篮板的 rating 计算在物理意义上就有防守能力与进攻能力的差别。于是我们可以把所有统计数据用所有可能的无监督排序方法计算一下 rating.

于是，最终使用的 model 采用了两类 feature：一种是统计数据的直接简单归纳，如篮板计算赛季均值，助攻计算赛季均值，加上上文提到的 Four factors of basketball success。还有一类 feature 则是对统计数据的无监督排序处理化。

那么，每一队都有了能够足够表示自己的 feature，是不是应该直接相减得到两队发生一次比赛的 feature，继而用这个 feature 训练一个 LR 或 GBDT 进行 classification 呢。事实上我用的是 CNN。为什么看上了 CNN 呢，我把表示一场比赛的 feature 组织成一个两行的矩阵，每一行就是描述一个队伍的 feature。如果你使用 CNN，你加一个卷积核在上面，你比使用两个 feature 直接相减有了更多的控制参数：至少对于两支队伍同一个 feature 你的特征抽取方式是 $c_{1} x_{1} + c_{2} x_{2} + c_{3}$ ，而如果使用 feature 直接相减就相当于 $c_{1} = - c_{2}$ ，少了模型的控制自由度。而且，我希望得到 feature 之间相互 cross 的效果，使用一种连接主义模型就能得到这样的效果。当然有人就会说了，你这样会不会有过拟合啊，因为你这个模型复杂度太大了。事实上，我的实验表明使用一个很简单的四层神经网络（输入层，卷积层，全连接层，输出层）就能很好地得到我的效果，而且比 GBDT （使用 xgboost 和 lightgbm 做的实验，feature 是两支队伍的 feature 相减）要好。

这个模型的代码在这里。

坑

我一开始的设想还是 feature cross，也就是构造一些队伍之间相互交互的 feature 达到更加细粒度的队伍实力描述，然后我发现这个甚至不如直接使用 seed delta train 一个 lr. 我认为其主要原因是训练数据太少：由于是对锦标赛进行预测，而可用的训练数据也只有两千多个，我用一个十万维度的 model 能 train 出什么东西来？

后续工作

现在的 rankit 非常难用，连我用的时候都不得不去查看源代码确认用法或是确认是否已经添加了我希望的功能。我希望今年的锦标赛结束之前能把 rankit 升级到 0.2.

另外，我在上文说过，我仅仅使用当前赛季的常规赛比赛情况预测锦标赛比赛情况。但是一直队伍在历史上的长期表现应该也会对该季锦标赛产生影响，但是我没有做。使用历史数据的麻烦就在于生成特征需要一年一年地生成，sequentially.

此外，论坛中也有提到使用 elo 评分作为特征。Elo 评分体系是一个重要的体系，却没有被加入 rankit。在比赛最后两天我试图实现这个，但是时间太少，就没有做。这也是一个待办事项。

Max flow, minimum cut

Tue, 11 Oct 2016 00:00:00 GMT

在微软苏州已经入职了一个月了，生活开始渐渐稳定下来。和在北京的各种不堪相比，我要感谢这次调职，得以让我从 easy 模式开始社畜生活。同时搁置好久的算法又可以得以继续研究下去了。

今天讲的算法是最大流最小割算法。实际上这个是我在《算法导论》上看来看去都看不明白的一个章节：术语太多，而且代码很少（我好菜啊）。幸运的是，hihoCoder 上面的一系列专题为我垫了不少砖头，让我得以掌握这一块知识。

对于一个最大流问题，其定义一般都是这样的：有一个有向图 G，源点为 s，汇点为 t，每条边都有其对应的流最大容量 c，源点 s 只有发出的流量，汇点 t 只有汇入的流量，求能从源点到汇点的最大可能流量。

那么，我先不想说证明过程，我直接给出结论：我们用一种反复查找的方法，试图在当前图 G 上找到一条从 s 到 t 的路径，其边上允许的流量非零。每次找到这一条路径之后，也就可以确定这条路径上的流量瓶颈，将路径上的边的可行流量减去这一流量瓶颈，在新图上进行下一次查找。我们一直持续这样的查找，直到无法从 s 到 t 走出一条流量瓶颈大于 0 的路径。这个算法叫做 Ford-Fulkerson 算法。这个查找方式可以使用 BFS 进行。

嘛，基本上就是这样。但是由于图中可能会存在反向边，对于我上面讲的这个情况，对于下面这种情况是不成立的：

An tricky example of flow network

如果我们用 BFS 找到了 A-B-D-F 这条可行路径，其瓶颈是 3，减去该瓶颈之后无法找到更新的路径。然而其最大流是 5：由 B 分出的流量有一份到 D，另外两份到 E，然后 A-C-D 有一个流量为 2 的路径。这时候，我们需要一个“残余网络”的概念帮助我们解决这个问题：每条边维护一条对应的反向边，其大小为当前在正向上面已经消耗掉的流量，而正向边的容量为当前正向剩余的可行流量。换句话说，正向边和反向边的存在，帮助我们维护了每条边还有多少剩余流量可用。如果有一条流量容量为 1 的边，其正向流量为 1000000，反向流量为 999999，这也是可行的！我们在残余网络上找到的一条可行路径，叫做增广路径。于是我上面描述的算法可以如下表达：

While ( findAugmentPath() ) // 判断是否有增广路
  maxFlow = maxFlow + delta // 最大流增加
  modifyGraph() // 对增广路进行修改
End While

与最小割的关系

我们通常说 max flow, minimun cut。那么什么被定义为 cut？在一个带有 s 和 t 的网络流里，有一种划分把点划分到两个不相交的 S 和 T 集合中， $s \in S, t \in T$ . 净流 f(S, T) 被定义为穿过割 (S, T) 的流量之和（当一个割经过反向边的时候，反向边上的流量应为负值）。割的容量 C(S, T) 被定义为这条割上所有的容量之和（不包括反向边）。也就是说， $f (S, T) \leq C (S, T)$ 。可以证明，当前网络的流量总是等于任意一个割的净流。但是，任意的割不会有相同的容量。其中最小的那个割的容量对应的割，我们称之为最小割。

现在有一个结论：对于任意网络流图来说，最大流一定等于最小割的容量。这个结论是最大流最小割定理的直接推论，这个定理由三个等价的表达组成：

f 是网络的最大流；
该网络的残余网络不包含任何增广路径。
流网络的某个切割 (S, T) 的容量等于 f。

因此，求出了最大流，也就求出了最小割的最大容量。使用上文所提及的 Ford-Fulkerson 算法，能够快速算出割、网络流量。

Production Code

使用 BFS 进行每次增广路径查找的 Ford-Fulkerson 实现叫做 Edmonds-Karp 算法。由于 BFS 时间复杂度（约）为 O(E)，流量递增操作的总次数为 O(VE)，该算法的时间复杂度为 $O (V E^{2})$ 。这并不是最快的算法。现在有一种算法，通过记录每个点到汇点 t 的最短距离维持搜索顺序，使用 DFS 的方法进行增广路径的查找，能大大降低时间复杂度。这一算法的代码如下：

// 本代码对应于 http://hihocoder.com/problemset/problem/1369
#include <cstdio>
#include <cstring>
#include <queue>

const int inf = 0x3f3f3f3f;
const int maxn = 505, maxm = 40005;
int N, M;

typedef struct {
  int u, v, c, prev;
}edge_t;
int head[maxn];
edge_t edges[maxm];

int source, sink;
int dep[maxn], depcnt[maxn], cur[maxn], stack[maxn];

void addedge(int u, int v, int c) {
  static int id = 0;
  edges[id].u = u; edges[id].v = v; edges[id].c = c; edges[id].prev = head[u]; head[u] = id++;
  edges[id].u = v; edges[id].v = u; edges[id].c = 0; edges[id].prev = head[v]; head[v] = id++;
}

void bfs() {
  memset(dep, 0xff, sizeof(dep));
  memset(depcnt, 0, sizeof(depcnt));
  dep[sink] = 0;
  depcnt[dep[sink]] = 1;
  std::queue<int> Q;
  Q.push(sink);
  int u, v;
  while (!Q.empty()) {
    u = Q.front();
    Q.pop();
    for (int e = head[u]; ~e; e = edges[e].prev) if (edges[e].c == 0 && dep[edges[e].v] == -1) {
      v = edges[e].v;
      Q.push(v);
      dep[v] = dep[u] + 1;
      depcnt[dep[v]]++;
    }
  }
}

int SAP() {
  bfs();
  memcpy(cur, head, sizeof(head));
  int u = source, maxflow = 0, top = 0, i;
  while (dep[source]<N) {
    if (u == sink) {
      //find the bottleneck
      int delta = inf, p;
      for (int t = top - 1; t >= 0; t--) {
        int e = stack[t];
        if (edges[e].c<delta) {
          delta = edges[e].c;
          p = t;
        }
      }
      for (int t = top - 1; t >= 0; t--) {
        int e = stack[t];
        edges[e].c -= delta;
        edges[e ^ 1].c += delta;
      }
      maxflow += delta;
      top = p;
      u = edges[stack[p]].u;
    }
    for (i = cur[u]; ~i; i = edges[i].prev) {
      if (edges[i].c>0 && dep[edges[i].v] == dep[u] - 1) {
        cur[u] = i;
        u = edges[i].v;
        stack[top++] = i;
        break;
      }
    }
    if (i == -1) {
      depcnt[dep[u]]--;
      if (depcnt[dep[u]] == 0) break;
      int mindep = N;
      for (int e = head[u]; ~e; e = edges[e].prev) {
        if (edges[e].c>0 && mindep > dep[edges[e].v]) {
          mindep = dep[edges[e].v];
          cur[u] = e;
        }
      }
      dep[u] = mindep + 1;
      depcnt[dep[u]]++;
      if (u != source) {
        u = edges[stack[--top]].u;
      }
    }
  }
  return maxflow;
}

int main() {
  freopen("testcase", "r", stdin);
  scanf("%d%d", &N, &M);
  source = 1, sink = N;
  memset(head, 0xff, sizeof(head));
  for (int i = 1; i <= M; i++) {
    int u, v, c;
    scanf("%d%d%d", &u, &v, &c);
    addedge(u, v, c);
  }

  printf("%d\n", SAP());
  return 0;
}

嘛，这个优化后的算法叫什么我也不知道，我只是从别人的解法里学习过来的。但是这个代码做了至少这么几个工作：

在进行 DFS 寻找增广路径之前用 BFS 从汇点搜索建立 dep 和 depcnt，即到汇点的最短距离，这样为在 DFS 的时候总是走最短路径提供了依据。
正向边和反向边成对存储，索引为偶数的总是正向边；正向边和反向边可以通过索引的异或切换；
stack 里面存储通过 DFS 寻找的增广路径。
在每一次 DFS 寻找过后，回溯到瓶颈路径的起点重新搜索，节省时间；
维护一个 cur，其在物理意义上与 head 相同，也是为了直接从当前的可行边搜索，节省时间；
但是如果从某点找不到可行边，需要更新该点的 dep 与 depcnt。这也就意味着 cur 也要更新。

就是这样！但是有的文献指出，第一步建立 dep 与 depcnt 可以不进行。这主要的实现参考 http://hihocoder.com/contest/hiho117/solution/898175。

主要参考文献：

hihocoder hiho一下 115、116、117、118、119 周
《算法导论》（第三版）第 26 章
Max Flow-SAP-Improved Shortest Augmenting

滴滴算法大赛总结

Sat, 18 Jun 2016 00:00:00 GMT

滴滴算法大赛是一场旨在预测城市交通供给需求不平衡程度的机器学习比赛。这个比赛的赛题是给定待预测的时间节点，预测整个城市在不同区块中需求与供给的差异 gap. 最终的比赛衡量方式是

M A P E = \frac{1}{D} \sum_{d = 1}^{D} (\frac{1}{T} \sum_{t = 1}^{T} ∣ \frac{g a p_{d t} - s_{d t}}{g a p_{d t}} ∣) \forall g a p_{d t} > 0

在比赛中，D = 66，T = 144. 官方给出的训练数据有前三个星期的全部订单，天气和路况描述，区块属性描述。

我对该大赛的代码在这里。下面我来描述一下我的解决方案。

特征提取

在这场比赛中我只使用订单的训练数据，无视天气、路况和区块属性数据。理由是天气、路况和区块属性最终还是会反映在订单上面。所以着重描绘订单反映的特征就可以了。我提取了如下八类特征，全部以 one-hot coding 方式呈现：

订单所处时间是哪一小时（24维）
订单时间是否为双休日（2维）
订单地点在哪一区块（66维）
7 天前同一时间槽供求状况（21维）
订单所处时间的前一时间槽供求状况（21维）
订单前两个时间槽组合供求缺口状况（49维）
订单前三个时间槽的平均缺口状况（7维）
订单前三个时间槽的缺口标准差状况（3维）

“时间槽”是赛题预先定义的把一整天时间划分为 144 个时间片的每一个时间片。为了用 one-hot coding 的方式描述供求，我使用如下的方式重新定义 gap：将 gap 以 [0,0],(0,1],(1,3],(3,6],(6,12],(12,30],(30, $+ \infty$ ) 划分，形成 7 维特征。同时将需求（也就是客户发单数）以 [0,10],(10,20],(20, $+ \infty$ ) 划分，形成 3 维特征。对于 21 维的“供求状况”，则使用 2d feature 的方式将两个特征相组合。对于“缺口状况”，则是将两个 gap 以 2d feature 的方式相组合，形成 49 维特征。对于缺口的标准差，则使用 [0,1],(1,5],(5, $+ \infty$ ) 划分，形成 3 维特征。

但是这是远远不够的。比如说，我们想要设计的特征，能够包含一个区块在不同时间槽上的变化，这时候就必须结合时间特征和区域特征做二维特征。于是可以对所有这八类特征相互组合形成二维特征，最终形成一个一万多维的、非常稀疏特征。如果这时候按照这个特征训练一个线性回归模型，可以在测试集上面达到 0.32-0.34 的结果。但是实际上在应用的时候，并非八种特征完全相互组合，而是选取有物理意义的组合，以减少参数个数。代码中通过使用矩阵作为 mask 指定哪几类特征组合是被允许的。

我们还有一维特征，使用量的大小而非 one-hot coding：训练一个线性回归模型，预测的结果形成最后一维特征。这个特征也可以与先前的八类特征相互组合形成二维特征。

建模

一开始我使用 scikit-learn 的线性回归模型建模的，但是这个库可能偏离了实用性。对于稀疏的 feature，我非常希望能有一范数做正则项，但是 scikit-learn 里面没有一个模型是符合我的要求的。而且，对于题目中要求的 metric，最好是对每一个训练样本进行 $\frac{1}{g a p_{d t}}$ 的加权。并不是所有的模型在 scikit-learn 里面都有加权的选项。

其实最好的工具是 xgboost。这是一个基于残差迭代方法的、专门应用于机器学习竞赛的库。通过使用基于 GBDT 的回归模型，可以达到 0.29 左右的结果。需要指出的是，我发现三次残差迭代的效果是最好的，几乎颠覆了我以前对 GBDT 的印象。

训练

我选取了元月 4 日、9 日、17 日、19 日和 21 日的全天数据作为 validation，其余的去除元月 1-3 日的数据作为 training. 同时复制 10 日和 16 日的记录一遍。

需要指出的是，在训练的时候要去除 gap=0 的数据，因为这些数据对评价标准没有任何影响（如果真的像评价标准那样定义的话）而且还会对模型产生 bias。

可能存在的问题

先前有报导显示，直接下载提交的测试文件就能达到 0.6 的 level，而按照定义，这样的测试文件应该生成 1 的 MAPE。可能我在我的 MAPE 计算程序里面有与官方理解不一致的地方。

总结

我原来以为这个题目还是比较简单的，因为就是一个纯纯的监督学习问题。但是我发现我与最高水平的差距还是挺大。不论是实力还是客观条件方面都与别人的队伍有着较大的差距。最为愤怒的是，在前一天我在知乎上面看到有人说使用前三个时间槽的 gap 进行加权平均就能达到 0.29 的结果，我非常愤怒。我为了达到这个值花了这么多时间和精力，竟然还不如别人这么简单的无脑方法？？？如果能有更多的人和我团队合作，我们的思路就会越来越开阔，不至于像我走这种死胡同。

而且，我并非从一开始就参加这个竞赛，而是在硕士学位答辩完成之后才想着去“玩一玩”的。先前看到过 @haruki_kirigaya 也在玩这个（不过我要说，我没有看任何人的代码）。第一次提交是在 6 月 9 号，只有十次提交机会，而且中间还换了一次数据。不过，借口是无穷多的，实力的差距是绝对的。这也是我参加的第一次机器学习竞赛。我上次看到一个 Bangumi 上的人 fo 了我（我这种弱渣垃圾有什么好 fo 的），人家声称坚持打过每一场 Kaggle 竞赛，我真是无地自容。还是看书去吧。

使用 rankit 构建更科学的排名

Fri, 05 Feb 2016 00:00:00 GMT

rankit 是一个使用线性代数和最优化理论为基础的常见排名算法库。这个库是我写的。我说“常见”其实对于绝大部分人来说根本就闻所未闻，但是对于专门研究排名的研究者来说，这里面包含的算法都是比较基础的。自从阅读了一本介绍排名的书籍《谁排第一？关于评价和排序的科学》之后，我觉得很有必要把这里面的宝藏介绍给对此一无所知的研究者。作为一个做与机器学习相关研究的研究生，竟然除了 PageRank 和 HITS 其他排名算法一个都没有听说过——课上不教，研究也涉及不到——因为生活中应用这些排名算法的场景，实在是很少接触到。然而，这些排名算法正在美国的体育比赛排名中大行其道。在那本书中，大部分案例直接来源于美国的橄榄球比赛排名。

然而要我把这本书里面所有的算法都介绍出来，实在是一件难事，一是有侵犯版权的嫌疑，二是其中涉及到大量的数学推导。我在此也只能简单地说一下。每一个排名（rank）由一个既定的评分（rating）产生，评分可以被解释为被排名对象的实力。在一定数学模型的指导下，被排名对象产生了比赛结果。这时候，可以看作 rating 这一因素导致了外在的比赛结果的观测值，这和 state 与 observation 的关系是一样的。根据不同的数学模型，就有了不同的 rating 算法。另外还有一个排名算法不依靠于 rating 数值，它试图给出一个 ranking，使得该排名与比赛的结果最为相符，说白了就是 linear ordering problem.

那么这种排名算法对我们有什么启示呢？现实生活中好像没有多少排名问题能够用被排名对象之间的比赛来表达啊。搜索引擎的网页排名能用 in-link 和 out-link 表达网页之间的关系，但是网页之间怎么进行比赛呢？事实上，这本书能够拓宽人的眼界的地方就在于此。如果在一个网页排名结果中，网页点击量的大小可以视作在这一场比赛中的结果。网页流量的大小也是网页实力的一个外在特征。在商品排名中，同时购买两件商品的人的评分综合也可以被视为两件商品比赛的结果。事实上，我们应该抛弃“比赛”这种概念，对两个排名对象在同等条件下比较的结果进行 fitting 要远远稳定于计算一个平均分，或是加权平均的结果。

小白怎样使用 rankit？

rankit 提供了 Converter，只要用户能提供排名对象的每一轮的比赛结果（用 pandas.DataFrame 表示并包含特定的 columns），就能够为后续的算法计算出矩阵。在不同的数学模型下，需要的观测值就会有所不同。每一个算法都有它的物理意义，那么使用某一个算法要使用与其物理意义相对应的矩阵。比如说对于 MarkovRank 来说，这种算法需要表示排名对象之间相互投票的结果。我在 rankit 里面专门提供了 RateDifferenceVoteMatrix，SimpleDifferenceVoteMatrix 和 RateVoteMatrix 把观测到的评分结果表示成这样的矩阵。对于算法适用于什么样的矩阵这个问题，我在 rankit 的 GitHub 主页上面已经给出了参考表格。

rankit 还提供了排名融合的算法，排名融合能够使多种算法的排名更加稳定。用户也可以自行构建排名加入排名融合器，生成融合后的排名。另外，如果要比较排名之间的结果，rankit 还提供了两种测度描述排名列表之间的差距。

尽管我接口做得比较人性化了，我还是希望有一定背景知识的人去操纵这些算法。

为 Bangumi 动画排名！

长久以来，Bangumi 用户对 Bangumi 的动画排名争论不休[1][2]。由于 Bangumi 网站的高质量，某些别有用心人士试图通过刷分提高某些动画的排名或降低某些动画的排名，达到自己不可告人的宗教和政治目的[3][4][5]。除此以外，有用户建议使用更为细致化的排名系统[6][7]，但是所有这些讨论都没有超出统计学的范畴，最多也只是在平均分上做些加加减减，或是玩一些加权的把戏。一个综合的讨论收录可以参考[8].

我们提出了一种全新的基于不同数学模型的排名方法，这些排名方法通过比较每两部作品的表现评分。同时看过两部作品的用户，我们可以计算他们为这两部作品评分的算术平均分、对数几何平均分和倾向性概率，从而生成三种作品间两两比较的实力数据。接着，对于每一种生成方法，我们使用八种不同的算法对作品进行排名。这些排名算法由 rankit 提供技术支撑。对于生成的 24 种排名，我们使用 Borda Count 融合所有排名，生成最终的动画排名。这 8 种算法分别是：

Colley Rank (colley)
Massey Rank (massey)
Difference Rank (differ)
Markov Rank, using rate vote matrix as input (markov_rv)
Markov Rank, using rate difference vote matrix as input (markov_rdv)
Markov Rank, using simple difference vote matrix as input (markov_sdv)
Offence-defence Rank (od)
Keener Rank (no bias) (keener)

使用基于算术平均的排名使用 ariavg 做前缀，使用基于对数几何平均的排名使用 geoavg 做前缀，使用概率的排名我们使用 prob 做前缀。我们把最后的排名记作 merged_rank，把 Bangumi 原始排名记作 bangumi_rank，并对每一对排名计算 Kendall Measure，我们得到以下矩阵：

Kendall Measure Matrix

如果两个排名的 Kendall Measure 等于 1，说明两个排名的相似度比较大。如果越趋近于 -1，则两个排名完全相反。从这张图我们可以看到，使用 Borda Count 后的综合排名与各大排名的 Kenall Measure 都比 Bangumi 原始平均分排名表现要好，这充分说明了我们排名的科学性。

下表是该综合排名拍出来的 Bangumi 已排名 3252 部动画的前 20 位对应的作品 id：

id	rank
253	1
326	2
324	3
265	4
237	5
321	6
6049	7
1728	8
110467	9
2907	10
340	11
839	12
1608	13
876	14
3302	15
238	16
2734	17
1428	18
120700	19
37460	20

如何在新算法下操纵排名？

每一种算法都有被攻克的那一天，在提出语义搜索引擎之前，Google 一直在与 SEO 做着猫鼠游戏。当然，我这种简单的排名算法就更容易被操纵了。

如果有用户进行刷分，而且每个小号只为一部作品刷分，那么我的排名算法能够阻止这种作弊行为。但是如果有用户进行刷分的小号对多部作品进行刷分，而且是为某几部作品评高分，而给某几部作品评低分，这样就会对排名算法产生影响。

当然，也存在着针对这种行为的对抗方式，我们只需要对 Keener Rank 进行一些修改就能使得排名不容易被这种作弊方法操纵。

而更为切实际的做法是，将人工排名与计算机排名相融合。在我看来，最为稳定的融合方式是 LeastViolatedMerge，但是这是一个 NPC 问题，目前还没有对 3000 部动画这种规模的 LeastViolatedMerge 解决方案。所以说越科学的排名需要消耗的资源也就越大。

欧拉回路

Sun, 28 Jun 2015 00:00:00 GMT

今天讨论的主题是一类问题，就是欧拉路问题。有两种欧拉路。第一种叫做 Eulerian path(trail)，沿着这条路径走能够走遍图中每一条边；第二种叫做 Eularian cycle，沿着这条路径走，不仅能走遍图中每一条边，而且起点和终点都是同一个顶点。注意：欧拉路要求每条边只能走一次，但是对顶点经过的次数没有限制。

满足什么性质的图才能有欧拉路？根据 wikipedia 对欧拉路的介绍：

在无向图中，所有顶点的度数均为偶，则存在 Eularian cycle；若有且仅有两个顶点的度数为奇，其余的都为偶，则存在 Eularian path；
在有向图中，所有顶点的入度数等于出度数，则存在 Eularian cycle；若有且仅有两个顶点：其中一个入度数比出度数大 1，另一个入度数比出度数小 1，其余的顶点入度数等于出度数，则存在 Eularian path.

另外我们还需要知道，对于那些 Eularian path，起点和终点分别在那两个度数为奇的顶点上（对于无向图）或是入度数不等于出度数的顶点上（对于有向图）。

然而知道这些并没有给我们带来多少实惠。因为我们除了判定一个图有没有欧拉路之外，更想找到其中的一条欧拉路径。于是这就是我们今天的重点：寻找欧拉路径的算法。

一个比较经典的算法是 Fleury 算法。Fleury 算法的思想就是：在过河拆桥之前，先想想有没有退路。为什么这么说？Fleury 算法每个回合进行到一个顶点上的时候，都会删除已经走过的边。在选择下一条边的时候，不应该出现这样的状况：在删除下一条边之后，连通图被分割成两个不连通的图。除非没有别的边可选择。该算法从一个奇度数顶点开始（若所有顶点度数均为奇，则任选一个顶点）。当所有的边都走完的时候，该算法结束，欧拉路径为删除路径的顺序。用算法伪代码描述就是：

v_0 <- a vertex with odd degree or, if no such vertex, any arbitrary vertex.
Repeat:
    select an vertex v_i+1 adjacent of v_i, which should not separate the graph or, the only adjacent vertex of v_i
    remove edge <v_i, v_i+1> and jump to v_i+1
Until all edges have been visited.
Return the sequence of visited edges.

但是该算法的问题就是，怎么判断一条边是否是一个桥呢？如果使用 Tarjan 算法判断，则算法运行时间就是 $O (E^{2})$ 。在实际写代码的时候，我可没考虑那么多。我只考虑，如果在某一点处深搜的结果导致图被分离，那么在某一个边必然走过了一个桥，那么就返回走另一条边。这样的思想形成的算法如下：

#include <cstdio>
#include <stack>
#include <iostream>
#include <string>

using namespace std;

int G[1001][1001];
int N,M;
stack<int> S;

bool dfs(int u){ //返回的状态说明是否走过了一个桥
    S.push(u); //进入某一节点时推入节点，如果误入歧途还要负责弹出。
    if(G[u][0]==0){ //G[u][0]代表该节点所邻接的边的数目。此段代码判断是否走完了所有边，或者没有走完。
        bool flag=true;
        for(int i=1; i<=N; i++){
            if (i==u) continue;
            flag=((G[i][0]==0) && flag);
        }
        if(flag==false){
            S.pop();
        }
        return flag;
    }

    for(int v=1; v<=N; v++)
        if(G[u][v]){
            //删除边
            G[u][v]-=1;
            G[v][u]-=1;
            G[v][0]-=1;
            G[u][0]-=1;
            if(dfs(v)) return true;
            else{//撤销删除边
                G[u][v]+=1;
                G[v][u]+=1;
                G[v][0]+=1;
                G[u][0]+=1;
            }
        }

    S.pop();
    return false;
}


int main(){
    freopen("testcase", "r", stdin);
    cin>>N>>M;
    int u,v;
    for(int i=0; i!=M; i++){
        cin>>u>>v;
        G[u][v]+=1;
        G[v][u]+=1;
        G[u][0]+=1;
        G[v][0]+=1;
    }
    //寻找起点
    for(u=1; u<=N; u++){
        if(G[u][0]&1) break;
    }
    if(u==N+1) dfs(1);
    else dfs(u);
    while(!S.empty()){
        cout<<S.top()<<" ";
        S.pop();
    }
    cout<<endl;
    return 0;
}

View original gist

粗略分析一下，由于算法要经过每条边，所以时间必然是 $Ω (E)$ 。在最坏情况下，在每个节点处进行一次 DFS，节点会重复走所以以边计算，所以算法复杂度应该是 $O (E (E + V))$ 。

另一种计算欧拉路的算法是 Hierholzer 算法。这种算法是基于这样的观察：

Hierholzer

在手动寻找欧拉路的时候，我们从点 4 开始，一笔划到达了点 5，形成路径 4-5-2-3-6-5。此时我们把这条路径去掉，则剩下三条边，2-4-1-2 可以一笔画出。

这两条路径在点 2 有交接处（其实点 4 也是一样的）。那么我们可以在一笔画出红色轨迹到达点 2 的时候，一笔画出黄色轨迹，再回到点 2，把剩下的红色轨迹画完。

由于明显的出栈入栈过程，这个算法可以用 DFS 来描述。

DFS(u):
  While (u存在未被删除的边e(u,v))
    删除边e(u,v)
    DFS(v)
  End
  PathSize ← PathSize + 1
  Path[ PathSize ] ← u

如果想看得更仔细一点，下面是从点 4 开始到点 5 结束的 DFS 过程，其中 + 代表入栈，- 代表出栈。

4+ 5+ 2+ 3+ 6+ 5+ 5- 6- 3- 1+ 4+ 2+ 2- 4- 1- 2- 5- 4-

我们把所有出栈的记录连接起来，得到

5-6-3-2-4-1-2-5-4

诸位看官可以自己再选一条路径尝试一下。不过需要注意的是，起始点的选择和 Fleury 要求的一样。

这个算法明显要比 Fleury 高效，它不用判断每条边是否是一个桥。我写的代码如下：

#include <cstdio>
#include <stack>
#include <iostream>
#include <string>
#include <vector>

using namespace std;

int G[1001][1001];
int N,M;
stack<int> S;

void dfs(int u){
    for(int v=1; v<=N; v++)
        if(G[u][v]){
            G[u][v]-=1;
            G[v][u]-=1;
            dfs(v);
            //不用恢复边！
        }
    S.push(u);//出栈时记录
}


int main(){
    freopen("testcase", "r", stdin);
    cin>>N>>M;
    int u,v;
    vector<int> cnt(N+1,0);
    for(int i=0; i!=M; i++){
        cin>>u>>v;
        G[u][v]+=1;
        G[v][u]+=1;
        cnt[u]^=1;
        cnt[v]^=1;
    }
    for(u=1; u<=N; u++){
        if(cnt[u]) break;
    }
    if(u==N+1) dfs(1);
    else dfs(u);
    while(!S.empty()){
        cout<<S.top()<<" ";
        S.pop();
    }
    cout<<endl;
    return 0;
}

View original gist

需要注意的是这个算法时间复杂度是 $O (E)$ 。其在 DFS 的过程中不用恢复边，靠出栈记录轨迹。

Fin

（本文大量论述受到 hihocoder week 49, 50 和 51 启发。代码所解决的题目为 http://hihocoder.com/contest/hiho50/problem/1）

分解质因数

Mon, 25 May 2015 00:00:00 GMT

今天要说的题目来源于 Soldier and Number Game. 这道题到底干什么呢，说白了就是求两个数 $1 \leq b \leq a \leq 5000000$ 之间的所有数的质因数数目之和。快速求解一个数的质因数数目是这道题的关键。

Sieve of Eratosthenes 是这道题的关键。这是一个求解质数/质数判定的方法，其思想是筛选出一个质数的整数倍，质数的整数倍必然不是质数，所以都被筛选出去。在没有筛选的结果中继续求解当前最小数字的整数倍，直至筛完为止。其 C++ 代码如下所示：

// prime number table from 2 to 5000000
// those who have number 0 are prime numbers.
int table[5000001];
void build_table(){
    const int limit = sqrt(5000000)+1;
    table[0]=table[1]=-1;
    for(int i=2; i<=limit; i++)
        if(!table[i])
            for(int j=2; j*i<=5000000; j++)
                table[i*j]=i;
}
int isprime(int i){return !table[i];}

你可以发现，在这个质数表中实际上还存储了每个数字的一个质因数。要提取出一个数的完整质因数分解，只要依据~~基本法~~a/=table[a]不断迭代就可以了。

但是如果按照这样的思路去数每个数的质因数个数的话，在原题中还是会超时。其一个原因是我们要求的是质因数的个数，其可以在建立质数表的时候完成。其二，求从 a 到 b 中每个质因数的个数之和，倾向于使用部分和的方法。

那么怎么求每个数的质因数个数呢，在 Sieve of Eratosthenes 的基础之上？

void build_table(){
    //const int limit = sqrt(5000000)+1;
    //table[0]=table[1]=-1;
    for(int i=2; i<=5000000; i++)
        if(!table[i])
            for(int j=i; j<=5000000; j+=i)
                table[j]=table[j/i]+1;
}

Combination Sum

Sun, 26 Apr 2015 00:00:00 GMT

Combination sum 1 and 2 是 Leetcode 上面两道比较相似的题目。今天写这个题目是因为这个题目有不同的解法。

这两道题目都是给定一组数，给定一个 target，然后求出这组数中哪几个可以组合成 target。不同的地方是，第一道题要求数字可以被重复利用以组合成 target；第二道题要求数字不可以被重复利用。Seems easy, hmm?

首先说说我的想法和做法。首先通过观察可以得知，求一个 target 的 combination 可以被拆分成给定某个已知数的剩下数值的 combination 的子问题。于是乎，可以在确定一个 candidate 的同时试图解决这个子问题，子问题应该返回一个所有解的列表，把该 candidate 加入所有解的尾部即可。

那么怎么选取 candidate 呢？我们可以先对原候选数组进行排序，从最接近 target 的最大数开始筛选 candidate。

但是这里面还有不少问题。在解决子问题的时候，父问题应该传递给子问题这样的信息，使得子问题在选择 candidate 的时候，不应该出现重复的解。比如说在数组[2,3,6,7]，target 为 7 的时候，当目前确定一个 candidate 为 2，子问题就是相同数组中 target 为 5 的问题。但是此时是否能选择 candidate 为 3 呢？这就与 target 为 7 时 candidate 选为 3 的时候相重复了啊。为了力避这种情况，我规定父问题必须传给子问题当前的 candidate，使得子问题在选择 candidate 之时永远小于父问题 candidate。

所以解决问题的代码如下：

class Solution {
public:
    vector<vector<int> > combinationSum(vector<int> &candidates, int target) {
        sort(candidates.begin(),candidates.end());
        return dfs(candidates,target,INT_MAX);
    }
    vector<vector<int> > dfs(vector<int> &candidates, int target, int pred){
        vector<int>::const_iterator itr;
        vector<vector<int> > ans;
        itr = upper_bound(candidates.begin(), candidates.end(), target);
        if(itr==candidates.begin()) return ans;

        do{
            itr--;
            int t = *itr;
            if(t>=pred) continue;
            if(!(target%t)) ans.push_back(vector<int>(target/t,t));
            for(int i=1; i<=target/t; i++){
                vector<vector<int> > vst = dfs(candidates, target-i*t, t);
                for(size_t j=0; j!=vst.size(); j++)
                for(int k=0; k!=i; k++) vst[j].push_back(t);
                copy(vst.begin(), vst.end(), back_inserter(ans));
            }
        }while(itr!=candidates.begin());
        return ans;
    }
};

下面第二道题，第一道题之后应该不是什么难题，因为所有的数只能选择一次，所以在选择 candidate 的时候用不着去尝试多次选取的情况了。但是这里还有一个问题：位置不同、但是“看上去”结果相同的解被算作同一个！

为了优雅地解决这个问题，我规定在选取下一个 candidate 的时候，需要跳过与目前 candidate 相同的值。（注意第 22 行）

所以这个问题解决的代码如下：

class Solution {
public:
    vector<vector<int> > combinationSum2(vector<int> &candidates, int target) {
        sort(candidates.begin(), candidates.end());
        return dfs(candidates.rbegin(),candidates.rend(),target);
    }
    vector<vector<int> > dfs(vector<int>::const_reverse_iterator b, vector<int>::const_reverse_iterator e,
            int target){
        vector<int>::const_reverse_iterator itr;
        vector<vector<int> > ans;
        itr = upper_bound(b,e,target,greater_equal<int>());
        if(itr==e) return ans;

        while(itr!=e){
            int t = *itr;
            if(t==target) ans.push_back(vector<int>(1,t));
            vector<vector<int> > vs = dfs(++itr, e, target-t);
            for(size_t i=0; i!=vs.size(); i++){
                vs[i].push_back(t);
                ans.push_back(vs[i]);
            }
            while(itr!=e && *itr==t) itr++;
        }

        return ans;
    }
};

但是，以上这些方法都是沿用了 dfs 的思想。既然问题能被拆分为子问题，那么为何不用 DP？这当然是一个正当的思路。

我们记 target 从 0 到 target 的所有解的数组为 dp[target+1]，最终的结果就是要求 dp[target]。显然我们有 dp[target]=vector({itm.push_back(candidate) for itm in dp[target-i]})（抱歉这种不伦不类的语法）

但是状态转移方程还没有明确从哪里取得 candidate。其实只要从所有 candidate 里面一个一个抽取出来就可以了。

所以说解决第一题的伪代码如下：

dp[0]=vector<vector<int>>()
for c in candidates:
    for j in [c, target]:
        如dp[j-c]非空：
        dp[j] = 把dp[j-c]中的每一个解都push_back一个c

对于第二题用 DP 的话必须配合 Hash set。

另外，您发现了，用 dp 解的话与背包问题（0-1背包和可重复背包）有什么相似之处吗？

How I build up Chi: 同步率改 v0.3 实现细节

Sun, 08 Mar 2015 00:00:00 GMT

我想我已经好久都没写日志了，因为每天都会学到太多的新东西，虽然想记录下来，但实在是有心无力——太耗时间。不过我想仍然有里程碑意义的成果必须记录下来。这个同步率改 v0.3 就是一个。

　　Bangumi 番组计划有一个可以内置的查看用户间同步率的功能，但是这个功能很简陋，也很不科学。我通过爬取 Bangumi 用户作品收藏信息，计算出了比较科学一点的同步率，使得品味相近的用户可以互相认识。

　　稍有常识的人就会看出，这实际上就是一个推荐系统嘛：推荐与你相似的用户。但是目前的同步率改不能完全算是一个推荐系统，只能说起到了某些推荐系统的功能而已。现在的“同步率改”之所以还保留着“同步率”的称法，是为了让 BGMer 在旧同步率和新同步率之间保持无缝概念接受：如果我没有标注某部作品，那么这部作品不应该在同步率上有所贡献。所以在到目前为止，所有的同步率计算都是在作品空间中进行的而非概念空间。

　　同步率改的 v0.2.1 版是一个比较基本的推荐系统实现：提取用户的所有评分并减去其平均值，得到用户对作品的偏好程度。同时对于用户没有评分的作品，利用这个作品所处于的五个状态——想看、在看、看过、搁置和抛弃——加上一定评分偏置。同时为了防止只有很少评分的用户影响系统表现，系统做了不少 trick，如评分在标准差在零点几以下的用户同步率无视评分、收藏小于 3 的用户无视评分等。这样的设计方法虽然整体思路是正确的，但是存在 ad hoc 太多、评分偏置单一的现象。

　　同时，在 Bangumi 社区交流的过程中，我发现用户对于不同类型的作品评分有一定的独立性。对于动画和三次元的评分准则，有些用户将其与音乐、书籍类作品相独立看待。

　　基于这样的事实，我在 v0.2.1 的基础上进行了大量修改，其结果就是 v0.3。他们一脉相承的特点都是：相似度在作品空间中计算，每位用户的向量都以其自己平均分为基准，对已收藏但未评分作品根据作品收藏状态有一定偏置。但是 v0.3 使用了子空间分解技术估计用户已收藏和未评分作品的评分。同时，不同类型作品的同步率分开计算，最后整合在一起形成综合同步率。

评分估计模型

　　我们记 Bangumi 某一类型（比如动画）作品的 user-item utility matrix 为 $R$ ，其是一个 $M \times N$ 的矩阵，其中用户数为 $M$ ，作品数为 $N$ 。矩阵的元素是元素所在行对应的用户评分减去该用户评分的平均值。用户未评分的元素值记为 0。我们的目的，就是要对某一个用户已标记未评分、收藏状态为 $s$ 的作品进行评分预估：

r_{i j} = u_{i} v_{j}^{T} + b u_{i s} + b i_{j s}

　　其中 $u_i$ 是 $M \times Q$ 的 user-concept matirx $U$ 的第 $i$ 行行向量， $v_j$ 是 $Q \times N$ 的 concept-item matrix $V$ 的第 $j$ 列列向量。 $b u_i s$ 是用户状态偏置矩阵 $B u$ 的元素， $b i_j s$ 是作品状态偏置矩阵 $B i$ 的元素。得出评分估计模型的关键就是求出这四个矩阵 $U$ 、 $V$ 、 $B u$ 和 $B i$ ，使得 root mean square error (RMSE)最小，同时又有较好的泛化能力。

R M S E = \frac{1}{\mbox t o t a l r a t e d i t e m n u m b e r} \sum {(r_{i j} - u_{i} v_{j}^{T} - b u_{i s} - b i_{j s})}^{2}

　　实际上，这个问题就是最小化 RMSE 的最优化问题。假定我们已经有了 $U$ 、 $V$ 、 $B u$ 和 $B i$ 的初始估计值，那么我们就可以通过梯度下降的方法估计出使得 RMSE 最小的局部最优解。

　　在 RMSE 的表达式中，total rated item number 是一个固定的常数， $r_{i j}$ 是已经观测到的评分。我们把最优化的目标函数写成如下形式：

O b j = \sum {(r_{i j} - u_{i} v_{j}^{T} - b u_{i s} - b i_{j s})}^{2} + \frac{1}{2 σ^{2}} (\sum_{i} ∣ ∣ u_{i} ∣ ∣^{2} + \sum_{j} ∣ ∣ v_{j} ∣ ∣^{2} + \sum_{i} ∣ ∣ b u_{i} ∣ ∣^{2} + \sum_{j} ∣ ∣ b i_{j} ∣ ∣^{2})

　　目标函数的第一项是 RMSE，第二项是为了防止 $U$ 、 $V$ 、 $B u$ 和 $B i$ 过大的罚项。此目标函数对于行向量 $u_{i}$ 的导数为：

\frac{\partial}{\partial u_{i}} O b j = - 2 \sum_{j} (r_{i j} - u_{i} v_{j}^{T} - b u_{i s} - b i_{j s}) v_{j} + \frac{1}{σ^{2}} u_{i}

　　对于其他项的导数可以一一推得，而且计算也很简单，这里就不赘述。

　　但是目前的问题就是如何求出初始的 $U$ 、 $V$ 、 $B u$ 和 $B i$ ？初始值非常重要，选取一个好的初始值可以得到全局最优解。对于 $U$ 和 $V$ ，其是 $R$ 的一个近似分解。我们可以用 SVD 求出 $U$ 和 $V$ 的初始值。对于 $B u$ ，其是一个 $M \times 5$ 的矩阵，其每一行的元素是该用户处于想看、在看、看过、搁置或抛弃作品评分平均值与所有作品评分平均值之间的偏差。 $B i$ 是一个 $N \times 5$ 的矩阵，其每一行元素是该作品在 $R$ 中的不同状态中的评分平均值与 $R$ 中的总平均值之间的偏差。

泛化能力

　　我们已经推导出了变量的初始值和梯度。通过不断迭代更新 $U$ 、 $V$ 、 $B u$ 和 $B i$ 我们可以得到很低的 RMSE。但是矩阵计算量巨大，我们需要在评分系统预估的表现和现有计算能力中取得折中。到底迭代多少次、学习率为多少时合适？

Anime iterate

　　上图是在动画类别中的 RMSE 随迭代次数变化的变化场景。我按照 7:2:1 的比例将所有动画作品评分划分为训练集、验证集和测试集（后来我发现其实这个阶段还不要用测试集）。可以看出，RMSE 在训练集上可以训练到很低，但是更多的迭代次数对验证集的 RMSE 下降作用不大。因此，我选取了在验证集 RMSE 下降曲线的第二个拐点，即迭代次数约为 70 次的位置作为迭代次数。

　　另外一个参数是学习率的选取。根据经验，学习率选取在 0.0002 时为合适。但即使如此，在计算动画类的时候，学习率在 0.0002、罚项 $σ^{2}$ 在 10 的时候还会发散。因此动画类的学习率在迭代 10 次之后，以 0.00002 的学习率继续迭代下降。

余弦距离

　　在预估出所有已收藏未评分的作品评分之后，我仍然采用余弦距离计算用户之间的同步率。正如上文所说，这样用户未收藏的作品不会影响同步率。目前阶段，我不想让用户看到某位和他/她同步率很高的人看的是完全不同的动画——尽管它们有相同的概念。

　　在同步率过去的反馈里，我总是听到有人抱怨有收藏了个位数作品的人进入了他们的前十榜单。但是，只要同步率还是采取这样的保守定义：即在作品空间的余弦距离，这种现象永远不会得到根治。

　　设想一下，如果用户 A 看过的作品是你的子集，而用户 B 看过更多的作品，他不仅看过 A 的作品，而且还看过更多的你没看过的其他作品，那么可能谁会更高？这个答案毫无疑问是 A 与你的同步率更高——尽管你可能更想让 B 在你的同步率榜单中靠前一些。也就是说，相同条件下，余弦距离的定义使得系统必然偏向收藏数目少的人。

　　鉴于这样的事实，我想同步率这个玩具，v0.3 就是它最后的一个版本了。如果要以“寻求同好”为目的，就必须抛弃“同步率”这样陈旧的概念。

下一步？

　　同步率改的设计，我想已经到达了一个里程碑了，而且我想这也完成了我对 matrix factorization 的实践。但是，寻找同好这一终极目标并没有到达。在接下来，对同好的描述可能将不是余弦距离这样直观的模型就能理解的。我已经想好了会怎么做。所以请期待下一个更棒的玩具吧。

Misha and Permutations Summation

Sat, 17 Jan 2015 00:00:00 GMT

此题为 CF 上的一道中等难度题。题目的原文见这里。用中文简单说一下吧：给定0到N-1的两个排列，求这两个排列的“和”。之所以会有“和”的概念出现，是因为排列的大小可以依据字典序确定。

　　所以，解决这个问题需要的两个关键步骤是：根据排列确定字典序大小；根据字典序大小还原排列。

　　一个排列和其字典序大小是有某种确定关系的。Factorial number system 就这种关系给出了理论支持。这种关系，是一种可以一一对应并且互相转换的关系。比如说，当 N=3 的时候，所有的排列和其字典序大小关系如下所示：

排列	字典序大小
012	0
021	1
102	2
120	3
201	4
210	5

　　要完成互相转换的任务，必须借助于 factorial number system。这种 system 和通常的十进制、十六进制很相似，只是把“基”换成了数乘。比如说，如何表示 42，利用 factorial number system？ 4! < 42 < 5!

\begin{aligned} 42 & a m p; = 1 \times 4! + 3 \times 3! + 0 \times 2! + 0 \times 1! + 0 \times 0! \\ a m p; = (((1 \times 4 + 3) \times 3 + 0) \times 2 + 0) \times 1 + 0 \\ a m p; = 1300 0_{!} \end{aligned}

　　可以看到，首先 42 小于 5!，因此 42 可以由 5 以下的阶乘表示。在拆分的时候，每一位的数字不得大于当前位的阶乘数字。如 $1300 0_{!}$ 的最高位为 1，1<4。各位看官可以自行拆解几个数字看看。

　　由此，我们可以把第一个表再增加一项，表示出每一个字典序大小的阶乘数系表示：

排列	阶乘数系	字典序大小
012	000	0
021	010	1
102	100	2
120	110	3
201	200	4
210	210	5

　　那么在阶乘系统下表示出来的数字，好像和排列没有明显的联系啊。好像还不如用原始的方法，就是直接从排列计算出字典序大小呢。那么这一过程怎么计算呢，用最原始的思路？比如说我们现在有排列 120。其第一个数是 1，那么在第一个数是 0 的时候就已经有了 2! 次排列。再看第二位，是 2。在 2 的前面已经有了 0 的排列（这时候就要去掉 1 了），所以其在第一位数为 1 的情况下第二位数为 2 的之前的排列有 1! 个。再看第三位，是0，这时候排序就已经确定了，加上先前的所有排列，就是 2!+1!+1=4。鉴于字典序从 0 开始计数，减去 1 即可。

　　可以看到，在使用原始方法计算字典序的时候，在计算后面的数字的时候要记住前面已经使用了什么数字（看官可以拿一个更大的排列计算一下）。因此，我们如果按照这种思路计算的话，很快就会陷入频繁的大小比较中。

　　如果我们维护一个从 1 到 N 大小的数组，每个数组元素都是 1，并且再维护一个数组，计算其部分和，就会发现，每一次确定某一位之前出现过的数字等于部分和。如果一个数字被用掉了，将其减一，相应的每一位部分和表示该位之前没有被用掉的数字个数。在阶乘系统下表示的数字的每一位，其物理意义就是部分和。我们就此举一个例子：

　　数组为(1,1,1)，部分和为(1,2,3)，排列为120。数组从 1 开始计数，为了方便，排列每一位加 1 变成 231.

排列第一位数字 2 索引位置对应的部分和为 2，将其记录下来，并把该位减一. 这时候数组为(1,0,1), 部分和为(1,1,2)；
排列第二位数字 3 索引位置对应的部分和为 2，将其记录下来，并把该位减一. 这时候数组为(1,0,0), 部分和为(1,1,1)；
排列第三位数字 1 索引位置对应的部分和为 1，将其记录下来，并把该位减一。

　　我们记录下来的部分和表示了在这样一个排序中，当某一位没有采用该数字的时候可选择的数字个数。由于排列已经确定，我们把记录下来的部分和减一，变成 110。这样，通过部分和，我们就可以很快计算出排列对应的阶乘系统中的数字。看官可以自己拿一个数字计算一下。

　　现在我们解决了从排列到字典序大小的转换问题，下面要解决的问题就是字典序大小到排列的转换了。如何用传统方法解决？我们可以看到阶乘系统下的数字每一位都有“部分和”的意思。同时排列的每一位数字都是不同的。利用这些信息可以从最高位推出排列。首先阶乘系统下的数字的最高位前面没有被选择的数字，它既是部分和，也是排列中的确定数字。在从排列转化为字典序的过程中，确定的数字被减一，变成不可利用，因此部分和中可以利用的部分和只有第一次出现的某个部分和————因为不可利用的数字其值为 0，在部分和中表示为没有变化。

　　假设我们现在有字典序 2，其对应的阶乘系统数字为 100，我们将其转化为 211。同样地，我们维护数组(1,1,1)和其部分和(1,2,3)。

阶乘系统下数字最高位为 2，部分和中第一个出现 2 的索引位置为 2，记录该位置，并将该位置减一，现在部分和为(1,1,2);
阶乘系统下数字次高位为 1，部分和中第一个出现 1 的索引位置为 1，记录该位置，并将该位置减一，现在部分和为(0,0,1)
阶乘系统下数字最低位为 1，部分和中第一个出现 1 的索引位置为 3，记录该位置。

　　看官可以发现，之所以记录下来的索引位置是不重复的，是因为每次选取第一个部分和导致了避开使用过的索引位置。记录下来的索引位置为 213，每一位减一等于 102. 看官也可以自己拿一个数字计算一下。

　　那么在实际操作中，怎么计算部分和并更新部分和呢？如果一个位置发生了改变，以后所有的部分和都要发生改变。一个直接的方法就是通过维护线段树，但是更方便的方法是使用树状数组。

　　树状数组并不直接管理部分和，而是管理某一段的和。对一个长度为 N+1 的数组，其相对应的树状数组与之等长，并且有以下性质：树状数组索引为 n 处的元素管理着索引区间为 [n-lowbit(n)+1, n] 处原始数组区间之和。所谓 lowbit，是指某一个数转化为二进制后最低非零位置转化为一个 2 的整数次方的值。其为 x & (-x)。总而言之，这个数组有着与 2 的整数次方相关联的树状组织。

Tree Like Array

　　那么如何维护树状数组？我们大可以构建一个原始数组然后在其上构建树状数组，但是鉴于这个问题的部分和是按照索引递增的，而且只在原始数组上执行加减一的操作，我们可以直接构建基于树状数组的加减一操作：在包含当前索引处的区间值加减一即可。可以预见，这样维护树状数组的时间复杂度为 O(log n)。

　　到了这里，我想解这道题所需要的所有知识已经明确了。下面是我本人写的代码：

　　总结：

排列与指数系统有着一一对应的关系。排列每个数物理意义为部分和索引，指数系统每一位物理意义为部分和。
树状数组每一个元素试图管理一个 2 的整数次方的大小的长度的数组，lowbit 运算可以实现这一点。

OJ 总结(Depricated)

Sat, 03 Jan 2015 00:00:00 GMT

2015.01.04

Simple Binary Search

题目大意就是一种更好的 Binary Search，在一个已经排好序的数组里面找到 target，返回 target 索引。如果找不到，那么就返回 target 应该插入的位置。

我觉得还是 Acclerated C++ 那本书给了我很多启示。Binary search 的搜索区间看作是一个左闭右开区间，每次迭代的过程中，不变的准则是：区间的右边是开区间。这样可以省去考虑中间点恰好是 target 的麻烦。这样做的好处除了省去中间点的考量外，也省略掉了尾端的考虑：在 C 语言中，整数类型向 0 取整，所以 4 是 end 的话，所有小于 4 的数与之相加除以 2 的结果都必然小于 4。

当然这样没考虑区间左端。有一种情况区间左端小于 target，这时候就简单地和等于的情况合并喽。

这道题没用迭代。用迭代还可以再缩短时间。

Merge Sorted Array

给定两个已排好序的数组，把它们 merge 成一个。不要再分配空间。

按照惯常的思路是从每个数组的开头开始一一比较然后插入，但这不是 Merge Sort。其实可以从每个数组尾端开始，从大到小插入。但是这样会不会污染原有数据呢？用数学方法证明一下即可。

Game Theory Note - week 3

Sat, 01 Nov 2014 00:00:00 GMT

This week’s material is dedicated to concepts “beyond Nash Equilibrium”: iterative removal of strictly dominated strategies, minimax strategies and the minimax theorem for zero-sum game, correlated equilibria.

Different from previous weeks’ notes, I will illustrate some concepts in Chinese.

Dominated Strategies

Strictly dominated strategies are based on every player’s rationality: that is, everybody is rational, and everybody knows other players make rational decisions, and everybody knows that also… So, those strategies that are strictly dominated are to be dominated. We can get final strategy by using iterated removal.

Example 1: Prisoner’s dilemma

Prisoner 1 and 2	Co	Be
Co	-0.5, -0.5	-10, 0
Be	0, -10	-2, -2

Follow the rational thinking, both prisoners will chose betrayal because choosing betrayal will definitely have him/her spent somewhat less time in prison in comparison to choosing cooperation. In this case, we say that betrayal dominates cooperation.

What’s interesting is that the final strategy, which is a Nash Equilibrium, is not optimal in a overall view. This is where dilemma lies, which illustrates that 非零和博弈中，帕累托最优和纳什均衡是相冲突的.

Example 2: Intelligent Pigs

The illustration of this game can be found here.

Small pig and big pig	Press	Wait
Press	1,5	-1,9
Wait	4,4	0,0

In this experiment, we can see that for the small pig, there is a dominate strategy, so the small pig would prefer waiting. After eliminating pressing for small pig, the big pig would chose to press. However, for the big pig, there is no dominate strategy, but after iterative eliminating, (wait, press) becomes the nash equilibrium.

Someone may question about the relationship between Nash equilibrium and dominant strategy equilibrium. 优势策略均衡和纳什均衡的区别在于：在优势策略均衡中，我所做的是不管你做什么，我所能做的是最好的；在纳什均衡中，我所做的是给定你所做的前提下，我所能做的是最好的，你所做的是在给定我所做的前提下你所能做的是最好的，从二者的关系可以看出，优势策略均衡是纳什均衡的一个特例，一个优势策略均衡首先是一个纳什均衡.

Maxmin Strategies and Minmax Strategies

Maxmin strategy is a strategy that maximizes one’s worst-case payoff. Maxmin Value of the game for player i is that minimum payoff guaranteed by a maxmin strategy. A conservative agent would prefer the maxmin strategy.

Minmax strategy is a strategy that minimizes other’s worst-case payoff.

Theorem : In any finite, two-player, zero-sum game, in any Nash equilibrium each player receives a payoff that is equal to both his maxmin value and his minmax value.

Note: in non-zero-sum game, Nash equilibrium may not equal to maxmin or minmax strategy.^1

Corrleated Equilibrium

Correlated Equilibrium (informal): a randomized assignment of (potentially correlated) action recommendations to agents, such that nobody wants to deviate.

Reference: Correlated equilibrium^2.

Game Theory Note - week 2

Sat, 18 Oct 2014 00:00:00 GMT

This week’s Game Theory is dedicated to Mixed-Strategy Nash Equilibrium.

Mixed strategy, different from pure strategy, means that players can choose an action according to a specific probability distribution (among all possible actions). The following concepts and definitions all derives from this idea:

Strategy $s_{i}$ : any probability distribution over the actions $A_{i}$ for agent i.

Pure strategy : only one action is played with positive probability.

Mixed strategy : more than one action is played with positive probability.

Support (of mixed strategy) : all the actions

We denote $s_i \in S_i$ as $S_{i}$ is the set of all strategies for user i. All strategies $S = S_1 \times S_2 \times \dots \times S_n$

Expected Utility is defined as follows:

u_{i} (s) = \sum_{a \in A} u_{i} (a) P (a ∣ s) P (a ∣ s) = \prod_{j \in N} s_{j} (a_{j})

In the equations above, a means a possible action profile from A. $a_{j}$ does not mean each of the action but the player j’s corresponding action in the corresponding profile.

Best response

$s_i^{*} \in B R (s_- i) i f f \forall s_i \in S_i u_i (s_i^{*}, s_- i) \geq u_i (s_i, s_- i)$

Nash Equilibrium

$s=\<s\_1, s\_2,="" \ldots,="" s\_n=""\> \mbox( is a Nash Equilibrium iff }\forall i, s\_i \in BR(s\_{-i})$ </s_1,>

Theorem : Every finite game has a Nash Equilibrium. (While comparing to pure strategy games!)

It is often very hard to compute the Nash Equilibrium of a game, but in simple cases, in which we know the support, we can get the Nash Equilibrium by being acknowledged that a player will act indifferently facing a mixed strategy.

Game Theory Note - week 1

Sun, 12 Oct 2014 00:00:00 GMT

This week’s game theory was dedicated to introduction, overview, uses of game theory, some applications and examples, and formal definitions of: the normal form, payoffs, strategies, pure strategy Nash equilibrium, dominant strategies..

Define a Game

Normal form: List what payoffs get as a function of their actions.
Extensive form: Includes timing of moves, players moves sequentially, represented as a tree.

Finite, n-person normal form game: $< n, a, = " " u = " " >$ :</n,>

Players: $N = 1, \dots, n$ , indexed by i;
Action set for player i: $a = (a_1, \dots, a_n) \in A = A_1 \times \dots \times A_n$ is an action profile;
Utility function or Payoff function for player i: $u_i : A \mapsto R$ , $u = (u_1, \dots, u_n)$ is a profile of utility functions.

Type of Games

Type of Game	Properties	Examples
Pure Competition	1. Exactly two players of opposed interests; Zero sum special case when $u_1 (a) + u_2 (a) = 0$	Matching Pennies, Rock-Paper-Scissors
Coordination	Players have same interests: $\forall a \in A, \forall i, j, u_i (a) = u_j (a)$	side of road
Coordination and Competition		Battle of the Sexes

Nash Equilibrium

In game theory, the Nash equilibrium is a solution concept of a non-cooperative game involving two or more players, in which each player is assumed to know the equilibrium strategies of the other players, and no player has anything to gain by changing only their own strategy. If each player has chosen a strategy and no player can benefit by changing strategies while the other players keep theirs unchanged, then the current set of strategy choices and the corresponding payoffs constitute a Nash equilibrium.¹

Someone has an incentive to deviate from a profile of actions that do not form an equilibrium.

Best Resopnse : If you knew what everyone else was going to do, it would be easy to pick your own action. : Nash equilibrium looks for stable action profiles.

Dominant Strategies

Strategy (currently) is choosing an action (“pure strategy”)

Denote $s_i$ and $s_i^{'}$ as two strategies for player i, and $S_- i$ be the set of all possible strategy profiles for the other players.

$s_i$ strictly dominates $s_i^{'}$ if $\forall s_- i \in S_- i, u_i (s_i, s_- i) > u_i (s_i^{'}, s_- i)$ $s_i$ very weakly dominates $s_i^{'}$ if $\forall s_- i \in S_- i, u_i (s_i, s_- i) \geq u_i (s_i^{'}, s_- i)$ Please pay attention to the difference between best response, which lies in the definition of strategy.

A strategy profile consisting of dominant strategies for every player must be a Nash equilibrium! An equilibrium in strictly dominant strategies must be unique.

Pareto Optimality

Some times, one outcome $o$ is at least as good for every agent as another outcome $o^{'}$ , and there’s some agent who strictly prefers $o$ to $o^{'}$ .

An outcome $o^{*}$ is Pareto-optimal if there is no other outcome that Pareto-dominates it.

Nash equilibrium, https://en.wikipedia.org/wiki/Real_number ↩

一种树的表达法

Sat, 04 Oct 2014 00:00:00 GMT

《算法导论》教导我们，图有两种表达方法：邻接链表和邻接矩阵。至少是对于有环的图来说，的确是这样。对于树和图究竟怎样表达最好，我一直都在摸索之中。以前在写与图有关的算法的时候，总是要把整个邻接链表（通常是一个很大的std::vector<std::list<T>>&）当作参数的一部分送进去。这样看着就很别扭，但是这确实是严格按照《算法导论》的定义实现的。

因此我对我的代码质量深表担忧。但是幸运的是，最近我开始学习起别人的代码，从中获得了一些启示。今天总结的是这么一种特殊的图————自由树的表达方法。这种方法高效，无论是从时间上还是空间上。

假定现在给出一系列树边，每行一条树边记录，由两个数组成。第一个数代表父结点，第二个数代表子结点。这一系列树边可以组成一棵树（或一片森林）。对于这样的信息，利用下面这种方法可以给出高效的表达。

首先我们定义如下结构和数组：

typedef struct{
    int v;
    int prev;
}edge_t;

edge_t edges[N]; //边
int head[N];     //结点

我们知道，在一棵结点数为V的树中，一共有V-1条边。因此给结点和边各开V大小的数组是没问题的。利用这样的数据结构，我们使用如下方法读取边：

//for each edge (u,v)
edges[i].v=v;
edges[i].prev=head[u];
head[u]=i;

从这段代码中，我们可以看出如下基本事实：

edges以边序号为索引，其中v记录的是该边的子结点，prev记录的是另一条边序号；
head以结点序号为索引，其中记录的是边序号；
在第一次涉及到父结点u时，head[u]为0，此时将此值赋给prev，代表空边。在这之后，head[u]被赋予本边序号；
如果再次遇到父结点u，head[u]会被新的边序号覆盖。
因此，head实际上存储着以某个结点为父结点时，其在读取顺序中的最后一条边。如果无子结点，则为0.

那么，每个结点最多只存储一条边，如何实现多个子结点的情况？事实上，我们在读到这“最后一条边”时，依照读取顺序的上一条边已经被存储在edges[i].prev中了。按照如下代码，可以方便地完成对某个结点所有子结点的遍历：

for(int k=head[i]; k!=0; k=edges[k].prev){
    //do something
}

这种方法适用于：

数据以自由树形式表达；
输入数据是边的信息，且标明了父亲孩子关系。
输入边的顺序可以任意。如果要确定根结点，只要再加上一个bool isroot[V]就可以在读取的时候把所有子结点标注出来。

树的直径

Sun, 21 Sep 2014 00:00:00 GMT

求一个自由树的直径。对于直径，《算法导论》第三版 349 页练习 22.2-8 上面这么定义道：

树中所有最短路径的最大值即为树的直径。

这个树由于没有根结点，其实直径这个概念，还是理解为一个连通无向无环图的直径为好。

现在给定如下格式的输入：

8 1 2 1 3 1 4 4 5 3 6 6 7 7 8

第一行是这个图的结点个数，不妨记为 N，以下 N-1 行是 N-1 条边，结点序号按照 1-N 顺序编号。求这个图的直径。

对于这个问题，最笨的方法就是对每一个结点进行 BFS，因为 BFS 有这个性质：BFS 生成的广度优先树的每一个结点到达根结点的路径总是最短路。这样，把每一个结点 BFS 一遍就会生成一个该结点到达的最远结点。按照定义取出最长的路径即可。由于 BFS 时间复杂度是 O(N)，这个方法的时间复杂度是 $O (N^{2})$ 。

其实还有一个更为简便的方法：首先对任意一个结点做 BFS 求出最远的结点，然后以这个结点为根结点再做 BFS 到达另一个最远结点。第一次 BFS 到达的结点可以证明一定是这个图的直径的一端，第二次 BFS 就会达到另一端。下面来证明这个定理。

但是在证明定义之前，先证明一个引理：

引理：在一个连通无向无环图中，x、y 和 z 是三个不同的结点。当 x 到 y 的最短路与 y 到 z 的最短路不重合时，x 到 z 的最短路就是这两条最短路的拼接。

证明：假设 x 到 z 有一条不经过 y 的更短路 $δ (x, z)$ ，则该路与 $δ (x, y)$ 、 $δ (y, z)$ 形成一个环，与前提矛盾。

定理：在一个连通无向无环图中，以任意结点出发所能到达的最远结点，一定是该图直径的端点之一。

证明：假设这条直径是 $δ (s, t)$ 。分两种情况：

当出发结点 y 在 $δ (s, t)$ 时，假设到达的最远结点 z 不是 s,t 中的任一个。这时将 $δ (y, z)$ 与不与之重合的 $δ (y, s)$ 拼接（也可以假设不与之重合的是直径的另一个方向），可以得到一条更长的直径，与前提矛盾。
当出发结点 y 不在 $δ (s, t)$ 上时，分两种情况： 1). 当 y 到达的最远结点 z 横穿 $δ (s, t)$ 时，记与之相交的结点为 x。此时有 $δ (y, z) = δ (y, x) + δ (x, z)$ 。而此时 $\delta (y,z)>\delta (y,t)$ ，故可得 $\delta (x,z)>\delta (x,t)$ 。由1的结论可知该假设不成立。

2). 当 y 到达的最远结点 z 与 $δ (s, t)$ 不相交时，记 y 到 t 的最短路首先与 $δ (s, t)$ 相交的结点是 x。由假设 $\delta (y,z)>\delta (y,x)+\delta (x,t)$ 。而 $δ (y, z) + δ (y, x) + δ (x, s)$ 又可以形成 $δ (z, s)$ ，而 $\delta (z,s)>\delta (x,s)+\delta (x,t)+2\delta (y,x)=\delta (s,t)+2\delta(y,x)$ ，显然与题意矛盾。

因此定理成立。

9月21日补充：这道题是上一周 hihocoder 上面的一道题。出题者的原意并不是要我们这么做。出题者写了很长的一段提示，但是这段提示的语文表述很差，完全没有抓住重点，导致我花了一个星期的时间也没弄明白他在讲什么。现在所有人的源代码均已公开，可以继续下去了。

出题者的原意是要我们使用这么一个定理：

定理2：树的直径，等于以树直径上任意一点为根的有根树，其左子树的高度+1，再加上其右子树高度+1。

按照这种定理的定义，我们可以设计这样一个程序，对每个结点计算左子树高度+右子树高度+2.这样的时间复杂度是 $O (n^{2})$ 。由于我们不知道所选取的结点是否是在直径上，所以要进行这样的枚举。显然这会超时。但是根据本文的提示，寻找这种直径的过程其实可以递归化：

在根结点的左子树上；
在根结点的右子树上；
直径经过根结点。

于是我们可以设计这样的程序：选取任意结点为根结点，递归地计算每个结点的高度。在结点内部计算高度的同时，计算以当前结点为根的子树的左子树高度+右子树高度+2，用于更新全局树直径。

二叉搜索树与快速排序的内在相似性

Sun, 27 Jul 2014 00:00:00 GMT

对我来说，对随机事件的分析，恐怕是最难的。我原以为我数学学得还可以，直到我遇上了随机过程。这篇 blog 所讲的是算法分析，其中涉及到大量对随机情况的分析。因此我在此将其梳理一下，特别注重挖掘不同算法之间的分析过程的相似性。

快速排序是一种原址排序方法，随机化的快排具有 O(nlgn) 的期望运行时间。这个在《算法导论》（第三版）的 7.4.2 节中有一个以比较操作为中心的证明方法。这个证明的核心思想就是：快速排序是由多次 partition 过程组成的，因此关键问题就在于获得 partition 过程的运行时间和运行 partition 过程的次数。partition 过程的最大运行次数是 n-1 次，可以记为 O(n) ，对于其运行时间，练习 7.1-3 给出的结论是 Θ(n) 。这样乍一算，似乎是 O( $n^{2}$ ) 的时间复杂度。这样计算是错误的，因为 partition 的时间复杂度与其长度有关。这里，我们需要更为细致的分析。决定 partition 运行时间的是其内部循环次数。这个循环次数可以统计每次必须运行的比较次数而得到。通过计算整个 quicksort 的比较次数，我们就可以得到真正的 partition 循环次数。而这个比较次数的期望值，可以通过拆分成示性随机变量相加得到。这个分析的精华之处就在于分析出每两个元素进行比较的概率。很有意思，可以进行比较的组合是 Θ( $n^{2}$ ) ，但是最终全部比较次数的期望是 O(n lgn) 。

当然这个只是作为复习，不是今天的重点。这个方法实在是太不直观了点。这次我们用类似于 merge-sort 的分析方法进行分析。

快速排序分析

按照 merge-sort 的分析思路，quicksort 是将一个问题拆分成了两个子问题，但是由于子问题大小不是固定的，这时候就只能分析运行时间的期望。随机化的快速排序使得任何一个元素成为主元都是等可能的。因此我们有如下式子：

\begin{aligned} E [T (n)] & = E [\sum_{q = 1}^{n} X_{q} (T (q - 1) + T (n - q) + Θ (n))] \\ = \frac{2}{n} \sum_{q = 2}^{n - 1} E [T (q)] + Θ (n) \end{aligned}

随后，可以通过代入法，把 n lgn 代入 T(n)。其中，有如下不等式可以利用：

\sum_{k = 2}^{n - 1} k \log k \leq \frac{1}{2} n^{2} \log n - \frac{1}{8} n^{2}

由于这个不等式的天赐特性，我们只能记住，有如（1）式的结论就是 O(n lgn) 。

二叉搜索树分析

我们知道，二叉搜索树的动态操作时间复杂度是 O(h) 。但是对于随机构建的二叉搜索树来说，其期望树高是 O(n lgn) ，对于随机构建的二叉搜索树来说。这里我们证明的是一个稍弱于此定理的定理：随机构建的二叉搜索树的平均节点深度为 O(n lgn)。

为表示每一个节点的深度，我们记树T的节点x的深度为 d(x, T) ，而全部节点的深度之和记为 P(T) 。节点平均深度可以表示为

\frac{1}{n} \sum_{x \in T} d (x, T) = \frac{1}{n} P (T)

而每一棵树可以拆分为节点与左子树、右子树。我们需要注意，当把 P(T) 拆分为 $P (T_{l e f t})$ 和 $P (T_{r i g h t})$ 之后深度还应该增加当前树总节点再减一。也就是

P (T) = P (T_{l e f t}) + P (T_{r i g h t}) + n - 1

对于某一棵树确实是这样。但是这棵树是随机构建的。如何表示出 P(T) 的期望值？事实上，这里和快速排序一样，在随机构建的过程中，第一个元素总是根节点，每一个元素成为第一个元素的概率都是相等的。因此，我们可以据此写出：

E [P (n)] = E [\frac{1}{n} \sum_{k = 0}^{n - 1} (P (k) + P (n - k - 1) + n - 1)]

其中 P(n) 是具有 n 个节点的树高。这时候，我们发现，这和在快速排序那里推导出来的式子是非常相似的。因此，延续着快排分析的思路，可以分析出 P(n) = O(n lgn)。

知道这一点有什么用呢？当构建一棵二叉搜索树时，第一个元素会被选为根节点，其后的元素，每一个都要和其比较。这和快速排序的比较次数是一样的。因为当一个元素选为主元的时候，其后的每一个元素都要和其比较。这样，当用相同的序列构建二叉搜索树和进行快速排序的时候，他们所需要的比较次数是相同的。

简单易懂的XML parsing——Qt篇

Fri, 30 May 2014 00:00:00 GMT

关于XML的文章我先前写过一篇。之后就再也没写过。原因是很简单的。虽然那篇文章是用Matlab的代码说明XML解析，但是XML的基本概念都是一致的，我也没必要再就C++或是Python等语言再写一遍在其他语言下面怎么用其他的库解析XML，都是大同小异。

可是这个世界上奇葩比较多。最近在做《网络通信原理》的project的时候，用到了Qt里面的QXmlStreamReader。有意思的是，这个东西不按常理出牌。为说明这个特性，我引用Qt 5关于QXmlStreamReader上面的一段话：

QXmlStreamReader is an incremental parser. It can handle the case where the document can’t be parsed all at once because it arrives in chunks (e.g. from multiple files, or over a network connection). … QXmlStreamReader is memory-conservative by design, since it doesn’t store the entire XML document tree in memory, but only the current token at the time it is reported.

由这段话我们可以看出，QXmlStreamReader的一个重要特点是，它是一个增量parser。QXmlStreamReader有一个特别的构造函数QXmlStreamReader::QXmlStreamReader(QIODevice * device)，这个device可以是QNetworkReply也可以是QFile。相信这样的好处大家都可以看得出来。为了应付不同IODevice的特性，QXmlStreamReader也只能采取增量解析的方法。然后又有了下面的概念：token.

QXmlStreamReader不在内存中保存全部的DOM tree，现在解析的位置和所解析的对象用token说明。关于什么是token，其实我也不知道。但是QXmlStreamReader提供了一个函数：TokenType QXmlStreamReader::readNext()，有关这个函数的说明是“Reads the next token and returns its type.”

按照官方文档上面的解释，一个可行的解析模型可以是这样：

QXmlStreamReader xml;
...
while (!xml.atEnd()) {
      xml.readNext();
      ... // do processing
}
if (xml.hasError()) {
      ... // do error handling
}

由此可见，QXmlStreamReader在解析xml的时候，以token为单位解析xml文档数据。

我在上一篇文章中讲过，xml有Element node，Element node以Text node作为child，Attribute node从属于Element node，comment node相对独立，而以上四种node都由document node生成，document node可以说是一个xml文档的代表，xml parsing的核心是element node。但是在Qt中，token与这种标准的概念似乎完全无关。它更关心我现在读到的东西是什么。在TokenType的定义中，一共给出了9种不同token的定义，而判断当前parser的tokenType是什么的函数一共有十二种。

我们可以想象，这种parser，一块一块地读取xml文档，只前进不后退，每一块代表一种既定的token，直到全部读完xml为止（也就是atEnd()为真的时候）。

下面让我展示一段我这个project中的一段代码：

if(reply->error()==QNetworkReply::NoError){
    ui->listWidget->clear();
    articlelist.clear();
    QXmlStreamReader xml(reply);
    if(xml.readNextStartElement() && xml.name()=="articles"){
        while(xml.readNextStartElement() && xml.name()=="article"){
            Article record;
            while(xml.readNextStartElement()){
                if(xml.name()=="author"){
                    record.author = xml.readElementText();
                }else if(xml.name()=="date"){
                    record.date = xml.readElementText();
                }else if(xml.name()=="title"){
                    QString t = xml.readElementText();
                    ui->listWidget->addItem(t);
                    record.title = t;
                }else if(xml.name()=="content"){
                    record.content = xml.readElementText();
                }
            }
            articlelist.push_back(record);
        }
    }
    ...
}

xml文档格式如下：

<articles>
  <article>
    <author>...</author>
      <date>...</date>
    <title>...</title>
    <content>...</content>
  </article>
  <article>
  ...
  </article>
  ...
</articles>

代码中reply是个API请求的回应，我的目的是吧这个回应中的每一条信息存放在articlelist中。值得注意的是14-16行那段代码，由于这个是一个增量parser，我们不能使用

ui->listWidget->addItem(xml.readElementText());
record.title = xml.readElementText();

否则record.title将为空。

简单易懂的XML parsing

Tue, 11 Mar 2014 00:00:00 GMT

读取一个XML文件，返回一个DOM对象。

什么是DOM对象？全称为Document Object Model, XML文件中的每一个东西都对应为一个node。DOM node的属性和方法遵循国际互联网的标准。

有以下类型的nodes：

Element nodes* Text nodes 每一个Text node都是Element node的child
Attribute nodes 不是任何node的parent 或 child,从属于element node
Comment nodes* Document nodes 只有使用document node的方法才能创造新element, text, attribute, comment

现有以下xml文档：

<listitem>
    <label>Import Wizard</label>
    <callback>uiimport</callback>
    <icon>ApplicationIcon.GENERIC_GUI</icon>
</listitem>
<listitem>
    ...
</listitem>
    ...

其中的一个label标签有字符Plot Tools。假设你想在同样的listitem里面寻找callback标签的字符：

findLabel = 'Plot Tools';
findCbk = '';
xDoc = xmlread(fullfile(matlabroot, ...
               'toolbox','matlab','general','info.xml'));
allListitems = xDoc.getElementsByTagName('listitem');
for k = 0:allListitems.getLength-1
    thisListitem = allListitems.item(k);

    % Get the label element. In this file, each
    % listitem contains only one label.
    thisList = thisListitem.getElementsByTagName('label');
    thisElement = thisList.item(0);
    % Check whether this is the label you want.
    % The text is in the first child node.
    if strcmp(thisElement.getFirstChild.getData, findLabel)
        thisList = thisListitem.getElementsByTagName('callback');
        thisElement = thisList.item(0);
        findCbk = char(thisElement.getFirstChild.getData);
        break;
    end

end

if ~isempty(findCbk)
    msg = sprintf('Item "%s" has a callback of "%s."',...
                      findLabel, findCbk);
else
   msg = sprintf('Did not find the "%s" item.', findLabel);
end
disp(msg);

MATLAB本身就提供一个xmlread函数，其返回的是Document Node。根节点哦。其余与Document Node的函数都是标准已经定义了的，这个标准详情请见这里.在上面一段代码中，我们可以看见几个常用的API：

getElementsByTagName是Document Node的方法，返回一个list。
这个list是node的列表，要得到其中一个元素，需要调用list的item方法。
一个有child的element node，获得其内容，要调用getFirstChild.getData。

如果我们想写一个XML文档：

<?xml version="1.0" encoding="utf-8"?>
<toc version="2.0">
    <tocitem target="upslope_product_page.html">Upslope Area Toolbox<!-- Functions -->
        <tocitem target="demFlow_help.html">demFlow</tocitem>
        <tocitem target="facetFlow_help.html">facetFlow</tocitem>
        <tocitem target="flowMatrix_help.html">flowMatrix</tocitem>
        <tocitem target="pixelFlow_help.html">pixelFlow</tocitem>
    </tocitem>
</toc>

MATLAB代码如下：

docNode = com.mathworks.xml.XMLUtils.createDocument('toc');

toc = docNode.getDocumentElement;
toc.setAttribute('version','2.0');

product = docNode.createElement('tocitem');
product.setAttribute('target','upslope_product_page.html');
product.appendChild(docNode.createTextNode('Upslope Area Toolbox'));
toc.appendChild(product)

product.appendChild(docNode.createComment(' Functions '));

functions = {'demFlow','facetFlow','flowMatrix','pixelFlow'};
for idx = 1:numel(functions)
    curr_node = docNode.createElement('tocitem');

    curr_file = [functions{idx} '_help.html'];
    curr_node.setAttribute('target',curr_file);

    % Child text is the function name.
    curr_node.appendChild(docNode.createTextNode(functions{idx}));
    product.appendChild(curr_node);
end

xmlwrite('info.xml',docNode);
type('info.xml');

这个函数首先先创建出一个Document Node，也就是最重要的根节点；
SetAttribute是Element Node的方法；
element, text, attribute, comment只能由docNode创建，方法是createXXXNode；
Element Node间的父子关系由appendChild确定。

以上就是MATLAB里面处理XML文档的最基本知识。由于XML文档的处理方式是统一的，因此很容易就能拓展到其他语言。从代码中就可以挖掘出许多东西。在实际中，要使用到的XML API恐怕还远远不够。这篇文章只是作为一个入门性质的导引。

简单易懂的Sublime Text 2

Tue, 04 Feb 2014 00:00:00 GMT

由于这几天一看见Python自带的IDLE我就作呕，我觉得很有必要花点时间研究一下Sublime Text 2。

为什么要用Sublime Text 2？其实我也不知道。我第一次知道这个编辑器是在Azure的培训上。后来我发现，许多专业人士都非常推崇此编辑器。Sublime Text 2在Windows、Mac和Linux下都有相应的版本。

如果你去看Sublime Text 2的主页，你会发现这个编辑器的最大优点就是多光标编辑。没有其他任何一个编辑器能做到这一点。

下面，我把Sublime的文档简要翻译了一下，权作参考。如果没有特殊说明，下面都是在Windows平台下操作。

大规模行选择

Legacy image unavailable: multiple line selecting. 方法一：Shift+右键拖动，或按下中键拖动。如果要额外添加一行光标，使用Ctrl+左键选择。（虽然文档上说Alt是撤销一行光标，但是我从来都没试成功过）方法二：使用键盘：Ctrl+Alt+Up向上选择，Ctrl+Alt+Down向下选择。

多重选择

选择块区域并分裂成多行

选择一个块区域，然后按下Ctrl+Shift+L，可把一整块的选择区域分成每一行一块的选择区。

快速添加下一相同区域

我们在文字编辑器里会有相同的变量名，如果我们的光标在其中一个变量名之上，按下Ctrl+D，整个变量名就会被选择。如果再按下Ctrl+D，下一个相同的变量名也会被选择。 Legacy image unavailable: multiple block selecting.

一起选定所有相同区域

光标在变量名上，按下Alt+F3

退回到单个选择模式

按下Esc

自动补全

自动补全是自动开启的，设置在Preferences/Settings-Default里面，有个”auto_complete”。如果当前弹出窗没有弹出，可以按下Ctrl+空格，强制显示当前可补全选项。不会引发输入法吗，我想。在HTML文档里，’<’键是触发自动补全的按键。

Tab补全

Tab补全是自动开启的，有个”tab_completion”的选项。如果当前的补全结果并非为我所愿，可以按下Ctrl+空格，显示补全选框。如果按下Tab不想补全而是写下制表符，可以按下Shift+Tab。

不受干扰模式

这种模式跟全屏模式还有些区别。 View/Enter Distraction Free Mode打开此模式。或直接按Shift+F11。设置不受干扰模式：与上文不同，路径在_Preferences/Settings - More

{
    "line_numbers": false,
    "gutter": false,
    "draw_centered": true,
    "wrap_width": 80,
    "word_wrap": true,
    "scroll_past_end": true
}

这是一个设置样本。特别注意的是”wrap_width”这个选项，这个选项之大小决定了该模式下的编辑宽度。

Vintage Mode

这个是Vi模式。此模式在默认状态下是关闭的，你需要做的是将其从ignored-packages中去除。编辑"ignored_packages": ["Vintage"] 至"ignored_packages": []即可。

Vintage模式默认状态是insert mode。如有不适请添加如下一行：

"vintage_start_in_command_mode": true

需要注意的是，Vintage模式下的insert模式是Sublime正常工作的模式，在此情况下的vi快捷键不可用。而且Ex模式也不可用。

Ctrl快捷键与Sublime冲突，默认关闭。如需启用，请打开

"vintage_ctrl_keys": true

Projects

在Sublime Text 2中，Projects由两个文件组成：

Sublime Project File：定义Project，需要加入版本控制；* Sublime-workspace file：用户的数据。

Sublime-Project File是一个JSON文件，顶层分三大部分：Folders明确包含的文件，Settings会覆写用户设置，还有Build_systems。

Permalink 404 Error 之解决方案

Sun, 26 Jan 2014 00:00:00 GMT

Ike本人在设置wordpress的时候，在settings里面发现了Permalink。从这个页面的主要介绍来看，Permalink的作用就是自定义文章的Link，使之更为结构化和友好。

但是当Ike设置了某个除Default之外的某个Permalink的时候，如果点击一篇发表的文章，就会出现Page Not Found的404错误。

经反复查证，Ike发现Permalink与.htaccess和Apache的设置紧密相关。

如果我们在Settings页面的Permalink中就某个选项进行了保存，wordpress在后台就会改写.htaccess：

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /blog/
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /blog/index.php [L]
</IfModule>
# END WordPress

这个.htaccess文件是存放在网页的根目录下的，和wp-config.php存放的位置一样。如果wordpress不能改写此文件，则需要手动改写，但需要注意到的是Ike本人的网页是放在/blog文件夹下的，如果放在别的文件夹下，正确的.htaccess内容可能和上面不一样。

如果成功改写.htaccess，只是成功了一半。因为Ike本人发现即使赋予了后台改写.htaccess的权限，还是不能访问。

有文献报道指出，Apache需要使能rewrite_module才能使得Permalink正常工作。这就需要改写Aapche的配置文件。

运行以下命令：

sudo find / -type f -iname "httpd.conf"

找到Apache的配置文件的位置。据相关文献报道，需要做的是将

#LoadModule rewrite_module modules/mod_rewrite.so

的注释去掉。

但甚为坑爹的是，Ike发现虚拟机上的Apache配置文件本来就没有把这一行给注释掉。

经过一番查证，这里一篇帖子为我们给出了解决方案的暗示。于是Ike在配置文件下找到了如下若干行：

#
# Each directory to which Apache has access can be configured with respect
# to which services and features are allowed and/or disabled in that
# directory (and its subdirectories).
#
# First, we configure the "default" to be a very restrictive set of
# features.
#
<Directory />
    Options FollowSymLinks
    AllowOverride All
</Directory>

...

#
# Possible values for the Options directive are "None", "All",
# or any combination of:
#   Indexes Includes FollowSymLinks SymLinksifOwnerMatch ExecCGI MultiViews
#
# Note that "MultiViews" must be named *explicitly* --- "Options All"
# doesn't give it to you.
#
# The Options directive is both complicated and important.  Please see
# http://httpd.apache.org/docs/2.2/mod/core.html#options
# for more information.
#
    Options Indexes FollowSymLinks

#
# AllowOverride controls what directives may be placed in .htaccess files.
# AllowOverride controls what directives may be placed in .htaccess files.
# It can be "All", "None", or any combination of the keywords:
#   Options FileInfo AuthConfig Limit
#
    AllowOverride All

按照上面配置，再重启Apache即可。大功告成。

坡道的起点——AWS上Wordpress建站小记

Sun, 26 Jan 2014 00:00:00 GMT

经过若干天的反复瞎搞，这个名为”Pursuing Freedom”的博客终于上线了。

建立一个个人博客本来不是难事，只要你肯花钱。国内国外本来就有很多主机提供商，而且有些还是提供注册域名、服务器搭建的一条龙服务。但是Ike酱认为，有钱首先应该花在手办上，其他的能省就省～上个学期接受了一个Azure的培训，从那个培训中Ike酱得知现在云服务可以做很多事情。而且亚马逊的AWS在一定的使用范围内是免费的，这就提供了无限多的可能构造一个自由定制的主页。下面Ike将会把这次建站的各个方面记录一下，供以后参考。

首先我们从AWS讲起。AWS全称Amazon Web Services。和Windows Azure一样，AWS提供了一系列云解决方案。在注册AWS用户的一年时间之内，可以在限定的范围内，免费使用AWS的部分服务。有关这些详情，请参考How Do I Get Started with the Free Usage Tier?。

有必要强调一点的是，注册AWS的账号需要一张国际信用卡。对于弊校学生来说，这还是一件比较容易办得到的事情，因为Ike常常见到食堂附近有建行的人在接受集体办卡。（Ike能说Ike拿到这个信用卡之后的第一件事就是开通了AWS账号么）

建站的过程其实很简单，因为AWS的Documention上已经把步骤都写好了。概要地说，就是使用AWS EC2建立一台虚拟机，进行安全和账户控制，然后在这个虚拟机上安装各式各样的东西～怎样建立一个虚拟机的Instance，怎样通过远程终端连接上去，怎样配置Apache+PHP+MySQL，其实我不是Linux的专家，但是Amazon EC2 User Guide上面都说得一清二楚。别看文档有600页，其实建立个人博客只要前几页就够了。

在这里整理一下，我参考文档的顺序是： 1. Getting Started with AWS 2. Getting Started with AWS Free Usage Tier 3. Amazon EC2 User Guide 我并不想把这里面的内容再抄一遍放在这里来，说实在的，这一建站步骤唾手可得。

在完成wordpress博客的创建之前，如果有任何问题，都可以归结到文档步骤没有仔细遵循的原因上。总体而言，建立wordpress博客的步骤要比Windows Azure复杂，但是也可以说Windows Azure忽略了许多重要的东西。

但是，在建立了这个wordpress博客、并可以访问之后，是否说明真的可以用了呢？其实后续还有许多复杂的事情要做。

首先就是虚拟机的权限设置问题。在EC2 UG里面，我们给虚拟机创建了一个名为www的group，理由是可以让ec2-user获得对/var/www/的修改权限。但是在实际中，光给ec2-user一个用户这些权限还不够。Wordpress程序可以进行插件的自动安装和自动更新，如果apache拿不到这些权限，Wordpress的更新和拓展都很麻烦。理论上说我们可以每次都登录虚拟机用ec2-user做这些事情，但这样大大提高了博客的使用门槛。

其次，在UG里面没有提到ftp的设置。ftp会给个人网站的部署和更新带来很大便利。wordpress进行更新也需要用到ftp。

关于这两个问题，我给ftp的user和服务器apache都加入到用户组www中，确认网站的根目录下对www都有读写权限。关于ftp的部署，我主要参考了AWS EC2上架设 FTP。

但是真正麻烦的，是Wordpress服务器经常连接不上数据库的问题。虽然wp-config.php里面的参数都配置正确，但就是无法连接。这个博客其实是第三代博客，就是因为这个问题。一种可能的解决方案是重启虚拟机，但是发现有时候不可行。这个问题Ike参考了许多中外网站，总的来说都不适用。博客所维持时间的长短几乎就取决于什么时候出现这个数据库的问题。

Ike对Linux只是略知皮毛，连鸟哥私房菜第一卷都没看完的战五渣，上面这些问题的解决真的是瞎搞，所以要是把详细的步骤写出来反而有误人子弟之嫌。所以说，建立了这个博客只是站在长长的坡道的起点，以后还要建设邮件系统之类的东西，还要有个像模像样的主页面，但在当前看来最重要的是把MySQL学会。

域名的注册是在Godaddy上注册的，原来想用ikely.cc以暗示真名，或是ike.ly，但是.me的域名实在是便宜，10刀一年。域名前面原来有www，要去掉www很简单，只要在Godaddy的域名转发里面设置子域名转发就可以了。

关于 CUDA 中 reduction 运算的优化

Sat, 20 Jul 2013 00:00:00 GMT

最近在Udacity上学习有关基于CUDA的并行运算。在学习当中除了Udacity上面所给的资源以外，我本人还查找了很多其他资料。我计划把我所查找到的这些资料写成技术blog，以供以后查阅。

在Unit 3当中，讲到了三种常见的并行运算：reduce、scan和histogram。简单地讲，reduce运算的输入是一个数据集，和一个运算符（二值，结合性），输出为一个数据，其为数据集中的数据依次与运算符相作用后的结果，如求和、求最大值、求最小值都是reduce. Scan运算的输入是一个数组，一个二值运算符和一个identity element. 这个identity element正如0之于加，1之于乘。常见的scan运算为求累积概率。当然我这种说法很不科学，只要能意会就行了。

最常见的reduce算法就是利用了完全二叉树的结构，分两步完成：

对于这一算法的实现，文献[1]以七种算法的逐级演进说明了reduce的优化过程。下面主要讲讲这个优化思想和过程。

首先一种是二叉树结构的直接实现算法，interleaved addressing:

__global__ void reduce0(int *g_idata, int *g_odata) {
extern __shared__ int sdata[];

    // each thread loads one element from global to shared mem
unsigned int tid = threadIdx.x;
unsigned int i = blockIdx.x*blockDim.x + threadIdx.x;
sdata[tid] = g_idata[i];
__syncthreads();

    // do reduction in shared mem
     for(unsigned int s=1; s < blockDim.x; s *= 2) {
         if (tid % (2*s) == 0) {
             sdata[tid] += sdata[tid + s];
         }
     __syncthreads();
     }

    // write result for this block to global mem
if (tid == 0) g_odata[blockIdx.x] = sdata[0];
}

对于红字那一段，高度分支结构会导致性能下降，因此利用strided index将其修改成非分支结构：

for (unsigned int s=1; s < blockDim.x; s *= 2) {
    int index = 2 * s * tid;
    if (index < blockDim.x) {
        sdata[index] += sdata[index + s];
    }
    __syncthreads();
}

由于偶数strided index会产生bank conflicts（以后会讲什么是bank conflicts），我们将其改进为sequential addressing:

for (unsigned int s=blockDim.x/2; s>0; s>>=1) {
    if (tid < s) {
         sdata[tid] += sdata[tid + s];
    }
    __syncthreads();
}

Sequential addressing中，红字凸显的部分说明有一半的线程在第一循环迭代的时候就处于空闲状态。为了改进，我们采用first add during load技术。简单地说，我们采用上述过程一半的block，在刚进入线程的时候就进行一次operation，具体实现如下：

// perform first level of reduction,
// reading from global memory, writing to shared memory
unsigned int tid = threadIdx.x;
unsigned int i = blockIdx.x*(blockDim.x*2) + threadIdx.x;
sdata[tid] = g_idata[i] + g_idata[i+blockDim.x];
__syncthreads();

我认为将代码优化到这一地步已经足够了，但是令我惊讶的是，文献[1]进行了如下分析：当前代码的带宽仍没有达到GPU的上限，究其原因，由于对于核心运算的不是存储、运算的辅助性指令造成了代码的瓶颈，代码没有达到最大性能。解决的办法就是拆开循环。

分析指出，当s<=32时，有效线程减少至一束（wrap）。一束线程是SIMD（单指令多数据） synchronous的。这就意味着s<=32时不需要__syncthreads()和if (tid < s)。因此，我们可以拆解最后六个循环：

for (unsigned int s=blockDim.x/2; s>32; s>>=1)
{
    if (tid < s)
    sdata[tid] += sdata[tid + s];
    __syncthreads();
}
if (tid < 32)
{
    sdata[tid] += sdata[tid + 32];
    sdata[tid] += sdata[tid + 16];
    sdata[tid] += sdata[tid + 8];
    sdata[tid] += sdata[tid + 4];
    sdata[tid] += sdata[tid + 2];
    sdata[tid] += sdata[tid + 1];
}

值得注意的是，这减少了所有线程束的无用功，而不仅仅是最后一个线程束。

进一步地，该文献还指出，在已知迭代数的情况下，可以完全拆解循环。在只讨论二的n次方大小的数组时，我们通过模板，给出blocksize，就可以给出一个通用的reduce算法：

if (blockSize >= 512) {
    if (tid < 256) { sdata[tid] += sdata[tid + 256]; } __syncthreads();
}
if (blockSize >= 256) {
    if (tid < 128) { sdata[tid] += sdata[tid + 128]; } __syncthreads();
}
if (blockSize >= 128) {
    if (tid < 64) { sdata[tid] += sdata[tid + 64]; } __syncthreads();
}
if (tid < 32) {
    if (blockSize >= 64) sdata[tid] += sdata[tid + 32];
    if (blockSize >= 32) sdata[tid] += sdata[tid + 16];
    if (blockSize >= 16) sdata[tid] += sdata[tid + 8];
    if (blockSize >= 8) sdata[tid] += sdata[tid + 4];
    if (blockSize >= 4) sdata[tid] += sdata[tid + 2];
    if (blockSize >= 2) sdata[tid] += sdata[tid + 1];
}

函数声明变为：

template <unsigned int blockSize>
__global__ void reduce5(int *g_idata, int *g_odata)

最后，文献指出，通过算法级联的思想，可以把上文中first add during load变成multiple add.

unsigned int tid = threadIdx.x;
unsigned int i = blockIdx.x*(blockSize*2) + threadIdx.x;
unsigned int gridSize = blockSize*2*gridDim.x;
sdata[tid] = 0;
while (i < n) {
    sdata[tid] += g_idata[i] + g_idata[i+blockSize];
    i += gridSize;
}
__syncthreads();

注意这个是更改的开头部分。

参考文献：

[1] Optimizing Parallel Reduction in CUDA - Nvidia