如何阅读数学著作

原文出自kelvin.ink转载请注明出处
Email: ziyoustep@gmail.com
欢迎与感谢一切指正

前言

本文的主体内容将会介绍系统地阅读一本数学著作的方法。文章内容主要来源于笔者个人的求学经验,导师的指导,以及《如何阅读一本书》(How to read a book)的启发。《如何阅读一本书》真的是一本不可多得的好书,由 Mortimer AdlerCharles Van Doren 于1972年再版。它由浅入深介绍了阅读一本书的基本原则并把阅读分为有梯度的四个层次,明确每个层次的阅读应该达成什么样的效果。非常建议每个家庭的书架上都拥有一本这样的书。再次向两位老先生致敬。本文的内容将会有小部分与《如何阅读一本书》重复,原因是笔者的体验与书上叙述非常类似,例如我们对于“数学是一门语言”的见解是如此的一致。整篇文章的讨论都是建立在“公理化系统”这个关键概念上面,然后我们会依照这个关键概念提出阅读数学著作的基本原则。

简介

数学是一门语言。或许你不同意我的论断,但是你可以暂时先接受我的观点。语言的组成有文字,读音,使用这些文字我们就可以表达我们的思想。数学既然是一门语言,数学符号(mathmatics symbol)就是它的文字,而各种命题(proposition)就是其所要表达的思想。例如:《几何原本》中命题19为–在任何三角形中大角对大边。在这个命题中,三角形 等都是数学符号,因为他们都有相应的数学定义,代表不同的数学含义。整个命题构成了一组完整的的语义:在三角形中,角大的,其对应的边也相对比较大。整个数学领域都是在做着一模一样的事情–用规范的数学语言来表达我们所发现的某些真理。而我们要理解数学的内部逻辑就必须先理解这些数学符号,然后再理解每个命题的含义,以及命题与命题间的关系。说到命题与命题间的关系,我们就需要介绍公理化系统(Axiomatic system)。这个概念首次由欧几里得于公元前300年左右在《几何原本》(Euclid’s Elements)中提出,是数学史上极其关键的里程碑。《几何原本》使得一些离散的数学结论被连接成整体,成为结构严谨的几何学大厦。接下来的章节我们将会介绍一座数学理论大厦是怎样建成的。在进一步讨论之前我们先对一些数学名词进行简单的定义,更加严格的数学定义请参阅其他数学著作。

数学名词定义

  • 命题(Proposition): 一个可以被判定为真(true)或假(false)的陈述。
  • 公理(Axiom): 一个被当作不证自明的命题。
  • 定理(Theorem): 一个重要的已经被证明为真的命题
  • 引理(Lemma): 为了证明定理,先证明某些重要结论,这些结论称为引理
  • 推论(Corollary): 一个可以由定理简单直接推出的结论

总结一下这些数学概念之间的相关关系:

  1. 公理,定理,引理,推论都是命题
  2. 定理的证明可能没有那么直接,我们需要一些辅助性的引理帮助证明;有了定理,我们经常可以马上做一些简单推论
  3. 定理和「引理」,「推论」的主要区别是:定理比较有趣,比较有意义,有价值;而其他两者的结论我们可能不太想关心
  4. 公理和定理是公理化系统最重要的组成部分

公理化系统

公理化系统最初由欧几里得建立,目的是以一套标准化的流程来建立一个严谨的理论体系。简单而言,公理化系统就是选出一组不证自明的最为基础的公理集,然后以这些公理作为基石证明推导出其他关键定理。由此可以形成一个完备的数学理论体系,例如欧几里得建立的欧氏几何理论。公理化系统有三个重要性质,分别是自洽性(consistent), 独立性(independent), 完备性(complete)。具有这样的性质的公理系统就是好的公理系统。构建公理化系统的第一步就是选取合适的公理,选取公理的时候数学家必须尽量使得这个系统满足这三大性质。虽然在欧几里得之后,数学有了更长足的发展(例如形式公理的建立),但是绝大部分的数学分支依然沿用公理化方法来建立严谨的理论体系。我们依然可以因循这个逻辑来帮助我们的学习。

下图展示了理论大厦的整体架构,先由公理证明一批重要定理,再由已经证明的定理产生更多的定理:
Theoretical system

