条件分支的两种实现方法

1. 控制的条件转移（条件控制）

   通过直接改变控制流，来实现条件分支

2. 数据的条件转移（条件传送）

   通过对各分支无条件运算，根据条件选取结果，来实现条件分支

   更符合现代处理器的性能特性，充分利用了处理器时间，避免由于空等或分支预测错误的惩罚造成处理器性能的浪费。但使用条件受限，要慎重使用。只有当各分支没有其他副作用时，才可考虑选择条件传送。

现代处理器的分支预测

现代处理器使用分支预测逻辑来尝试预测每个分支可能的走向，这样就可以不用等待求出分支条件的具体结果，从而有效利用现代处理器的高性能。

预期的正确率是90%，但在复杂情况下，这一概率依旧很低。

一旦处理器做出预测，就会按照预测的走向继续往下执行指令，如果计算结果发现预测正确，就皆大欢喜；如果发现预测错误，则丢弃从分支入口处到当前时间点所做的全部与该分支有关的工作，从另一个分支入口重新开始计算。

这个丢弃行为所带来的时间损耗，即称为“分支预测错误的处罚”

while 循环的两种翻译

1. 调转到中间（jump to middle）

   通过一个无条件跳转，直接跳转到测试条件相应的语句块，将while循环转换为do-while循环。

2. guarded-do

   先测试条件，若不成立，直接跳过循环；若成立，则顺序往下执行，循环代码转换为do-while循环。

switch 语句使用跳转表

使用switch语句可以十分高效地实现跳转，在分支数目较多的情况下，能够节省大量对条件的计算时间，得到较高的运行效率。其中起到关键作用的就是被称为“跳转表（jump table）”的数据结构。

跳转表被实现为一个数组，数组中元素是代码段的地址。GCC 在 C 语言的基础上进行了扩展，可以通过结合使用两个取地址符&&和代码标号，直接获取代码段的地址。这一点需要知悉。

注意，switch 的开关变量n是整数。

过程

过程，即 C 语言中的函数（function），在其他语言中也称方法（method）、子例程（subroutine）、处理函数（handler）等。

过程具有三个属性或者说要素：

1. 传递控制
2. 传递数据
3. 分配和释放内存

其中“传递控制”主要是指的对程序运行位置，即程序计数器值的压栈和出栈。

必须要在内存中存放局部数据的常见情况

1. 局部数据较多，只用寄存器不足以存放
2. 对局部变量使用了取地址符&
3. 有的局部变量是数组或是结构体，要能够通过数组或结构的访问方式进行访问

其中第2、3两条说的其实是一个意思。二者都是因为必须要对局部变量产生一个“地址”，只有这样才能够符合 C 语言的语法标准；但是寄存器是不存在“地址”这个概念的，也不可能通过内存地址的方式进行索引，因此处理器必须要将这些存在“地址需求”的变量存储到内存中。

注意，栈指针%rsp所指为当前栈顶的低位字节，也就是说，在小端系统中，假如栈顶存储了一个 8 字节内容，则该内容的最低位字节（从右往左第0~7位）的内存地址就是%rsp的内容，而次低位字节（第8~15位）则存储在1(%rsp)，也就是%rsp+1的地址上，以此类推，最高位字节（第56~63位）才应保存在7(rsp)的地址上。而8(%rsp)所指的又是上一个入栈的元素的低位字节了。

寄存器中值的保存

寄存器组是唯一被所有过程共享的资源

被调用者保存的寄存器

16 个通用寄存器中，%rbx、%rbp、%r12、%r13、%r14、%r15共计 6 个寄存器，被划分为“被调用者保存”寄存器。所谓“被调用者保存”，指的是“被调用”地过程有责任维护好调用发生当时，这些中存在的值。

维护的方式有两种：

1. 不使用相应寄存器
2. 在使用相应寄存器之前，将其储存的值入栈

这两种方式只需择一即可，也就是说，只有需要用到的寄存器才被入栈，如果在整个过程中不需要使用某些寄存器，也就不需要将其入栈。

调用者保存的寄存器

除栈指针%rsp外，其他所有通用寄存器均为“调用者保存”寄存器。

此处暂时存疑，不知道是仅限于通用寄存器还是所有寄存器。按逻辑来说，应该是仅限于通用寄存器，但书上表述不太严谨。

这些寄存器包括：%rax、%rcx、%rdx、%rsi、%rdi、%r8、%r9、%r10、%r11，共计 9 个通用寄存器。对应用法见下表。

所谓“调用者保存”，也就是说被调用的过程对这些寄存器中的值不负任何责任，所有有用值的保存和恢复，即入栈和出栈操作，都是调用者（或者说主调函数）的责任，在调用其他过程之前，就必须自行保存好上述寄存器中的值，以免被所调用的过程覆盖重写。

递归

站在机器的视角来看，递归调用和一般的调用没有什么区别。每次调用都产生一个独立的存储空间，用来保存每次调用所需的各种状态信息。

递归在机器层面是一个很自然的过程。

1. 概念介绍

装饰器（decorator），又称“装饰函数”，即一种返回值也是函数的函数，可以称之为“函数的函数”。其目的是在不对现有函数进行修改的情况下，实现额外的功能。最基本的理念来自于一种被称为“装饰模式”的设计模式。

在 Python 中，装饰器属于纯粹的“语法糖”，不使用也没关系，但是使用的话能够大大简化代码，使代码更加易读——当然，是对知道这是怎么回事儿的人而言。

想必经过一段时间的学习，大概率已经在 Python 代码中见过@这个符号。没错，这个符号正是使用装饰器的标识，也是正经的 Python 语法。

语法糖)：指计算机语言中添加的某种语法，这种语法对语言的功能并没有影响，但是更方便程序员使用。通常来说使用语法糖能够增加程序的可读性，从而减少程序代码出错的机会。

2. 运行机制

简单来说，下面两段代码在语义上是可以划等号的（当然具体过程还是有一点微小区别的）：

1
2
3
4
5
6
7
8

def IAmDecorator(foo):
    '''我是一个装饰函数'''
    pass

@IAmDecorator
def tobeDecorated(...):
    '''我是被装饰函数'''
    pass

与：

1
2
3
4
5
6
7
8

def IAmDecorator(foo):
    '''我是一个装饰函数'''
    pass

def tobeDecorated(...):
    '''我是被装饰函数'''
    pass
tobeDecorated = IAmDecorator(tobeDecorated)

可以看到，使用装饰器的@语法，就相当于是将具体定义的函数作为参数传入装饰器函数，而装饰器函数则经过一系列操作，返回一个新的函数，然后再将这个新的函数赋值给原先的函数名。

最终得到的是一个与我们在代码中显式定义的函数同名而异质的新函数。

而装饰函数就好像为原来的函数套了一层壳。如图所示，最后得到的组合函数即为应用装饰器产生的新函数：

这里要注意一点，上述两段代码在具体执行上还是存在些微的差异。在第二段代码中，函数名tobeDecorated实际上是先指向了原函数，在经过装饰器修饰之后，才指向了新的函数；但第一段代码的执行就没有这个中间过程，直接得到的就是名为tobeDecorated的新函数。

此外，装饰函数有且只能有一个参数，即要被修饰的原函数。

3. 用法

Python 中，装饰器分为两种，分别是“函数装饰器”和“类装饰器”，其中又以“函数装饰器”最为常见，“类装饰器”则用得很少。

3.1 函数装饰器

3.1.1 大体结构

对装饰函数的定义大致可以总结为如图所示的模板，即：

由于要求装饰函数返回值也为一个函数的缘故，为了在原函数的基础上对功能进行扩充，并且使得扩充的功能能够以函数的形式返回，因此需要在装饰函数的定义中再定义一个内部函数，在这个内部函数中进一步操作。最后return的对象就应该是这个内部函数对象，也只有这样才能够正确地返回一个附加了新功能的函数。

如图一的动图所示，装饰函数就像一个“包装”，将原函数装在了装饰函数的内部，从而通过在原函数的基础上附加功能实现了扩展，装饰函数再将这个新的整体返回。同时对于原函数本身又不会有影响。这也是“装饰”二字的含义。

这个地方如果不定义“内部函数”行不行呢？

答案是“不行”。

3.1.2 关于结构的解释

让我们来看看下面这段代码：

1
2
3
4
5
6
7
8
9

>>> def IAmFakeDecorator(fun):
...     print("我是一个假的装饰器")
...     return fun
...
>>> @IAmFakeDecorator
... def func():
...     print("我是原函数")
...
我是一个假的装饰器

有点奇怪，怎么刚一定义，装饰器扩展的操作就执行了呢？

再来调用一下新函数：

1
2

>>> func()
我是原函数

诶呦奇了怪了，扩展功能哪儿去了呀？

不要着急，我们来分析一下上面的代码。在装饰函数的定义中，我们没有另外定义一个内部函数，扩展操作直接放在装饰函数的函数体中，返回值就是传入的原函数。

在定义新函数的时候，下面两段代码又是等价的：

1
2
3
4
5

>>> @IAmFakeDecorator
... def func():
...     print("我是原函数")
...
我是一个假的装饰器

和

1
2
3
4
5

>>> def func():
...     print("我是原函数")
...
>>> func = IAmFakeDecorator(func)
我是一个假的装饰器

审视一下后一段代码，我们可以发现，装饰器只在定义新函数的同时调用一次，之后新函数名引用的对象就是装饰器的返回值了，与装饰器没有半毛钱关系。

