《数学之美》读后感-京东云开发者社区

### 1 前言

近代科学实验奠基人之一的伽利略曾经说过“数学是上帝描写自然的语言”，在我们成长的道路上也一直都有声音告诉我们数学知识很重要，却很少有人说清楚数学为什么重要？哪里重要？《数学之美》的作者吴军使用通俗易懂、生动活泼的语言对其进行详细阐述，书中描述的工程思维更是作为工程师应该学习的思维模式。下面简单分享本人阅读此书的总结和心得，希望引起大家对《数学之美》的阅读兴趣。

### 2 《数学之美》概述

《数学之美》是人民邮电出版社于2012年5月（2020年5月发行第三版）出版的图书，作者吴军，书中将高深的数学原理讲得更加简单明了，让非专业读者也能领略数学的魅力。通过具体实例教会读者在解决问题时如何化繁为简，如何用数学去解决工程问题，如何跳出固有思维不断去思考创新等。

#### 2.1 作者介绍

吴军，男，汉族，1967年4月生， 博士，毕业于清华大学和约翰霍普金斯大学。前Google高级资深研究员、原腾讯副总裁、计算机科学家、畅销书作家。 硅谷风险投资人、工业和信息化部顾问、约翰·霍普金斯大学工学院董事。人工智能、自然语言处理和网络搜索专家、上海交通大学客座教授。Google自动问答系统和许多创新产品的负责人，是当前Google中日韩文搜索算法的主要设计者。有《数学之美》、《浪潮之巅》、《文明之光》、《全球科技通史》等16本著作。

#### 2.2 内容简介

如书名所述，数学知识贯穿始终，且与作者的工作背景紧密相关。本书内容大概包括以下几个方面：数学工具、自然语言处理、搜索算法等相关的一些概念和模型，还介绍了自然语言处理领域的几位大家。

### 3 努力抽丝剥茧，看问题的本质

#### 3.1 统计语言模型-二元模型

自然语言从它产生开始，逐渐演变成一种上下文相关的信息表达和传递的方式，因此让计算机处理自然语言一个基本的问题就是为自然语言这种上下文相关的的特性建立数学模型。这个数学模型就是自然语言处理中的统计语言模型。

例：①“王某某毕业于大连海事大学。”②“大某业王事海学于毕某连大。”

上世纪70年代的科学家试图判断文字序列是否合乎文法、含义是否正确等来建立数学模型，这条路由众多科学家用了15年时间验证是走不通的。 而贾里尼克用一个简单的统计模型搞定这个问题，出发点也很简单——一个句子是否合理，就看它出现的可能性大小如何。显然，第一个句子比第二个句子出现的概率大很多很多。假定S表示某一个有意义的句子，由一连串特定顺序排列的词w1， w2，·······wn组成，这里n是句子的长度。此时，句子S在文本中出现的可能性可以被估算。公式如下：