下图展示了公理化系统的创建过程。其中黄色的「定义」部分并不是公理化系统的主要内容。它只是在推导新的结论前定义清楚一些关键的数学概念使得所有人对这些关键概念达成共识。其过程已经在前面章节说明过了,就不再重复。
Axiomatic System

接下来我们将会介绍到欧几里得的《几何原本》以及公理化系统的突出贡献:
一切的得来并非无缘无故的,而真理也没有显得那么理所当然。《几何原本》的许多定理并非欧几里得原创,在欧几里得之前,就已经有泰勒斯,毕达哥拉斯学派,柏拉图学派等前人付出了艰苦的劳动,给出了许多零零散散的命题。而欧几里得的开创性在于他创造性地建构了公理化系统把这些零散的数学命题统合称为严谨完备的几何理论体系。开创了演绎推理法的先河。他的天才在于选取了恰当的公理,对于每个关键的数学概念给出了清晰的定义,并且对每个定理都给出了严格的证明。公理化系统避免了对问题的无限溯因,使得每个定理都有了坚实的理论基础。其中选取恰当的公理是最为艰难的挑战。你没有看错,一直认为理所当然的公理竟然是被选出来的而不是一开始就名正言顺地存在的!想象一下要从成百上千个命题中选出最为基础的公理集,并且要满足公理化系统的约束条件(自洽性,独立性,完备性)是多么困难的过程。欧几里得一共选出来5条公理5条公设,另外包含了119个定义与465个命题(定理)。在现代来看,5条公理和5条公设都是公理,所以一共是10条公理。以此为基石建立了欧氏几何大厦。

基于公理化系统的数学著作阅读方法

对公理化系统有了整体认识之后我们就开始详细介绍如何阅读数学著作。先提出一条基本原则—按照建构公理化系统的过程来阅读数学著作。也就是先理解清楚前提定义,接着阅读公理部分,再阅读引理部分,然后阅读定理部分,最后阅读推论。在这里我们提出两个问题:第一个是为什么这样阅读?第二个是为什么这种方法可行?对于第一个问题,我们的回答是:我们阅读数学著作的主要目的是要在心中重构这个理论体系,而这种阅读方式正好可以达到这样的目的。对于第二个问题,我们的回答是:这种方法可行的原因是绝大部分数学分支的理论体系沿用公理化系统体系。而一本好的著作也肯定或多或少按照这种方法进行章节安排。实际上有些书不一定会完全按照这样的结构进行安排,这个时候我们采取的方案是自己询问自己正在阅读的是公理化系统的哪一个部分。在阅读的过程中你就能够重构这个系统,如果发现一个定理的证明有不甚明了之处你也可以很快地发现问题的所在。这种方法对于我们来说至关重要,因为当我们在阅读的时候我们至少知道我们是在阅读什么。

前面说到公理与定理是公理化系统最重要的组成成分,而定义部分不是主要内容。这并不表明定义不重要。对于建构理论体系的数学家而言一切都是重要的,包括定义,公理和定理。其中,(1)定义什么? (2)如何进行定义? (3)公理的选择? 以及(4)如何对定理进行证明? 构成了建构公理化系统的4大问题。而对于一般读者而言,一切成果都已经就绪,我们不需要重复经历这个繁复的过程。这时,对我们而言,最重要的是理解定义,明白作者要讨论的问题。然后,其他的疑惑便能一步步被化解。否则,你将会不知道作者正在谈论什么,他想要为我们呈现一个怎样的结果。

举一个简单又常见的例子:


摩尔质量的定义:
单位物质的量物质所具有的质量称摩尔质量(molar mass).
英文定义:
The molar mass M is a physical property defined as the mass of a given substance divided by the amount of substance.


如果你对摩尔质量的定义有疑惑,我敢打赌你肯定对“物质”(substance),“质量”(mass),“物质的量”(amount of substance)这三个物理量不清楚或者混淆了。解决的方案是先重新思索一遍这三个量的定义,再回转过来看摩尔质量的定义。接下来的部分我们以此为例讨论当我们在阅读时如何进行逆向倒推(backward chaining),寻找支撑理论或者解释。