换句话说，装饰器本身的函数体中的操作都是当且仅当函数定义时，才会执行一次，以后再以新函数名调用函数，执行的只会是内部函数的操作。所以到实际调用新函数的时候，得到的效果跟原函数没有任何区别。

如果不定义内部函数，单纯返回传入的原函数当然也是可以的，也符合装饰器的要求；但却得不到我们预期的结果，对原函数扩展的功能无法复用，只是一次性的。因此这样的行为没有任何意义。

这个在装饰函数内部定义的用于扩展功能的函数可以随意取名，但一般约定俗成命名为wrapper，即“包装”之意。

正确的装饰器定义应如下所示：

1
2
3
4
5
6

>>> def IAmDecorator(fun):
...     def wrapper(*args, **kw):
...         print("我真的是一个装饰器")
...         return fun(*args, **kw)
...     return wrapper
...

3.1.3 参数设置的问题

内部函数参数设置为(*args, **kw)的目的是可以接收任意参数，关于如何接收任意参数的内容在前面的函数参数部分已经介绍过。

之所以要让wrapper能够接收任意参数，是因为我们在定义装饰器的时候并不知道会用来装饰什么函数，具体函数的参数又是什么情况；定义为“可以接收任意参数”能够极大增强代码的适应性。

另外，还要注意给出参数的位置。

要明确一个概念：除了函数头的位置，其他地方一旦给出了函数参数，表达式的含义就不再是“一个函数对象”，而是“一次函数调用”。

因此，我们的装饰器目的是返回一个函数对象，返回语句的对象一定是不带参数的函数名；在内部函数中，我们是需要对原函数进行调用，因此需要带上函数参数，否则，如果内部函数的返回值还是一个函数对象，就还需要再给一组参数才能够调用原函数。Show code：

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

>>> def IAmDecorator(fun):
...     def wrapper(*args, **kw):
...         print("我真的是一个装饰器")
...         return fun
...     return wrapper
...
>>> @IAmDecorator
... def func(h):
...     print("我是原函数")
...
>>> func()
我真的是一个装饰器
<function func at 0x000001FF32E66950>

原函数没有被成功调用，只是得到了原函数对应的函数对象。只有进一步给出了下一组参数，才能够发生正确的调用（为了演示参数的影响，在函数func的定义中增加了一个参数h）：

1
2
3

>>> func()(h=1)
我真的是一个装饰器
我是原函数

只要明白了带参数和不带参数的区别，并且知道你想要的到底是什么效果，就不会在参数上犯错误了。并且也完全不必拘泥上述规则，也许你要的就是一个未经调用的函数对象呢？

把握住这一点，嵌套的装饰器、嵌套的内部函数这些也就都不是问题了。

3.1.4 函数属性

本小节内容启发于廖雪峰的官方网站-Python 教程-函数式编程-装饰器

还应注意的是，经过装饰器的修饰，原函数的属性也发生了改变。

1
2
3
4
5

>>> def func():
...     print("我是原函数")
...
>>> func.__name__
'func'

正常来说，定义一个函数，其函数名称与对应的变量应该是一致的，这样在一些需要以变量名标识、索引函数对象时才能够避免不必要的问题。但是事情并不是那么顺利：

1
2
3
4
5
6

>>> @IAmDecorator
... def func():
...     print("我是原函数")
...
>>> func.__name__
'wrapper'

变量名还是那个变量名，原函数还是那个原函数，但是函数名称却变成了装饰器中内部函数的名称。

在这里我们可以使用 Python 内置模块functools中的wraps工具，实现“在使用装饰器扩展函数功能的同时，保留原函数属性”这一目的。这里functools.wraps本身也是一个装饰器。运行效果如下：

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

>>> import functools
>>> # 定义保留原函数属性的装饰器
... def IAmDecorator(fun):
...     @functools.wraps(fun)
...     def wrapper(*args, **kw):
...         print("我真的是一个装饰器")
...         return fun(*args, **kw)
...     return wrapper
...
>>> @IAmDecorator
... def func():
...     print("我是原函数")
...
>>> func.__name__
'func'

大功告成！

3.2 类装饰器

本节部分参考[Python3 文档-复合语句-类定义]和[python 一篇文章搞懂装饰器所有用法]中类装饰器相关部分

类装饰器的概念与函数装饰器类似，使用上语法也差不多：

1
2
3

@ClassDecorator
class Foo:
    pass

等价于

1
2
3

class Foo:
    pass
Foo = ClassDecorator(Foo)

在定义类装饰器的时候，要保证类中存在__init__和__call__两种方法。其中__init__方法用以接收原函数或类，__call__方法用以实现装饰逻辑。

简单来讲，__init__方法负责在初始化类实例的时候，将传入的函数或类绑定到这个实例上；而__call__方法则与一般的函数装饰器差不多，连构造都没什么两样，可以认为__call__方法就是一个函数装饰器，因此不再赘述。

3.3 多个装饰器的情况

多个装饰器可以嵌套，具体情况可以理解为从下往上结合的复合函数；或者也可以理解为下一个装饰器的值是前一个装饰器的参数。

举例来说，下面两段代码是等价的：

1
2
3
4

@f1(arg)
@f2
def func(): 
    pass

和

1
2
3

def func(): 
    pass
func = f1(arg)(f2(func))

理解了前面的内容，这种情况也很容易掌握。

4. 总结

本文介绍了 Python 中的装饰器这一特性，详细讲解了装饰器的实际原理和使用方式，能够大大帮助学习者掌握有关装饰器的知识，减小读懂 Python 代码的阻力，写出更加 pythonic 的代码。

参考资料

[1] Python3 术语表-装饰器

[2] Python3 文档-复合语句-函数定义

[3] Python3 文档-复合语句-类定义

[4] 语法糖

[5] 廖雪峰的官方网站-Python 教程-函数式编程-装饰器

1 概念引入

在之前的教程中，我们已经接触过一些典型的for语句，比如：

1
2
3
4
5
6
7
8
9

>>> list_example = [0, 1, 2, 3, 4]
>>> for i in list_example:
...  print(i)
...
0
1
2
3
4

通过简单地使用for和in两个关键字，我们可以很轻松地实现在 C 语言中繁琐的遍历操作。相比较而言，C 语言中要实现相同的功能，需要这样写（假设存在整型数组list_example）：

1
2
3

int i;
for(i = 0; i < list_length; i++)
    printf("%d\n", list_example[i]);

显而易见，在遍历元素的操作上，Python 的表达更加直观优雅，简洁明了；这正是因为 Python 在实现for语句的时候，恰到好处地使用了“迭代器”的概念。

迭代器在 Python 中随处可见，并且具有统一的标准。通过使用迭代器，Python 能够逐个访问列表list_example中的每个元素。

下面我们来进一步讨论相关的机制。

2 定义及原理

2.1 迭代器的定义

迭代器（iterator）是一种可在容器（container）中遍访的接口，为使用者封装了内部逻辑。

——百度百科·迭代器) 大意

上面是我们可以查到的、对“迭代器”的一个宽泛的定义。

而具体到 Python 中，迭代器也属于内置的标准类之一，是与我们之前学习过的“序列”同一层次的概念。

对于迭代器对象本身来说，需要具有__iter__()和__next__()两种方法，二者合称为“迭代器协议”。也就是说，只要同时具有这两种方法，Python 解释器就会认为该对象是一个迭代器；反之，只具有其中一个方法或者二者都不具有，解释器则认为该对象不是一个迭代器。

上述论断可由下面的代码验证（需要用到内置函数isinstance()，来判断一个对象是否是某个类的实例；该用法启发于[廖雪峰的官方网站]）：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

>>> from collections import Iterable, Iterator, Container
>>> class bothIterAndNext:
... def __iter__(self):
... pass
... def __next__(self):
... pass
...
>>> isinstance(bothIterAndNext(), Iterable) # 两种方法都有的对象是可迭代的
True
>>> isinstance(bothIterAndNext(), Iterator) # 两种方法都有的对象是迭代器
True
>>> 
>>> class onlyNext:
... def __next__(self):
... pass
...
>>> isinstance(onlyNext(), Iterable) # 只有方法 __next__() 是不可迭代的
False
>>> isinstance(onlyNext(), Iterator) # 只有方法 __next__() 不是迭代器
False
>>> 
>>> class onlyIter:
... def __iter__(self):
... pass
...
>>> isinstance(onlyIter(), Iterable) # 只有方法 __iter__() 是可迭代的
True
>>> isinstance(onlyIter(), Iterator) # 只有方法 __iter__() 不是迭代器
False

由第 8~11 行的代码可知，对于 Python 来说，判断一个对象是否是迭代器的标准仅仅是“是否同时具有__iter__()和__next__()这两个方法”。

并且从第 17~20 行的代码也可以验证上述推断：只具有方法__next__()既不是可迭代的，也不是一个迭代器。

有意思的事情发生在代码第 26、27 两行：代码输出结果显示，只有方法__iter__()的对象居然是可迭代的！（后文解释）

2.2 迭代器的实质

迭代器对象本质上代表的是一个数据流，通过反复调用其方法__next__()或将其作为参数传入next()函数，即可按顺序逐个返回数据流中的每一项；直到流中不再有数据项，从而抛出一个StopIteration异常，终止迭代。

在 Python 中内置了两个函数：iter()和iter()，分别用于“将参数对象转换为迭代器对象”和“从迭代器中取出下一项”。

实际上所有具有方法__iter__()的对象均被视作“可迭代的”。因为方法__iter__()进行的操作其实就是返回一个该对象对应的迭代器，也就是说“可迭代的（iterable）”的真实含义其实是“可以被转换为迭代器（iterator）的”。而内置函数iter()也是调用对象本身具有的__iter__()方法来实现特定对象到迭代器的转换。