![](//img1.jcloudcs.com/developer.jdcloud.com/d41f63b0-e4fb-4d04-9278-c8e6847f211220220525141232.png)

从计算上来看，第一、二个词条件概率相对来说还好计算，但从第三个词开始因为涉及变量越来越多计算也越来越难。最后一个词的条件概率可能性太多，无法估算。这时，俄国数学家马尔可夫提出假设，即任意一个词wi出现的概率只同它前面的词有关，此时句子S出现的概率就变的简单了。

![](//img1.jcloudcs.com/developer.jdcloud.com/18daf6f2-fbc7-4377-9d8e-46489a9f701920220525141243.png)

该公式对应的统计语言模型是二元模型。

#### 3.2 心得体会

用这么简单的数据模型解决复杂的语音识别、机器翻译等问题，除了数学本身的美妙之外，是因为贾里尼克和马尔可夫两个人发现问题的本质：①一句话是否合理，要看这句话出现的可能性大小；②（假设）任意一个词出现的概率只与它前一个词语有关。无论什么时候，努力发现问题的本质才能更好的解决问题。

因为我是一名测试开发工程师，所以从我的角度给大家举一个简单的例子。工作中接一个新的测试需求之后，不会立即着手测试，一定会充分了解相关业务流程和代码改动点，确认自己要测的内容是什么。

测试之前的准备工作（也许只是我这个新手村成员才会这样）：

1. 看PRD并记录疑问点；
2. 找产品学习并学习相关业务流程；
3. 看提测文档和提测代码并解决疑问点，需要时根据测试流程提出自己的诉求；
4. 结合业务知识确定功能、回归、异常的测试范围或测试点。

当然，遇到问题时，也不会茫然的只是去解决问题，而是充分定位造成问题的根本原因是什么。

### 4 古德-图灵估计原理对于没有看见的事件，我们不能认为它发生的概率就是零

#### 4.1 古德-图灵估计

为解决上述统计语言模型训练时的统计样本不足时的概率估计问题，古德和图灵提出古德-图灵估计方法。该方法在统计中相信可靠的统计数据，而对不可信的统计数据打折扣，同时将折扣出来的那一小部分给予未看见的事件。如下图，从左到右的变化，把一部分看得见的事件的概率分布给未看见的事件。

![](//img1.jcloudcs.com/developer.jdcloud.com/09430947-6817-4bc6-852f-a33bacf9f5a820220525141331.png)

下面以统计词典中的每个词的概率为例，来说明古德-图灵估计公式。假设在语料库中出现r次的词有Nr个，未出现的词数量为N0。语料库的大小为N，那么

![](//img1.jcloudcs.com/developer.jdcloud.com/53c6bdfe-5d6a-43e6-8951-1104204fdd4e20220525141353.png)

此时，出现r次的词在整个语料库中的相对频度则是rNr/N。很显然，当r比较小时它的统计可能不可靠。因此在计算那些出现r次的词的概率时，要使用一个更小一点的次数，是dr（而不直接使用r），

![](//img1.jcloudcs.com/developer.jdcloud.com/6e9b3d5d-f0b9-46b1-a999-793bec4e854720220525141406.png)

一般来说，出现一次的词的梳理比出现两次的多，出现两次的比出现三次的多，这种规律称为Zipf定律，即Nr+1<Nr。因此，一般情况下dr<r，而dr>0。这样就给未出现的词赋予了一个很小的非零值，从而解决了零概率的问题。同时，下调了出现频率很低的词的概率。

#### 4.2 心得体会

工作中，我们要站在“用户”（真实用户、业务运营人员等）的角度去思考可能会出现的所有业务场景。“理论上”、“应该”、“实际上”等不会出现的业务场景，只要它是有可能发生的，进行系统设计或者开发测试的时候就需要考虑到应对措施。

当然，相信其实大家一直都在这么做。产品同学设计系统时对系统健壮性的执着，开发同学写代码时对于系统稳定性的坚持，测试同学非要对系统进行异常测试的固执，都是为了尝试解决可能没有看见的事件。

### 5 注重细节，以小抓大

#### 5.1 信息熵

信息是个很抽象的概念。人们常常说信息很多，或者信息较少，但却很难说清楚信息到底有多少。比如一本五十万字的中文书到底有多少信息量。直到1948年，香农提出了“信息熵”的概念，才解决了对信息的量化问题。一条信息的信息量和它的不确定性有直接关系，可以认为信息量就等于不确定性的多少。比如说，对于我们一无所知的事情，需要了解大量的信息。相反，如果对某件事比较了解就不需要太多的信息。

那么如何将信息量化呢？书中有一个简单易懂的例子，假设世界杯决赛圈32强已经产生，那么变量“2018年俄罗斯世界杯足球赛32强中，谁是世界杯冠军？”的信息量是多少呢？这时，我问一个知道比赛结果的观众“哪支球队是冠军”？他不愿意直接告诉我，而让我猜，并且我每次猜需要告诉他一元钱才告诉我是否猜对了，那么我需要花多少钱才能知道谁是冠军呢？我可以把球队编上号，从1到32。然后提问：“冠军在1-16号中吗？”假如他告诉我猜对了，我会接着问：“冠军在1-8号中吗？”假如他告诉我猜错了，我自然知道冠军对在9-16号中。这样最多需要五次，我就能知道哪支球队是冠军。所以，谁是世界杯冠军这条消息的信息量只值5元钱。

假设变量x，P(x)是该变量是此信息的概率，信息熵的具体计算公式定义如下：

![](//img1.jcloudcs.com/developer.jdcloud.com/56b5c97b-d14a-45ac-9405-ae328e4981f220220525141800.png)

#### 5.2 心得体会

信息熵虽然是在自然语言处理里面很小的概念，但它是整个信息论的基础。它对于通信、数据压缩、自然语言处理都有很大的指导意义。作为一名工程师，工作中的每一个小细节在我们眼里都应该至关重要。

例如， Spring框架中最常用的三个非空注解@NotNull、@NotEmpty和@NotBlank，它们都可以被用来校验非空，但也都有自己的小特点。开发同学需要根据不同的业务场景慎重选择使用，测试同学需要根据不同的注解设计不同的测试用例。

@NotNull：不能为null，但可以为empty；
@NotEmpty：不能为null，而且长度必须大于0；
@NotBlank：只能作用在String上，不能为null，而且调用trim()后长度必须大于0；

### 6 工程上简单实用的方法最好

枪迷或者看过电影《战争之王》的人也许还记得影片开头的一段话：“（在所有轻武器中）最有名的是AK-47冲锋枪”，因为它从不卡壳，不易损坏，可在任何环境下使用，可靠性好，杀伤力大并且操作简单。Google的AK-47是排序算法Ascorer，由美国工程院院士阿米特辛格博士设计。辛格秉承的理念是：在工程上简单实用的方法最好。作者之前一直在学术界学习和工作，凡事倾向于寻找完美的解决方案。解决网络中搜索作弊问题时，他可以设计一个可用且“完美”的分类器，但由于当时的Google还没有MapReduce这种并行计算工具，实现和训练这个分类器需要三四个月的时间。但因为辛格坚持工程上简单实用方法最好的原则，作者用了一周时间设计出简单可用分类器，并且一两个月就把作弊的数量减少了一半。（ps：书中关于这个理念背后的意义和优点作者用了一章纯语言类的“例子”去讲解，希望大家可以阅读原文直观感受。）

在计算机科学领域，一个好的算法应该像AK-47冲锋枪那样：简单、有效、可靠性好而且容易读懂。工作中产品同学的设计流程图，开发同学写的代码，测试同学设计的测试用例都应如此，因为工程上简单实用的方法最好。 这里仅站在测试同学的角度表达自己对测试用例设计的看法，求大佬们别打脸：

- 用例应当在形式上是简单的，即可读性好。（以后的自己、研发、产品等可以理解） 
- 测试用例的实用性应经得起质疑也值得坚持。
- 一条测试用例尽可能覆盖多的测试点。 
- 保证测试用例的复用性和实现性。

### 7 推荐

#### 7.1 推荐语

这本书讲的不单单是数学，更是告诉我们工程思维应该是什么样的。作为工程师需要明白“大道至简”是什么，如何将其运用到实际生活中。解决问题的时候，了解其背景与全局之后，以最简单的解决方法去思考往往会带来惊喜。最有用的模型或者算法，背后的原理或想法都是很简单的。因此，当你对一个领域的非常之精通时，向不熟悉它的人介绍时可以用简单的例子和语言。

本人才疏学浅简单的三言两语并没有把本书的所有精华讲述出来，可能还有我没有读懂的精彩。希望看见这篇文章的你可以亲自去阅读它，去发现更多的美好。

#### 7.2 本书经典语录

- 数学的魅力就在于将复杂的问题简单化。
- 数学、文字和自然语言一样，都是信息的载体，它们之间原本有着天然的联系。语言和数学的产生都是为了同一目的——记录和传播信息。
- 发觉真理在形式上从来是简单的，而不是复杂和含混的。

------------

###### 自猿其说Tech-JDL京东物流技术与数据智能部
###### 作者：王莹莹