第一步是我们要知道我们正在阅读什么,显然这是一个定义,定义是不需要被证明的,只需要理解它包含了什么关键概念,其涵盖的范围是什么。在阅读这个定义的时候我们要问自己到底对哪些术语名词不了解,然后去了解这些定义。首先“物质的量”的定义是一阿伏伽德罗常数的数量,也就是6.022140857×1023。它是数量(quantity)意义,本质上跟一个亿,一个兆这样的量没有区别。接下来“物质”就是我们能接触到的分子原子等一切客观实体。而“质量”相对定义显得稍为复杂,大多数人知道质量却不知道质量的实质定义是什么,通常人们会把它跟重量等同,虽然很多情况下他们都不会因此导致麻烦。然而这是错误的,质量与重量是完全不同的量,人们之所以会犯这样的错误是因为他们没有时常发问自己到底正在阅读什么。现在我们就提出一个问题:到底质量的确切定义是什么?我们单独分一个段落出来讨论什么是质量。

如果我们没有特别指明,一般而言质量就等同于惯性质量。为什么会有这样的区分?因为除了惯性质量还有引力质量。为了避免复杂性,我们避开这些复杂因素,只谈论惯性质量,一般情况下我们只需要知道惯性质量就够了。以下的内容中质量一律等于惯性质量。质量的确切定义是由牛顿第二定律给出,也就是 F = ma ,变换一下就可以得到 m = F/a。牛顿首先定义了什么是,什么是加速度,然后才定义质量。可能我们看上去不太直观,仿佛是应该先有质量和加速度,而后有力;仿佛质量这个概念本来自然而然就存在的。然而事实并非如此!虽然我们在日常生活中对于质量有比较直观的感受,拿到重的东西就觉得它的质量很大,轻的东西就觉得它质量小。这种直觉很有价值,它帮助我们理解复杂的自然世界。但是牛顿在建构公理化系统的时候需要考虑更多的问题以满足公理化系统的约束条件(如自洽性,相容性,完备性)。于是他首先定义了速度,然后再导出衍生物理量加速度质量。这样做才能使得牛顿三定律建立的经典力学大厦严谨与稳固。

了解了前面三个定义之后,我们很容易就可以明白摩尔质量的定义,我们可以把其定义翻译成如下的句子:


摩尔质量 = (单位)(物质的量)的(物质)所具有的(质量)
摩尔质量 = (1unit) × (6.022140857×1023) (原子或分子) 的 (质量)


上面的括号里的内容呈一一对应惯性。如果我们要理解3摩尔碳分子的质量,只需要代入到上面的定义就可以很清楚地了解其涵义了。即:


3摩尔碳分子的质量 = (3unit) × (6.022140857×1023) (碳分子) 的 (质量)


至此我们完结了对这个例子的讨论,我们没有介绍如何阅读定理,不过基本的原则是一致的。在阅读时我们先确定自己阅读的是什么部分(定义?定理?公理?),然后寻找与它有关的内容(定理或引理),了解它在整座大厦中担任了什么角色。当我们完成了阅读时我们就能够重构这个体系,并且画出这个体系的树状图,树状图的根就是公理,茎和枝叶就是定理。

总结一下我们在这一节到底谈论了什么。我们阐明了阅读数学著作的核心方向:重构理论系统,并且我们提出了一个指导性的阅读原则:按照建构公理化系统的过程来阅读。最后我们还举了一个例子来说明为什么这样的阅读方式可以帮到我们。

几何原本中的公理化系统

我们来欣赏一下欧几里得的几何原本的前五页(引自陕西科技出版社2003):
Euclid Elements Index
Euclid Elements Definition
Euclid Elements Definition and Axiom
Euclid Elements Axiom and Theorem 1
Euclid Elements Poof of Theorem 1

对于《几何原本》这本书的架构,我们有几点说明。第一是:它是按照公理化系统的架构进行组织的(因为它是开创这种形式的第一本著作)。可以看到,一开始欧几里得给出了一些基本定义,然后给出他的10大公理,然后着手证明他的命题(定理)。注意目录处的命题都是欧几里得要证明的定理。前面已经介绍过,一个命题如果为真,并且非常有趣我们就称之为定理。后面的内容都是提出更多的定义,然后证明更多的定理。我们有第二点要说明:每一个定理的证明必定由前面已经证明的定理或者公理作为支撑。我们可以看第一个命题的证明,由于它是第一个命题,所以它必须只用定义跟公理来证明,仔细看每一步的注释你就会发现的确是遵循这一逻辑。我们要再次强调对读者而言定义的重要性是绝对不能忽视的,你必须清楚你正在探讨的究竟是一个什么样的问题。
我们就此结束对于《几何原本》的讨论,下面将会简单讨论一下牛顿的《自然哲学的数学原理》中相似的结构。