相应地，内置函数next()其实是调用了对象本身的方法__next__()，而该方法执行的操作就是从对象对应的数据流中取出下一项。

因此直接调用对象的__iter__()和__next__()方法与将对象作为参数传入内置函数iter()和next()是等效的。

要注意的一点在于，对迭代器调用其本身的__iter__()方法，得到的将会是这个迭代器自身，该迭代器相关的状态都会被保留，包括该迭代器目前的迭代状态。见下述代码：

1
2
3
4
5
6

>>> li = [1, 2, 3]
>>> li_iterator = iter(li)
>>> isinstance(li, Iterator)
False
>>> isinstance(li_iterator, Iterator)
True

显然，列表li本身并不是一个迭代器，而将其传入内置函数iter()就得到了相应于列表li的迭代器li_iterator。我们调用next()函数来迭代它：

1
2
3
4

>>> next(li_iterator)
1
>>> next(li_iterator)
2

一切都在预料之中。我们再来将其本身作为参数传入内置函数iter()：

1
2
3

>>> li_iterator = iter(li_iterator)
>>> next(li_iterator)
3

到这里跟我们希望的就有所出入了。在使用这样一个语句的时候，通常我们的目的都是得到一个新的迭代器，而非跟原先的迭代器一样的对象。

更进一步地，我们还可以发现，对迭代器调用iter()函数得到的对象不仅与原先的迭代器具有相同的状态，它们其实就是指向同一个对象：

1
2
3
4
5
6
7
8

>>> id(li_iterator)
2195581916440
>>> li_iterator = iter(li_iterator)
>>> id(li_iterator)
2195581916440
>>> li_iterator2 = iter(li_iterator)
>>> id(li_iterator2)
2195581916440

也就是说在对象本身就是一个迭代器的情况下，生成的对应迭代器的时候 Python 不会进行另外的操作，就返回这个迭代器本身作为结果。

3 实现一个迭代器类

本节构建类的代码来自[Python3 文档-类-9.8 迭代器]

有了上面的讨论，我们就可以自己实现一个简单的迭代器。只要确保这个简单迭代器具有与迭代器定义相符的行为即可。

说人话就是：要定义一个数据类型，具有__iter__()方法并且该方法返回一个带有__next__()方法的对象，而当该类已经具有__next__()方法时则返回其本身。示例代码如下：

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

class Reverse:
    """反向遍历序列对象的迭代器"""
    def __init__(self, data):
        self.data = data
        self.index = len(data)

    def __iter__(self):
        return self

    def __next__(self):
        if self.index == 0:
            raise StopIteration
        self.index = self.index - 1
        return self.data[self.index]

验证一下：

1
2
3
4
5
6
7
8
9

>>> rev = Reverse('justdopython.com')
>>> next(rev)
'm'
>>> next(rev)
'o'
>>> next(rev)
'c'
>>> next(rev)
'.'

(o゜▽゜)o☆[BINGO!]

任务完成！

4 for语句与迭代器

回到文章开头我们作为引子的for循环示例，实际上在执行for语句的时候，Python 悄悄调用了内置函数iter()，并将for语句中的容器对象作为参数传入；而函数iter()返回值则是一个迭代器对象。

因此，for语句是将容器对象转换为迭代器对象之后，调用__next__()方法，逐个访问原容器中的各个对象，直到遍历完所有元素，抛出一个StopIteration异常，并终止for循环。

5 总结

• 迭代器（iterator）首先要是可迭代的（iterable）；即迭代器一定是可迭代的，但可迭代的不一定是迭代器
• 可迭代的对象意味着可以被转换为迭代器
• 迭代器需要同时具有方法__iter__()和__next__()
• 对迭代器调用iter()函数，得到的是这个迭代器本身
• for循环实际上使用了迭代器，并且一般情况下将异常StopIteration作为循环终止条件

本文探究了 Python 中迭代器的相关知识点，深入理解了迭代器的属性和行为，学到了两个重要的方法__iter__()和__next__()。同时搞明白了 Python 实现for循环的内部机制。

参考资料

[1] Python3 文档-内置类型

[2] 廖雪峰的官方网站

[3] Python3 文档-类-9.8 迭代器

1. 引用简介与工具引入

Python 中对于变量的处理与 C 语言有着很大的不同，Python 中的变量具有一个特殊的属性：identity，即“身份标识”。这种特殊的属性也在很多地方被称为“引用”。

为了更加清晰地说明引用相关的问题，我们首先要介绍两个工具：一个Python的内置函数：id()；一个运算符：is；同时还要介绍一个sys模块内的函数：getrefcount()。

1.1 内置函数id()

id(object)

Return the “identity” of an object. This is an integer which is guaranteed to be unique and constant for this object during its lifetime. Two objects with non-overlapping lifetimes may have the same id() value.

返回值为传入对象的“标识”。该标识是一个唯一的常数，在传入对象的生命周期内与之一一对应。生命周期没有重合的两个对象可能拥有相同的id()返回值。

CPython implementation detail: This is the address of the object in memory.

CPython 实现细节：“标识”实际上就是对象在内存中的地址。

——引自《Python 3.7.4 文档-内置函数-id()》

换句话说，不论是否是 CPython 实现，一个对象的id就可以视作是其虚拟的内存地址。

1.2 运算符is

即is的作用是比较对象的标识。

——引自《Python 3.7.4 文档-内置类型》

1.3 sys模块函数getrefcount()函数

sys.getrefcount(object)

Return the reference count of the object. The count returned is generally one higher than you might expect, because it includes the (temporary) reference as an argument to getrefcount().

返回值是传入对象的引用计数。由于作为参数传入getrefcount()的时候产生了一次临时引用，因此返回的计数值一般要比预期多1。

——引自《Python 3.7.4 文档-sys模块——系统相关参数及函数》

此处的“引用计数”，在 Python 文档中被定义为“对象被引用的次数”。一旦引用计数归零，则对象所在的内存被释放。这是 Python 内部进行自动内存管理的一个机制。

2. 问题示例

C 语言中，变量代表的就是一段固定的内存，而赋给变量的值则是存在这段地址中的数据；但对 Python 来说，变量就不再是一段固定的地址，而只是 Python 中各个对象所附着的标签。理解这一点对于理解 Python 的很多特性十分重要。

2.1 对同一变量赋值

举例来说，对于如下的 C 代码：

1
2
3
4

int a = 10000;
printf("original address: %p\n", &a); // original address: 0060FEFC
a = 12345;
printf("second address: %p\n", &a); // second address: 0060FEFC

对于有 C 语言编程经验的人来说，上述结果是显而易见的：变量a的地址并不会因为赋给它的值有变化而发生变化。对于 C 编译器来说，变量a只是协助它区别各个内存地址的标识，是直接与特定的内存地址绑定的，如图所示：

但 Python 就不一样的。考虑如下代码：

1
2
3
4
5
6

>>> a = 10000
>>> id(a)
1823863879824
>>> a = 12345
>>> id(a)
1823863880176

这就有点儿意思了，更加神奇的是，即使赋给变量同一个常数，其得到的id也可能不同：

1
2
3
4
5
6

>>> a = 10000
>>> id(a)
1823863880304
>>> a = 10000
>>> id(a)
1823863879408

假如a对应的数据类型是一个列表，那么：

1
2
3
4
5
6

>>> a = [1,2]
>>> id(a)
2161457994952
>>> a = [1,2]
>>> id(a)
2161458037448

得到的id值也是不同的。

正如前文所述，在 Python 中，变量就是一块砖，哪里需要哪里搬。每次将一个新的对象赋值给一个变量，都在内存中重新创建了一个对象，这个对象就具有新的引用值。作为一个“标签”，变量也是哪里需要哪里贴，毫无节操可言。

但要注意的是，这里还有一个问题：之所以说“即使赋给变量同一个常数，其得到的id也可能不同”，实际上是因为并不是对所有的常数都存在这种情况。以常数1为例，就有如下结果：

1 2 3 4 5 6 7 8 9

> >>> a = 1 > >>> id(a) > 140734357607232 > >>> a = 1 > >>> id(a) > 140734357607232 > >>> id(1) > 140734357607232 >

>

可以看到，常数1对应的id一直都是相同的，没有发生变化，因此变量a的id也就没有变化。

这是因为Python在内存中维护了一个特定数量的常量池，对于一定范围内的数值均不再创建新的对象，而直接在这个常量池中进行分配。实际上在我的机器上使用如下代码可以得到这个常量池的范围是 [0, 256] ，而 256 刚好是一个字节的二进制码可以表示的值的个数。

1 2 3 4 5 6

> for b in range(300): > if b is not range(300)[b]: > print("常量池最大值为：", (b - 1)) > break > # 常量池最大值为： 256 >

相应地，对于数值进行加减乘除并将结果赋给原来的变量，都会改变变量对应的引用值：

1
2
3
4
5
6
7
8

>>> a = 10000
>>> id(a)
2161457772304
>>> a = a + 1
>>> a
10001
>>> id(a)
2161457772880

比较代码块第 3、8行的输出结果，可以看到对数值型变量执行加法并赋值会改变对应变量的引用值。这样的表现应该比较好理解。因为按照 Python 运算符的优先级，a = a + 1实际上就是a = (a + 1)，对变量a对应的数值加1之后得到的是一个新的数值，再将这个新的数值赋给a ，于是a的引用也就随之改变。列表也一样：

1
2
3
4
5
6
7
8

>>> a = [1,2]
>>> id(a)
2161458326920
>>> a = a + [4]
>>> a
[1, 2, 4]
>>> id(a)
2161458342792

2.2 不变的情况

与数值不同，Python 中对列表对象的操作还表现出另一种特性。考虑下面的代码：

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

>>> c = [1, 2, 3]
>>> id(c)
2161458355400
>>> c[2] = 5
>>> c
[1, 2, 5]
>>> id(c)
2161458355400
>>> c.append(3)
>>> c
[1, 2, 5, 3]
>>> id(c)
2161458355400

观察代码块第 3、8、13三行，输出相同。也就是说，对于列表而言，可以通过直接操作变量本身，从而在不改变其引用的情况下改变所引用的值。

更进一步地，如果是两个变量同时引用同一个列表，则对其中一个变量本身直接进行操作，也会影响到另一个变量的值：

1
2
3
4
5
6

>>> c = [1, 2, 3]
>>> cc = c
>>> id(c)
1823864610120
>>> id(cc)
1823864610120

显然此时的变量c和cc的id是一致的。现在改变c所引用的列表值：

1
2
3

>>> c[2] = 5
>>> cc
[1, 2, 5]

可以看到cc所引用的列表值也随之变化了。再看看相应地id：

1
2
3
4

>>> id(c)
1823864610120
>>> id(cc)
1823864610120

两个变量的id都没有发生变化。再调用append()方法：

1
2
3
4
5
6
7
8
9

>>> c.append(3)
>>> c
[1, 2, 5, 3]
>>> cc
[1, 2, 5, 3]
>>> id(c)
1823864610120
>>> id(cc)
1823864610120

删除元素：

1
2
3
4
5
6
7
8
9

>>> del c[3]
>>> c
[1, 2, 5]
>>> cc
[1, 2, 5]
>>> id(c)
1823864610120
>>> id(cc)
1823864610120

在上述所有对列表的操作中，均没有改变相应元素的引用。

也就是说，对于变量本身进行的操作并不会创建新的对象，而是会直接改变原有对象的值。

2.3 一个特殊的地方

本小节示例灵感来自[关于Python中的引用]

数值数据和列表还存在一个特殊的差异。考虑如下代码：

1
2
3
4
5
6

>>> num = 10000
>>> id(num)
2161457772336
>>> num += 1
>>> id(num)
2161457774512

有了前面的铺垫，这样的结果很显得很自然。显然在对变量num进行增1操作的时候，还是计算出新值然后进行赋值操作，因此引用发生了变化。

但列表却不然。见如下代码：

1
2
3
4
5
6
7
8

>>> li = [1, 2, 3]
>>> id(li)
2161458469960
>>> li += [4]
>>> id(li)
2161458469960
>>> li
[1, 2, 3, 4]

注意第 4 行。明明进行的是“相加再赋值”操作，为什么有了跟前面不一样的结果呢？检查变量li的值，发现变量的值也确实发生了改变，但引用却没有变。

实际上这是因为加法运算符在 Python 中存在重载的情况，对列表对象和数值对象来说，加法运算的底层实现是完全不同的，在简单的加法中，列表的运算还是创建了一个新的列表对象；但在简写的加法运算+=实现中，则并没有创建新的列表对象。这一点要十分注意。

3. 原理解析

前面（第3天：Python 变量与数据类型）我们提到过，Python 中的六个标准数据类型实际上分为两大类：可变数据和不可变数据。其中，列表、字典和集合均为“可变对象”；而数字、字符串和元组均为“不可变对象”。实际上上面演示的数值数据（即数字）和列表之间的差异正是这两种不同的数据类型导致的。

由于数字是不可变对象，我们不能够对数值本身进行任何可以改变数据值的操作。因此在 Python 中，每出现一个数值都意味着需要另外分配一个新的内存空间（常量池中的数值例外）。

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

>>> a = 10000
>>> a == 10000
True
>>> a is 10000
False
>>> id(a)
2161457773424
>>> id(10000)
2161457773136
>>> 
from sys import getrefcount
>>> getrefcount(a)
2
>>> getrefcount(10000)
3

前 9 行的代码容易理解：即使是同样的数值，也可能具有不同的引用值。关键在于这个值是否来自于同一个对象。

而第 10 行的代码则说明除了getrefcount()函数的引用外，变量a所引用的对象就只有1个引用，也就是变量a。一旦变量a被释放，则相应的对象引用计数归零，也会被释放；并且只有此时，这个对象对应的内存空间才是真正的“被释放”。

而作为可变对象，列表的值是可以在不新建对象的情况下进行改变的，因此对列表对象本身直接进行操作，是可以达到“改变变量值而不改变引用”的目的的。

4. 总结

对于列表、字典和集合这些“可变对象”，通过对变量所引用对象本身进行操作，可以只改变变量的值而不改变变量的引用；但对于数字、字符串和元组这些“不可变对象”，由于对象本身是不能够进行变值操作的，因此要想改变相应变量的值，就必须要新建对象，再把新建对象赋值给变量。

通过这样的探究，也能更加生动地理解“万物皆对象”的深刻含义。

5. 参考资料

Python 3.7.4 文档-内置函数-id()

Python 3.7.4 文档-内置类型

Python 3.7.4 文档-sys模块——系统相关参数及函数

Python 3.7.4 文档-术语表

关于Python中的引用

2018-12-09，博客园

教程

• 【强烈推荐】GitHub项目：learnGitBranching-pcottle

  网站：learnGitBranching

• 廖雪峰的官方网站-Git教程

整理 Git 命令如下，按第一个教程顺序整理

常用命令

初始化命令

• git init

  在当前文件夹初始化一个本地仓库

提交命令

• git add

  将改动（文件变化）添加到到暂存区（缓冲区），以待正式提交（commit）

• git commit（不建议单独使用）

  将暂存区的改动提交到Git，对其中文件进行一次快照，保存为一个节点

• git commit -m <对提交的描述信息>

  在提交变化的同时添加描述信息

• git commit --amend

  好像是将暂存区的修改直接提交到当前所在节点，而不是新建一个节点（提交）
  有待检验

分支命令

• git branch <新建分支名> [目标节点]

  在目标节点新建一个分支
  若不指定目标节点，则默认在当前节点（HEAD）新建分支

• git branch -f <指定分支名> <目标节点位置>

  此命令可以将指定分支强制指向目标节点
  如git branch -f master HEAD~4命令的作用是使master强制指向HEAD所在节点的前4级节点
  其中，<目标节点位置>可以是具体的节点哈希值，也可以是相对引用的节点

• git branch -u <指定远程分支名> [指定本地分支名]

  将指定远程分支与指定本地分支关联
  如果省略[本地分支名]，则默认将当前分支与远程分支关联。[疑问]¹

切换命令

• git checkout <分支名/标签名/节点哈希值等>

  切换到对应的分支、标签或节点。（实际上是改变HEAD的指向，“HEAD的指向”代表当前所在位置）

• git checkout -b <新建分支名>

  在当前节点新建一个分支，并立即切换到这一新建分支

• git checkout -b <新建分支名> <目标远程分支名>[疑问]³

  在当前节点新建并切换到一个新分支，同时将其与指定的远程分支关联，用来跟踪这一远程分支

相对引用

• git checkout <分支名/HEAD>^

  将HEAD指向指定分支名指向节点的上一节点，即父节点。
  或将HEAD指向HEAD的父节点
  其中，^符号可以一次使用多个。每使用一个代表将HEAD往上一级节点移动一次
  比如git checkout master^^命令表示将HEAD指针指向master指向节点的上两级节点（即上一级的上一级节点）

• git checkout <分支名/HEAD>~[数字]

  作用类比于上一条命令。但通过[数字]可以直接指定将HEAD往前指向的节点级数
  若不加[数字]则默认上移一级，即git checkout master~与git checkout master^作用相同

• git checkout <节点>^[数字]

  数字指定回溯到哪一条分支
  若没有数字，则默认回溯到直接分支（即合并操作执行时HEAD所在的分支）

• git checkout <节点>~^2~2

  支持链式操作，将多个切换命令合并为一条命令

合并命令

• git merge <分支名>（合并方法1）

  将<分支名>指定的分支合并到当前所在分支
  即以当前分支为主，最终合并的结果（最终节点）也是由当前分支来指向【疑问】¹⁰
  merge的优势在于可以保持提交历史的顺序、结构

• git rebase <目标分支> [移动分支]（合并方法2）

  直译为“以目标分支（分支1）为基础，结合移动分支（分支2）进行梳理整合”
  将[移动分支]的提交记录整理，复制一个副本合并到[目标分支]，得到一个线性提交记录。原提交记录依然存在。
  同时将[移动分支]指向rebase得到的分支顶端节点（有待验证）
  直译过来就是“将[移动分支]整合到[目标分支]”
  若不指定[移动分支]，则默认移动当前分支
  优势在于可以保留干净、线性的提交树

标签命令

• git tag <标签名> [指定节点]

  将标签名标注于指定节点
  若不指定节点，则加标签于当前节点（HEAD）

查看命令

• git log

  列出提交记录（具体列出全部还是当前分支有待确定）

撤销变更命令[疑问]⁴

• git reset <目标节点>（仅适用于本地分支）

  将当前分支指向目标节点
  即忽略目标节点之后的所有提交
  但被忽略的节点所作的变更依旧存在，只是处于未加入暂存区状态

• git revert <节点>（适用于远程分支）

  撤销指定节点的修改，即回到指定节点父节点的状态
  实现方式不同于git reset <目标节点>命令
  git reset [目标节点]仅仅通过修改指向实现，
  git revert <节点>是对当前节点与其父节点的差异重做而产生一个新的提交节点，得到指定节点的子节点，但是该子节点的状态与指定节点的父节点状态相同
  此命令没有实际使用过，有待检验