自然哲学的数学原理中的公理化系统

本节我们将不会进行展开讨论,我们只会介绍到牛顿的著作《自然哲学的数学原理》中的确应用到了公理化系统的思想。我们先来看看它的目录(引用自商务印书馆汉译世界学术名著丛书):
Philosophiæ Naturalis Principia Mathematica Index
可以看到目录中牛顿先洋洋洒洒进行了大量的定义,然后马上开出他的公理,然后下面的部分分章节逐个逐个讨论与证明。一开出公理,牛顿做的第一件事情就是证明一批重要定理(例如平行四边形定则)为后面的讨论提供理论支撑。有兴趣的读者可以自己找来看看,不必把它通读(我也只是粗略看过),只需要欣赏其严密优雅的结构即可。

下面是三大定律(Axiom)的中文版本:
Philosophiæ Naturalis Principia Mathematica Axiom 1-2
Philosophiæ Naturalis Principia Mathematica Axiom 2-3

可以看到《自然哲学的数学原理》的结构工整而优雅,一本好的数学著作通常都会遵循相似的排版原则。我们都可以应用相似的原则来阅读。

总结

我们来总结一下整篇谈论了些什么。我们首先说明了数学是一门语言,这门语言的文字是数学符号;句子是命题,公理,定理等;架构就是公理化系统。然后我们详细说明了什么是公理化系统,并且解释为什么它对于我们来说非常中要。接着我们又提出了阅读数学著作要遵循的基本原则。我们举了两个例子(《几何原本》和《自然哲学的数学原理》)来说明这个原则的确有效。我们就此结束本文的关键讨论,希望能够给你带来一点帮助。

Object Oriented Analysis with UML 1

Object Oriented Analysis Procedure

This is the first part of our OO analysis series posts. What we are going to talk about here is how to construct use case diagram, use case description and class diagram. First, we construct the use case diagram from user requirements. This will give us an overview to the system that we are going to build. Base on the use case diagram and user requirements, we then finish the use case description. This will show us more details about each use cases. This phase also helps to identify the potential classes and attributes of each class in the next phase. Finally we make the class diagram, this is the blue print of the system that we are gonna develop. (Note: This article reference from professor T.H Tse’s lecture notes , The university of Hong Kong)

  1. Construct Use Case Diagram
  2. Construct Use Case Description
  3. Construct Class Diagram

Constructing Use Case Diagram

Steps of Constructing Use Case Diagram

The following are the recommended procedure for constructing use case diagram:

  1. Identify actors and use cases.
  2. Identify use case relationships.
  3. Construct use case diagram.

Structure of Use Case Diagram

This figure shows the structure and elements of a use case diagram:
Use Case Diagram Structure

Constructing Use Case Discription (For each use case)

Steps of Constructing Use Case Discription

The following are the recommended procedure for constructing use case description:

  1. Document use case name, actors, descriptions .etc.
  2. Document preconditions, postconditions, assumptions.
  3. Document normal course.
  4. Document alternative course.
  5. Add-in include use cases.
  6. Add-in extend use cases.
  7. Add-in exceptions.
  8. Finish.

Use Case Description Template

This figure shows the template of use case description:
Use Case Description Template

Constructing Class Diagram

Structure of Class Diagram

This figure shows the structure and elements of a class diagram:
Class Diagram Structure

Steps of Constructing Class Diagram

The following are the recommended procedure for constructing class diagram:

  1. Identify classes.
  2. Keeping the right classes.
  3. Identify class relationships.
  4. Keeping the right class relationships.
  5. Identify attributes and methods.
  6. Keiiping the right attriutes and methods.
  7. Constructing class Diagram.

Indentify Classes

  • Usually be nouns.
  • Must Meaningful in application domain.
  • Must be persistance.

Keeping the Right Classes

  • Eliminate redundant classes.
  • Eliminate irrelevant classes.
  • Eliminate vague classes.
  • Eliminate attributes.
  • Eliminate operations(methods).
  • Eliminate role(relationship).
  • Eliminate implementation constructs.

Identify Relationships

Identify Association

Maybe related to:

  • Ownership
    • Has-a
    • Has-many
    • Uses-a
    • Uses-many
  • Directed actions
  • Physical location
  • Communication