远程命令

克隆到本地

• git clone <ssh/https地址>

  从远程仓端克隆远程仓库到本地

从远程仓库拉取内容

• git fetch

  下载远程仓库所有分支及提交记录到本地各个远程分支

• git fetch <remote> <place>

  类比push命令的参数
  可以理解为仅仅是将远程仓库内容下载下来，但是并没有对本地文件作出改动。但是会更新本地仓库的远程分支指向。
  区别于git pull命令
  不需要当前处于远程分支

• git fetch <远程仓库名称> <指定的远程分支名>【疑问】⁹

  同时会更新本地仓库的对应的远程分支（单独的fetch会更新吗？）

• git fetch <远程仓库名称> <源节点>:<本地目标分支>（实际很少用）

  <源节点>是指远程仓库中的索引位置，<目标分支>才是本地分支了。类比push命令，刚好相反。
  如果本地仓库不存在指定的目标分支，则Git自动在本地仓库（当前节点）创建一个同名分支，并执行操作
  不更新本地的远程分支（？）

• git fetch <远程仓库名称> :<本地目标分支>

  命令自动在本地（当前节点）创建一个本地分支

• git pull <>

  相当于git fetch与git merge相继作用的效果
  即不光下载远程内容并把本地仓库远程分支指向最新节点，同时将当前所在分支指向这一节点[疑问]⁵【疑问】⁸

git pull origin foo相当于git pull origin foo; git merge o/foo
git pull origin bar~1:bugFix相当于git fetch origin bar~1:bugFix; git merge bugFix
只关心提交最终合并到哪里

• git pull --rebase

  相当于git fetch + git rebase <远程分支>

向远程仓库推送内容

• git push <remote> <place>

  以上为push命令的标准表述

• git push <远程仓库名称> <要推送的本地分支名>

  可以直译为“将本地分支A推送到远程仓库1”
  向指定远程仓库推送指定的本地分支的提交记录，并更新本地仓库中与指定本地分支相关联的远程分支[疑问已解决]⁷
  [疑问]²

• git push <远程仓库名称> <源节点>:<远程目标分支>

  如果在远程仓库不存在指定的目标分支，则Git会在远程仓库自行创建一个新的分支

• git push <远程仓库名称> :<远程目标分支>

  删除指定的远程分支

进阶命令

整理提交记录

• git cherry-pick <指定节点> [指定节点] ...（cherry-pick意为“精挑细选”）

  可以在一条命令中指定多个节点为执行对象（好像需要是节点的哈希值）可以是提交树上任意位置的节点[疑问]⁶，但不能是当前节点上游的节点
  命令的作用顾名思义，是选中指定节点，并按顺序将节点副本顺次附加到当前所在节点（HEAD）之后
  或许这个命令可以直译为“精选”命令

交互式rebase

• git rebase -i <分支名/节点/HEAD>~[数字]

  使用参数--interactive（简写为-i）
  尝试了一下，好像只能用HEAD作为索引？（经验证，不是）
  数字n代表包括HEAD所在节点向上的n个节点
  打开一个rebase UI界面

  • 调整提交记录的顺序（通过鼠标拖放）
  • 删除不想要的提交
  • 合并提交

描述节点

• git describe <索引>

  作用是输出关于离[索引]最近的标签的信息
  “最近”的意思仅限于同一条分支（有待验证）
  <索引>指所有可以指向具体节点的值，官方表述为“任何能被 Git 识别成提交记录的引用”
  若不指定具体节点，则作用于当前节点（HEAD）

注意事项

• 节点哈希值基于 SHA-1，共 40 位

• 分支名/HEAD等本质上类似一个指针，指向某个节点

  具体讲，分支名指向当前分支的最新节点；而HEAD指向当前状态实际所在的节点
  同时，git checkout [分支名/标签名/节点哈希值]命令的本质是移动HEAD指针的指向

• 本地仓库里的远程分支，或者说远程仓库分支对应的本地分支名（如果存在）不能手动移动。只有在与远程仓库同步时才能够自动修改。

疑问

• 既然可以用rebase UI直接对节点重排，那各个提交记录到底是记录的“变化”还是文件本身的快照啊？

  如果只是变化的话，重拍之后怎么可能还可以正确应用呢？

• 尝试了一下，git rebase -i [索引]好像只能用HEAD作为索引？

  不必。索引均可。

• 对提交进行重排之后，所有后续节点都会产生相应改变？还是说因为记录的都是“变化”，所以改变内容不影响后续？

• 实际工作环境是否存在“本地仓库的远程分支”这一说法？

  在“远程跟踪”一节提到了，确实存在。
  原话如下：

  1 2 3

  当你克隆时, Git 会为远程仓库中的每个分支在本地仓库中创建一个远程分支（比如 o/master）。然后再创建一个跟踪远程仓库中活动分支的本地分支，默认情况下这个本地分支会被命名为 master。 克隆完成后，你会得到一个本地分支（如果没有这个本地分支的话，你的目录就是“空白”的），但是可以查看远程仓库中所有的分支（如果你好奇心很强的话）。这样做对于本地仓库和远程仓库来说，都是最佳选择。

• 本地仓库有，而远程仓库没有的分支能否推送到远程端并自动创建一个新分支？

¹. 如果当前没有指向具体分支，而是分离HEAD状态呢？ ↩

². 本地仓库有，而远程仓库没有的分支能否推送到远程端并自动创建一个新分支？ ↩

³. 是否能够不指定“远程分支名”，从而默认关联某一远程分支 ↩

⁴. 没懂，看完再看一下。 ↩

⁵. 但是不更新在本地的远程分支？比如o/master，不会改变？ ↩

⁶. git cherry-pick命令的作用对象是否可以是任意节点（除当前分支的上游节点外）？ ↩

⁷. 若关联的本地分支与远程分支名称不一致，则在push命令中是以远程分支名为准吗？试一试。（顺便试一试脚注的冒号用中文冒号行不行） ↩

显然，中文冒号不行
经试验，push命令中指定的分支名以本地分支为准
故可以直译为“将本地分支A推送到远程仓库1”

⁸. 是否仅限于当前分支？试一试 ↩

⁹. 应该也是对应于push命令，fetch则以远程分支名为准，将指定的远程分支的记录全部拉取到本地与之相关联的分支上。试一试 ↩

单独的fetch会更新本地仓库的远程分支吗？试一试

¹⁰. 若当前指向一个具体节点而不是某一个分支名呢？即处在分离HEAD状态，且可以更进一步，HEAD指向的节点没有其他任何分支同时指向，会发生什么？ ↩

单纯移动HEAD？

是 2019-04-03 看书时写下的

关于展开为二维数组后转置规律的探究（p208-p221）

• 对输入数据展开后，其维度情况是$(行数=数据个数\times 单个数据卷积次数, 列数=输入通道数\times 卷积核的宽\times 卷积核的高)$

  若把输入数据维度情况记为$(N, C, H, W)$，卷积核维度情况记为$(FN, C, FH, FW)$，输出数据维度情况记为$(ON, OC, OH, OW)$，则有以下关系：

  $$ON=N$$ $$OC=FN$$ $$OH=\frac{H+2P-FH}{S}+1$$ $$OW=\frac{W+2P-FW}{S}+1$$

  $N$个输入数据展开的二维数组形状为$(N\times OH\times OW, C\times FH\times FW)$

  其中，行数中$(OW\times OH)$为单个输出数据的维度情况，亦即对单个输入数据需要卷积的次数；而$N$则是输入数据的个数，也是输出数据的个数。完整的行数表示只有一个卷积核时，$N$个输入数据对应的输出元素个数。
  列数中，$C$为输入数据的通道数；而$(FH\times FW)$则代表卷积核的维度情况，其值是卷积核的元素个数。完整的列数表示对具有$C$个输入通道的输入图像，一次卷积运算需要运算的区域对应的输入元素个数。

  $FN$个卷积核展开的二维数组形状为$(C\times FH\times FW, FN)$

  其中，行数$(C\times FH\times FW)$的解释如上的列数。
  列数$FN$则为卷积核的个数，也就是输出数据的通道数。

  按照数组的排列规则，其排列顺序是优先排最低维度。比如对二维数组(5, 3)，其排完一行的元素个数为 3 ，排完一行再排第二行，也就是说，离首元素最近的元素首先是第一行的其他元素，而不是下一行的首元素。在reshape的时候必须要考虑到元素的顺序问题。
  数组维度规律是越靠前维度越高，新增的更高维因此也必须加在数组维度的最左边。比如从$Width$维度开始，增加了一个$Height$维度，则数组变为$(Height, Width)$，再增加一个通道维度$Channel$，则数组维度变为$(Channel, Height, Width)$，以此类推。

• 输出数据在进行reshape操作前，维度情况是$(行数=数据个数\times 单个数据卷积次数, 列数=卷积核个数=输出通道数)$

  输出数据的维度情况用字母表达则为$(N\times OH\times OW, FN)$
  对应为最终需要的输出，可以表示为$(ON\times OH\times OW, OC)$，经过reshape调整之后维度情况为$(ON, OH, OW, OC)$而需要的输出是$(ON, OC, OH, OW)$，以便作为下一次的输入。
  所以对reshape的结果，还需要通过transpose更改轴的顺序，把原先的(0,1,2,3)转换为(0,3,1,2)

突然想到一个类比：数组的高维、低维就像数制中的高位、低位一样，数先在低位排，排满一个低位之后，则向高位进1，然后继续排列下一个高位的一系列低位。并且数制的进位也是让高位在左，低位在右。十分有趣。数制也可以理解为维度的一种特殊形式，其各维具有相同的元素个数。数组的高维和低维之间也存在一种类似的“进位”关系。

关于“为什么二维数组的第0轴是列方向”

从上面的分析可以看出来，多维数组对轴的编号是从左往右的，也就是说，对二维数组(y, x)来说，x方向是第0轴，y方向是第1轴；对三维数组(z, y, x)来说，第0轴则是z轴，第1轴是y轴，第2轴是x轴。

图书链接

《深度学习入门：基于Python的理论与实现》（图灵社区）

刚刚上传了一篇博客到 CSDN，因为使用的本地编辑器是Typora，本身支持HTML语法，用习惯了之后也喜欢在markdown之外再定制一些显示格式。

在显示图片失败的文章中我是用的img标签来定制图片的缩放大小，在Typora中显示完全正常，因此也就没有多想直接上传了。但上传之后查看效果才发现三张图片都无法正常显示，于是赶紧排查原因。

看到有的博主说是因为 CSDN 要手动上传图片，给我惊了一把。不过再看下时间大概是两年前了，总觉得 CSDN 不能这么坑吧，于是继续排查。发现个人博客使用的 hexo 也无法正确渲染img标签，顿时仿佛明白了什么。于是哼哧哼哧把几张图片的格式都改回了 markdown 的原生格式，终于显示正常了。

所以结果证明 CSDN 自带的 markdown 编辑器不支持 HTML 语法，以鉴后来。

是记。

参考资料

CSDN图片显示不出解决方法！（新手之坑）

CSDN 的 Markdown 编辑器好像不像Typora那样能够正确渲染 .md 文档中夹杂的 HTML 标签，所以导致之前以 HTML 语法插入的图片在 CSDN 上无法正确显示

具体问题

在根据文档配置好LeanCloud并完成部署之后，刷新博客网页，在主页看到每篇文章的阅读次数都显示为0，而打开每篇文章的相应页面更是发现错误信息：Counter not initialized! More info at console err msg.。具体情况如图所示：

此外在之前还遇到“阅读次数”不显示或者显示为NaN/NaN的情况，检查发现是在 leancloud 中配置的时候习惯性将自己的自定义域名协议写成了HTTPS，但实际上是用的HTTP协议。因此修改之后就出现了上面的情况。

如图所示：

解决方案

在搜索过程中发现有人也遇到过这个问题，于是按照《hexo使用笔记》中的描述，安装了插件hexo-leancloud-counter-security（命令行执行npm install hexo-leancloud-counter-security）

，并将主题配置文件_config.yml中的对应项security置为false。

具体位置如下（第 8 行）：

1
2
3
4
5
6
7
8
9

leancloud_visitors:
  enable: true
  app_id: # <app_id>
  app_key: # <app_key>
  # Dependencies: https://github.com/theme-next/hexo-leancloud-counter-security
  # If you don't care about security in leancloud counter and just want to use it directly
  # (without hexo-leancloud-counter-security plugin), set `security` to `false`.
  security: false
  betterPerformance: false

这样配置之后，就可以看到页面中的数据能够正常显示了。如下图：

参考文档

hexo使用笔记

注：原文档中建议的是两种方法：1）使用hexo-leancloud-counter-security插件；2）设置leancloud_visitors.security = false均可。

但考虑到主题配置文件中关于安全性的提醒，我是按步骤分别完成了这两步。并且只安装hexo-leancloud-counter-security插件依然不能解决报错问题，可能真正生效的是“将security置为false”这一步。

但出于安全考虑，建议大家也同时安装hexo-leancloud-counter-security插件。

浮点数陷阱

在第二章最初，给出了“浮点运算是不可结合的”这样一个结论，乍一看有点令人费解，但仔细看了看例子，发现其实结合浮点数在内存中的存储方式反而很容易理解，不过就是这种表达很容易让人误会，颇不可取。

实际上由于浮点数在内存中存储时，计算机存储的是它的尾数，因此在一个数的基础上，给它加上或者减去太小的浮点值，都会导致最终产生截断，表现出来就是“什么也没有发生”的效果。

书中提到的：

1

(3.14 + 1e20)-1e20

正是这样一个例子。

其中的1e20远大于3.14，于是实际发生的事情就是(3.14+1e20)所得的结果为1e20，再减去1e20，于是就得到了看起来很不合理的0。因此在使用浮点数的时候一定要注意精度的问题。

如果一定要在跨度很大的范围内进行浮点数运算，最好将同一优先级下，数值范围相近的操作数先运算。

“虚拟内存”的抽象

大多数计算机的最小可寻址内存单位就是“字节”。

机器级程序将内存视为一个非常大的字节数组，称为虚拟内存。

这里又复习了一下第一章提到的“抽象”概念，所谓“虚拟内存”，就是对主存和I/O设备的抽象。并且这段话还具体讲了一下“虚拟内存” 抽象的方式，使得这个抽象概念更加明晰。

每台计算机都有一个字长（word size），指明指针数据的标称大小。

这里的“字长”可以比较“字节”的概念。“字长”并不等于“字节”，一个“字”可能包含多个字节，并且是取决于机器的位数的。

所谓“指针数据的标称大小”，我的理解就是在这台机器上存储某个虚拟内存地址的指针变量的位数。更进一步说，应该就是PC寄存器（程序计数器）的大小，因此PC寄存器的大小（也就是“字长”）限制了计算机的最大寻址范围，超出“字长”所能表示的最大值的虚拟内存地址对计算机来说是没有意义的。

并且还要注意的是，编译结果的二进制程序是32位还是64位并不取决于机器，而是取决于具体使用的编译器和编译方式。

大端法和小端法

之前忘记在哪儿看到过关于大端法和小端法的描述，但因为毕竟不是CS专业，了解了一下也没有记住，今天看书的时候倒是认真推敲了一下，发现了一些有趣的东西，也对这两种存储顺序有了更深的理解和记忆。

最低有效位在最前面的（存储）方式，称为小端法（little endian）

最高有效位在最前面的（存储）方式，称为大端法（big endian）

其实按人类的正常思维和书写习惯，很显然大端法是一种更加自然的方式，但却很少被采用，连两种主流的移动端操作系统都没落着；而小端法则是一种更加符合逻辑的存储顺序，可能也更加适合在计算机当中表达。

说是这么说，但实际上转念一想，为什么大端法存储顺序就更贴近人的思维了呢？其实就连在书面上表达的时候，将内存单元按地址增大的顺序从左往右排列也不过是人为规定的而已；对计算机来说，地址的高位、低位并不存在左右之别，反而将低字节放在低地址更便于机器操作。

具体问题

前两天折腾博客时，在静态页面生成完成之后要部署到GitHub上时遇到了ERROR Deployer not found: git的问题。

但是奇怪的是我都是按照文档一步步设置的，其中博客根目录中的配置文件_config.yml中写入了如下内容：

1
2
3
4

deploy:
  type: git
  repo: https://github.com/lierchao1997/lierchao1997.github.io.git #https://bitbucket.org/JohnSmith/johnsmith.bitbucket.io
  branch: master #published

同时也执行相应命令安装了相应的插件：

1

$ npm install hexo-deployer-git --save

但在执行hexo d命令的过程中却遇到了上述问题。

解决方案

最后发现是因为在安装插件时“当前工作目录”不在博客根目录下，所以hexo没有找到这个插件。注意此处的“博客根目录”。不是创建博客文件夹时所在的文件夹，而是执行命令hexo init [博客文件夹]时指定的[博客文件夹]。

要执行cd [博客文件夹]，将命令行当前目录跳转到为博客创建的新文件夹中去，并且保持这个路径不要再进入下一级目录。此时再来执行插件安装命令，即可正确安装相应插件。

到这里，再执行hexo d命令即可正确部署静态页面。

Quick Start

Create a new post

1

$ hexo new "My New Post"

More info: Writing

Run server

1

$ hexo server

More info: Server

Generate static files

1

$ hexo generate

More info: Generating

Deploy to remote sites

1

$ hexo deploy

More info: Deployment

《深入理解计算机系统（原书第 3 版）》

英文版简称CS: APP

2017 年 12 月第 1 版第 6 次印刷

ISBN 978-7-111-54493-7

信息 = 位 + 上下文

一切皆比特

CSAPP 开篇就提到一个概念：信息 = 位 + 上下文

在计算机内部，“一切皆比特”，所有信息都以二进制序列的形式存储、传输、处理和表示，但同样是二进制序列，在不同的情境下就有不同的解释方法。比如同样是四字节二进制序列，可以解释为一个整数，也可以解释为四个ASCII码表示的字符；既可以是某个具体的32位机器指令，又可以是待处理的浮点数……

所谓“读到这些数据对象时的上下文”，实际上就是指的这些二进制序列被呈现时的具体情境，是被处理的数值，还是待执行的指令，抑或是要传输的字符，“信息”的意义并不取决于二进制序列本身长什么样，而更多地依赖于它在什么情况下被解释。

文本文件和二进制文件

在 CSAPP 第 2 页有一个论断是“只由 ASCII 字符构成的文件称为文本文件，所有其他文件都称为二进制文件”。这样的说法其实很有意思，理论上来讲，计算机内部所有文件都应该是“二进制文件”，却单单拉出来一个“文本文件”离群索居。