Identify Aggeregation

  • Indicated by Is-part-of relationship
    • Has-a
    • Has-many

Identify Inheritance

  • Indicated by Is-a relationship
  • Generalization(Bottom-up)
  • Specialization(Top-down)

Keeping the Right Association

  • Eliminate implementation construct associations.
  • Eliminate actions.
  • Eliminate missnamed associations.
  • Add-in role names.
  • Add-in multiplicity.
  • Add-in missing associations.

Identify Attributes

  • Usually be nouns.
  • Indicated by possessive phrases.
  • Indicated by adjectives.

Keeping the Right Attributes

  • Eliminate discordant attributes.
  • Eliminate classes.
  • Eliminate internal values.
  • Indentifiers may or may not be attributes.

Further Discussion

There is still one thing we haven’t discussed yet. That’s how to identify methods(operations) of class diagram. Before doing so, we need the help of other dynamic models like sequence diagram and state diagram. And these topics will be covered in OO analysis with UML 2 on kelvin.ink.

Phases of Database System Design

Introduction

This article is gonna give a brief overview to the phases of database system design which is the kernel of database life cycle. The whole article here is discussing what we need to do and how to do in each phases of database design.

After each phase, we will get the corresponding deliverable–The so called schema. In the following section, we will introduce the data model first, and then the phases of database design. A data model is collection of concepts for describing the data in a database. While A schema is a description of a particular collection of data, using a given data model. The relationship between data model, schema, and phases of design are as follow:
Before we start the design process, we choose a data model for our database. Then, we do the design. In each step of our design process, we obtain the corresponding schema such as conceptual schema, logical schema .etc.

The following figure shows the database design and application development in parallel:
Phases of Database Design

Lets start with data models.

Data Models

There are three kinds of data models whose abstraction level are from high to low:

  • Conceptual model [e.g: ER-model]
  • Logical model [e.g: Relational-model]
  • Physical model
  1. Conceptual Model
    A data model that is independent of all implementation details like target DBMS, storage structure, security, performance issue.
    Example: ER model
  2. Logical Model
    A logical data model describes the data in as much detail as possible, without regard to how they will be physical implemented in the DBMS.
    Examples: By ANSI -> Hierarchical Model, Network Model, Relational Model and Object Oriented Model
  3. Physical Model
    Data model that involved data management technology.

The Four Database Design Phases

There are four steps in database design procedure:

1. Requirements collection and analysis

Task: Analyse user requirements.
Deliverables: Data requirements, Functional requirements

2. Conceptual design

Task: Create conceptual model
Deliverables: Conceptual schema(Conceptual model) e.g: ER-Model

3. Logical design(Data model mapping)

Task: Maps conceptual model to the implemented logical model of target DBMS.
Deliverables: Logical schema(Logical model) e.g: Relational Schema
Remarks: What we need to do(focus) on in this phase: Integrity, Constraints, Normalization
Note1: You may assume that the logical schema is just a conceptual schema with more details
Note2: Logical design may or may not DBMS independent.

4. Physical design

Task: Determines how a database is implemented in a DBMS.The internal storage structures, file organizations, indexes, access paths, and physical design parameters are completed in this phase.
Deliverables: Internal schema(Physical model) e.g: File organization, Indexes
Remarks: What we need to do(focus on) in this phase: Denormalization, Indexing, Derived data, Storage structure, Partitioning, View, Security, Query Optimization, Backup, Recovery, Concurrency control, Access control

It’s hard to distinguish conceptual and logical model, the boundary is blur. It will be safe to think logical model as a conceptual model with more details.

Or, we can see it from another point of view:

Different DBMS are using different data model, we can consider these data model as logical model. For example, MongoDB is using document-oriented model, Oracle Berkeley DB XML is using XML model and MySQL is using relational model. These are all so called logical model. Note that the abstraction level of conceptual model is higher than that of logical model. So, it’s hard to transform from one logical model to another logical model. But, transforming from conceptual model to the three logical models above is fairy easy. This is one main difference between conceptual model and logical model.
This concludes the discussion.

Further Discussion

Further discussion of databases are all based on the phases of database design. For example: normalization and constraints checking resides in logical design; while denormalization, indexing and query optimization resides in physical design. We will give more discussion to these topics in other posts of kelvin.ink