之前在编程的时候有时会感到奇怪，读取/写入文件时有一个模式是“以二进制格式读取/写入”，为什么就偏是“二进制格式”呢？看到 CSAPP 相关论述的时候突然福至心灵，实际上计算机内部存储的信息大体上被分为两种类型：一种是给人看的，即文本信息；一种是给机器看的，即二进制信息。

信息要表示给人看，就肯定要以一个个字符的形式呈现，不限于 ASCII 码的字符，GBK、Unicode这些都行，但一定要是字符编码，因为对人而言一串串的二进制序列并没有任何直观的意义，只有这些序列能够被依次解读为一个个连续的字符时才能被人获取到其中的信息。而机器之间的通信则不然，二进制就是机器的语言，就是机器的文字，既不必呈现给人类，也不必再进一步地转换浪费更多时间和空间，高效并且准确。

与其说计算机内部的文件分为“文本文件”和“二进制文件”，倒不如说是计算机内部文件分为“给人看的”和“给机器看的”来得贴切。

关于“上下文”的思考

不出意外的话，这部分中提到的上下文对应的英文应该是 context，但这里存在一个疑问：“上下文”这个术语在当前的计算机领域内有种被滥用的嫌疑。只要出现了 context 这个单词，不管三七二十一大家都把它译为“上下文”。但实际上作为使用汉语的中国人应该意识到，在很多出现单词 context 的地方，将其译为”情境“、”背景“甚至是”语境“，都比译作”上下文“更好也更准确。

举例来说，下面这句话：

In the context of AI, the brain is essentially an advanced piece of technology that we must study, reverse engineer, and learn to emulate.

译作：

而在人工智能的学科背景下，大脑本质上就是一种深奥繁复的技术，我们有必要对它进行研究，通过逆向工程来解析它的工作原理和机制，从而模仿它的功能。

显然要比译为：

而在人工智能的上下文中，大脑本质上就是一种深奥繁复的技术，我们有必要对它进行研究，通过逆向工程来解析它的工作原理和机制，从而模仿它的功能。

更加贴切和通顺。

当然，也有可能此处的“上下文”是后文所称“进程运行所需的所有状态信息”的特指，这当然也能解释得通；但私以为在计算机领域中将 context 译作”上下文“的滥用情况也需要得到重视并及时纠正。

编译系统

这个部分只是想尝试一下 mermaid 画图功能强行加的

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

graph LR
A[预处理器]
B[编译器]
C[汇编器]
D[链接器]
a{hello.c}
d{hello}
a-->A
A--"hello.i"-->B
B--"hello.s"-->C
C--"hello.o"-->D
D-->d

系统的硬件组成

1. 总线

注意区分”字（word）“和”字节（byte）“。

一个“字”可能包含多个字节，“字长”即一个字中的字节数。字的具体大小应该是与处理器位数相关。

2. I/O 设备

硬盘也是 I/O 设备的一种，但主存（即内存）不是。（存疑）

网络也可以被抽象为 I/O 设备

I/O 设备又可以被抽象为“文件”

区别“控制器”和“适配器”

I/O 设备通过控制器或适配器与 I/O 总线相连

• 控制器：是 I/O 设备本身或系统主板上的芯片组
• 适配器：一块插在主板插槽上的卡

3. 主存

临时存储设备

由动态随机存取存储器芯片（DRAM，Dynamic Random Access Memory）组成

4. 处理器

• 指令集架构：描述每条机器代码指令的效果
• 微体系结构：处理器实际的实现

按我的理解，微体系结构指的应该就是处理器具体的半导体结果，也不知对不对。此处存疑。

存储器层次结构

高速缓存存储器（cache memory）

利用局部性原理，通过局部加载下一级低速存储器的内容来优化上一级高速存储器的操作速度，最终达到优化计算机整体运行速度的效果。

要点

• 学会利用高速缓存存储器，可以大大提升程序性能
• 存储器层次结构逐层抽象，对低速设备而言，与之直接通信的高速设备相当于其对应的高速缓存

操作系统

基本功能

1. 防止硬件被失控的应用程序滥用；
2. 向应用程序提供简单一致的机制来控制复杂而又通常大不相同的低级硬件设备。

三个重要抽象

1. 文件
2. 虚拟内存
3. 进程

此外，还有一个称为“虚拟机”的抽象，针对的是整个系统

进程是计算机科学中最重要、最成功的概念之一；

抽象也是。

Amdahl 定律

要想显著加速整个系统，必须提升全系统中相当大的部分的速度。

并发和并行

在本书中虽然给出了并发（concurrency）和并行（parallelism）的概念，但二者的区别还是不明显，甚至看完之后比不看更加混乱。

区别

按之前的理解，从英文单词来看，并发（concurrency）前缀“con-”用以强调，整个单词是“同时发生”的意思，但并不强调同一时刻，而更在于存续状态。比如同时看《深入理解计算机系统》和《计算机网络：自顶向下方法》两本书，可以今天看前者20页，明天看后者20页；也可以今天上午看前者20页，今天下午看后者20页，无论如何，在我看完两本书之前，我对两本书的状态都是“阅读中”，“看这两本书”的状态是一直存在的，虽然我并没有一直看同一本书，但我一直“在看”这两本书。几种状态同时存在，允许交替，但同一时刻只有一种状态活跃，这就是所谓“并发”。

而并行（parallelism）的前缀“para-”则是“在旁边”之意，也就是说行为是同时发生的，强调的是同一时刻。以看书为例，就不能是我自己一个人同时看两本书了，而应当有另一个人在我旁边跟我一起看书，我看《深入理解计算机系统》，而他看《计算机网络：自顶向下方法》。在这期间任意时刻进行观察，两个人都是在看自己那本书，互不干扰，并行不悖。实际上，“并行不悖”正是“并行”概念的题眼，也是其精髓所在。几种状态同时存在，同一时刻保持活跃，这就是所谓“并行”。

当然，看了 CSAPP 之后感觉自己之前的理解似乎有一些偏颇之处，因此暂时存疑。

超线程

前两天在读书群中看见有人讨论超线程的问题，但当时还没有开始看书，因此不是很清楚相关概念，也就没有参与讨论；看完之后对于超线程也有一定的想法，因此写下来以供参考。

超线程和多线程是不一样的。多核处理的情况下无需赘言，多个处理器相互之间是并行的。在单核的情况下，多线程实际上就是一种并发，通过 CPU 的时间调度来分配各个线程的执行时间，多时间片轮转以此塑造出“多线程并行”的假象。而超线程则是充分利用 CPU 在执行某个线程时多余的资源，在不影响当前线程的情况下再开一个线程，用到的则是空闲的资源；而一旦发生资源竞争，超线程就会终止。也就是说“超线程”在其出现的时候，是真正意义上的“并行”。

还是举例来说。

多线程就像是《火影忍者》中学习影分身术的忍者，忍者需要通过在各个事务间高速移动，并且不停接续每项事务的上一个状态，来达到一种“出现分身”的假象。但实际上忍者还是只有一个，因为做每件事都需要忍者投入全部资源，也就无法将资源共享出去。

而超线程则像是一个人一边看书一边泡脚，确实一个人在看一本书的情况下无法在同一时刻再看另一本书，因为大脑、眼睛都处理不过来；但这并不妨碍他在看书的同时泡脚，因为泡脚并不需要占用大脑和眼睛的资源，而脚这个资源在看书的时候正好是处于空闲状态的。也就是说在进行一项无需投入全部资源的任务的时候，必要资源分配出去后剩余的资源还能够支撑其他任务，并且其他任务也不会对当前任务产生干扰，那么这两项或者是几项任务就可以同时执行，并行不悖。也因此，超线程带来的性能提升远不如多核处理带来的性能提升，因为在超线程中，多个任务的规模并不是对等的，也就不会出现“性能提升两倍”的现象。

来自博文《“常数变易法”有效的原理》

常数变易法

为什么写这篇文章

学过“常数变易法”的同学请直接点击“常数变易法的原理”
这里只讲述常数变易法的原理，为什么要用常数变易法请参见参考资料《常数变易法的解释 》

在学习高数的过程中，关于为什么在解一阶线性微分方程的时候要使用常数变易法，为什么可以使用常数变易法，常数变易法为什么是有效并且正确的，老师都语焉不详，一笔带过，导致一直不能很好地理解其中的数学思想。自己也只能接受老师的解释，将这个方法强行合理化。

但是最近再次看到一阶线性微分方程的求解，看到直接给出来的求解公式一头雾水，再去翻书，始终还是感觉隔靴搔痒，雾里看花，始终不自在，所以上网搜索了一下，搜到了一篇相关文章（常数变易法的解释 ），终于明白了其中蕴含的深刻而巧妙的数学思想，喜不自禁。

所以在此记录下个人的理解，一则梳理自己的思路，二则可供感兴趣的同学参考，倘能有助于大家理解常数变易法的“自然”性，亦是幸甚。

什么是常数变易法？

有以下一阶线性微分方程：

其中，$P(x)\not \equiv 0$ 且 $Q(x)\not \equiv 0$。

若解其对应的齐次方程：

则易有：

即为齐次方程的通解。

这时，我们可以用常数变易法来求非齐次方程$(1)$的通解，即将齐次方程$(2)$的通解中的常数$C$换成（变易为）一个关于$x$的未知函数$u(x)$，变易之后，非齐次方程通解表示如下：$y=u(x)\cdot e^{-\int P(x)dx} \Big(u(x)\not\equiv 0\Big)\tag3$于是将该通解形式代入原方程$(1)$，可以解得：$u(x)=\int Q(x)e^{\int P(x)dx}dx+C$将上式代入$(3)$式，即可解得：$y=e^{-\int P(x)dx}\cdot (\int Q(x)e^{\int P(x)dx}dx+C)$这就是所谓常数变易法。
可以看到，这里把常数 $C$ 直接代换为了函数$u(x)$ ，显得十分生硬不自然，没有什么说服力。然而书上很少会对这个方法的由来作出介绍，所以想必会使很多人感到困惑。

错误的理解

对于常数变易法，我以前的理解是：
既然 $y=Ce^{-\int P(x)dx}(C\neq 0)$ 可以使齐次方程 $y’ +P(x)y=0$ 成立，那么在其基础上增添一个函数，就应该使得该方程运算结果多出一个与自由项相关的余项$Q(x)$，所以可以使用常数变易法。
这样的理解是基于表面形式做出的一个解释，然而还是不能够明确地说明这个方法的正当性与正确性。
所以我们需要进一步探究其内在的原理。

常数变易法的原理

基本

容易理解，我们可以把任意函数表示成为两个函数之积，即 $y(x)=u(x)\cdot v(x)\tag4$对 $y(x)$ 求导，得：$y’(x)=u’(x)v(x)+u(x)v’(x)$

计算

将 $y(x)=u(x)\cdot v(x)$，$y’(x)=u’(x)v(x)+u(x)v’(x)$ 代入非齐次方程$(1)$，整理得到：$u'(x)v(x)+u(x)\cdot [v'(x)+P(x)v(x)]=Q(x)\tag5$由解一阶线性微分方程的常用方法分离变量法容易想到，如果没有 $u(x)\cdot [v’(x)+P(x)v(x)]$ 这一项，我们就可以简便地利用分离变量法进行计算。
现在单独考察 $u(x)\cdot [v’(x)+P(x)v(x)]$ 这一项。其中 $u(x)$ 不确定，不能用来保持 $u(x)\cdot [v’(x)+P(x)v(x)]\not\equiv0$ ，所以考虑另一个因式 $v’(x)+P(x)v(x)$ 。显然 $v(x)$ 是不确定的，在 $u(x)$ 不确定的情况下，可以任意取值。则假设 $v(x)$ 满足 $v'(x)+P(x)v(x)\equiv0\tag6$ 观察式 $(6)$ ，可以看到其形式与式 $(2)$ 基本一致。
求解式 $(6)$，可以得其通解形式：$v(x)=C_1\cdot e^{-\int P(x)dx}\tag7$将所得通解代入 $(4)$，则$y(x)=u(x)\cdot C_1\cdot e^{-\int P(x)dx}\tag8$将 $(8)$ 式代入 $(5)$ 式，得到：$u'(x)\cdot C_1\cdot e^{-\int P(x)dx}=Q(x)$使用分离变量法，容易解得：$u(x)=\frac1{C_1}\int Q(x)\cdot e^{\int P(x)dx}dx+C_2\tag9$将 $(7)$ $(9)$ 同时代入式 $(4)$ ，则$y(x)=e^{-\int P(x)dx}(\int Q(x)e^{\int P(x)dx}dx+C_1C_2)$令$C=C_1C_2$，则得原一阶线性微分方程的通解为：$y(x)=e^{-\int P(x)dx}(\int Q(x)e^{\int P(x)dx}dx+C)$

推广

这一部分是在知乎看到了关于“常数变易法”在高阶作用的问题之后增补的

问题链接：常数变易法思想的来源或本质是什么？
现在有一般$n$阶线性微分方程$P_{n}(x)y^{(n)}+P_{n-1}(x)y^{(n-1)}+P_{n-2}(x)y^{(n-2)}...+P_{1}(x)y'+P_{0}(x)y=Q(x)\tag{10}$
由前述有，$y(x)$可以表示为$y(x)=u(x)v(x)$。
现在我们考察两函数乘积的高阶微分形式。
比较二项式展开定理我们不难发现，对$y=uv$的高阶微分具有类似的形式。
比如：$(uv)'=u'v+uv'$$$$(uv)''=(u'v+uv')'=u''v+2u'v'+uv''$$$$...$
从原理上来看，展开多项式的每一项都应有$n$阶微分，而这$n$阶微分分别分配在$u、v$上；对于多项式的每一项，相当于任选$k$个微分算子作用于$u$，则另有$(n-k)$个微分算子作用于$v$，与二项式展开定理本质相同，所以展开形式也应相同。
则有式$(11)$：$(uv)^{(n)}=C_n^0u^{(n)}v+C_n^1u^{(n-1)}v^{(1)}+C_n^2u^{(n-2)}v^{(2)}+...+C_n^{n-1}u^{(1)}v^{(n-1)}+C_n^nuv^{(n)}\tag{11}$
将这个一般形式代回式$(10)$，假设将$u$作为主要研究对象（以$v$为主要研究对象亦可，二者地位相同），则按$u$的导数降阶排列多项式：$M_{n-1}(x)u^{(n)}+M_{n-2}(x)u^{(n-1)}+...+M_0(x)u'+\bigl(P_n(x)v^{(n)}+P_{n-1}(x)v^{(n-1)}+...+P_{1}(x)v'+P_0(x)v\bigr)u=Q(x)\tag{12}$
其中，$Mi(x)$为关于$x$的多项式。
按一阶情况下的原理，可以令多项式$\bigl(P_n(x)v^{(n)}+P{n-1}(x)v^{(n-1)}+…+P{1}(x)v’+P_0(x)v\bigr)\equiv0$消去$u$项。解$v$即为解式$10$对应的齐次线性微分方程。
则剩下的式子为$$M{n-1}(x)u^{(n)}+M{n-2}(x)u^{(n-1)}+…+M_0(x)u’=Q(x)$令$\alpha(x)=u'(x)$，则上式化为$M{n-1}(x)\alpha^{(n-1)}+M_{n-2}(x)\alpha^{(n-2)}+…+M_0(x)\alpha=Q(x)\tag{13}$$
比较式$(12)、(13)$，可以看到：通过常数变易法，成功地把求解一个$n$阶线性微分非齐次方程的问题，为了求解一个对应的$n$阶线性微分齐次方程和一个$(n-1)$阶线性微分非齐次方程的问题。

总结

很显然我们可以看到，常数变易法是蕴含了很深刻的数学思想、具有很强健的数学基础的解题方法，并非无根之萍，更不是突发奇想或是强行合理。
但是从其原理上来讲，将其称呼为“常数变易法”是不太妥当的，本质上它并非是单纯地使用一个函数来替代了齐次方程通解的常数。
常数变易法的称呼应该说为了便于日常应用和直观记忆，这里可以不必纠结。

参考资料

[1] lookof,常数变易法的解释
[2] 崔士襄,邯郸农业高等专科学校,“常数变易法”来历的探讨

壬辰一考，方见不足，只余心伤难住。一十五年，学中不忘，风雨思仙途。再堪回首，菩提树下，一阵龙吟天鼓。何人知：我辈年少，可能无数。

公元2010（庚寅）年11月14日夜21：03，晚自习，无故心情大好，故作

窗外冷月洒清辉，

屋内如昼有灯垂。

未见后羿射九日，

却有嫦娥登月回。

五道天地人神鬼，

修罗之道不在内。

我自癫狂我逍遥，

哪由他人论白黑！

（2010.12.28日，夜，20：56晚自习，补作）

地有义，

人活世间真不易。

七尺男儿躯，

顶天又立地，

空叹太古，

时光如白驹过隙。

风云将起，

祸乱天地，

雄心壮志至斯不已。

虎龙相生，

大鹏同风起。

梦入神机，

顶天立地伟丈夫莫逆，

感天动地真英雄无济

帷幄神机，

世间纤毫测算无遗，

奈何不能明己，

男儿立志开天辟地！

天有情，

地有义，

人活世间真不易。

七尺男儿躯，

顶天又立地！

晓风残照，落红为妆。

不识大道，此心永殇。

纵横宇宙，睥睨八荒。

飞扬跋扈，虚梦一桩。

王侯将相，谁人久长？

风云变幻，前路迷茫。

我欲改命，谁可扶相？

悲悯天下，泣血炎黄。

匹夫一怒，覆灭玄黄！

——————————————————————————————————————

天道长享，既寿永昌！！！

兴之所至，提笔为诗，茫茫然不知所云

凑字数故带冥王星

域外苍茫星耀光，

夜夜吾梦入洪荒。

回望火星苍苍凉，

警钟长鸣铛铛响。

天海冥王三星降，

日似龙头四面汤。

中土千古一梦想，

放眼宇内心激荡。

但望地球非绝唱，

代代前人总惆怅。

九州风云总要让，

宇内生灵何与抗？

伦理道德万年长，

星途遥远独泪殇。

生灵源于星斗傍，

星斗源于宙缩张。

缩缩张张不见光，

黑白二洞太极样。

黑者阴也司灭亡，

白者阳也主生长。

吞吐之间衍道行，

宙际来去洞连相。

天马神驹铁蹄扬，

飞碟无声择日降。

相坐勿怒叙旧伤，

目望不到二洞长。

一叙久别有无恙，

何以令尓弃故乡？

二叙仙神在何方，

通灵显圣多猖狂。

三叙何处育炎黄，

神龙皇者自主张。

言叙久时多孟浪，

待入席时把话讲。

张灯结彩心昂扬，

非是俗事使我忙。

此乃域外天客到，

糊糊涂涂把神装。

心慕仙法志如钢，

世世生生随梦张。

大道五十衍四九，

独余其一驻天上。

噫唏！

三千大道，

凡人各取其一，

吾独取三千而皇！