我的天

用两天才终于搞懂一道编程题目，这实在是太过分了。如果有人指点的话，肯定不需要这么长时间。如果在我看到这道题的参考答案之前已经完全明白参考答案里面写的所有东西的语法，我也不需要费这么多时间。对我来说，这个理解的过程就像是在猜谜语。什么样的东西是True，什么东西是False。理论上，这非常的简单，但实际上，当真的问起你的时候，如果还没有人跟你说过有这样的规则，你肯定想不明白，对我这种人来说，搞不明白就直接把那丢给python，要他试给我看会是什么的状况。

以前做条件判断，我都是用一些很明白的东西。用一些大家都知道是True还是False的东西，比如说条件是1大于2，这显然是不成立的，肯定是False，不会在这个条件下进行。但如果条件判断的时候，我传进去的是一个列表呢？列表到底是True，还是False？有东西，比如数字、字符的列表是什么？如果里面只有一对单引号，也就是空字符，那又是什么？还有另外一个情况，列表就只是一对方括号，一个空列表，这又是什么？通常来说，我不会给自己制造这些模棱两可的烦恼，如果是我自己写的条件，我不会这么折磨我自己，大概我会加个明确的判定下去。万一我真的把列表传进去作为条件判断。我会问那个列表是不是空列表，那个列表的长度是不是大于0？只要列表里面的东西，列表的长度就肯定大于0，无论里面是数字、字符，又或者是其他列表，甚至有元组，哪怕列表里面只有一对单引号，空字符串，其实也是有长度的，这样的列表长度为1。但空列表，就只有一对中括号的东西，长度会是0。如果在一对中括号里面又有一堆小号呢？从外面看来，中括号是有元素的，但是从里面的小括号元组看来，元组。这些说起来挺尴尬的事，如果你不知道他们的规则。无论如何都是回答不上来，答案是什么呢？这些答案又非常的明白，非黑则白，没有其他选择。

我不知道为什么在同一个判断上面，参考答案用了好几个表达式，是写脚本的人故意在用这种方式考验我们，还是说他有点随心所欲呢？对优秀程序员来说，通常不会犯这样的错误，或者说这能算是错误，应该是有这样不一致的习惯。养成一致的习惯是非常重要的，比如说注释的习惯。也比如缩进的习惯，在python里，缩进就是4个空格，没有说尽基本上程序就进行不下去了，因为通常你都要写个判断循环函数之类的吧。对我来说，我还没有养成空格的习惯，比如说，有些时候我的运算符和对象之间有没有空格，但有时却又。我完全是凭感觉。有些时候我会把那些东西搞得很开，有些时候我会挤在一起。当然，通常这些都不成问题。

在一道编程题上我之所以耗费那么多时间，就正如我上面所说，是因为在一些我应该知道的东西上面实际上我不知道。于是我得出一个结论，在看这个Think Python 2的时候，估计我得拿着本python的手册，一边学一边翻。显然Think Python 2这本书不会把所有规则都告诉你，因为他们想让你自己去学习，掌握那些他们觉得你铁定要知道的东西。

我不觉得用两天时间去研究透一道题是在浪费时间。

用了几分钟时间，写了个用字典法查找10万单词的词汇表回文词的脚本。字典法肯定要比列表二分法快，但到底快多少呢？实测大概10倍。相比之下，字典法语言实在简练太多。二分法的函数还得考虑递归和起点终点神马，字典法一个in杀到底。

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
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50

# import time
# def in_bisect(library, first, last, myword): # 二分法搜索，10万数据查询最多只需不到20步
#     if first > last: # 这是一句拯救了我的条件
#         return -1
#     else:
#         mid = (first + last)//2
#         if myword == library[mid]:
#             return mid
#         elif library[mid] > myword:
#             return in_bisect(library, first, mid-1, myword)
#         else:
#             return in_bisect(library, mid+1, last, myword)
# j = 0
# count = 0
# library = []
# fin = open('words.txt')
# for line in fin:
#     word = line.strip()
#     library.append(word)
# library.sort()
# start = time.time()
# for i in range(len(library)-1): # 二分法搜索 
#     j = in_bisect(library, 0, len(library)-1, library[i][::-1])
#     if j > -1 and library[i] < library[j]:
#         print(library[i], library[j])
#         count += 1
# print(count)
# end = time.time()
# print(end - start)
# 397, 1.2810001373291016 # 二分法搜索
 
import time
def set_dict(fin): # 字典法搜索
    d = {}
    for line in fin:
        word = line.strip()
        d[word] = 0
    return d
count = 0
fin = open('words.txt')
start = time.time()
mydict = set_dict(fin)
for word in mydict:
    if word[::-1] in mydict and word < word[::-1]:
        print(word, word[::-1])
        count += 1
print(count)
end = time.time()
print(end - start)
# 397, 0.14300012588500977 # 字典法搜索

我觉得必定把我搞死的筛选词汇表里的二锁三锁单词，居然不怎么费劲就做出来了。

第一次，我在里面用了一个很傻的循环，其实根本就没有必要。可以不用自己的循环就千万不要在词汇表搜索时多用，但我的第一次尝试并不是毫无意义的，，因为已经能得出结果了，而且结果是对的，虽然非常慢，慢到我无法忍受程序继续运行下去。然后，我把要搜索的东西全部都丢到二分法搜索里面，循环只剩下一个必须做的，因为要把词汇表过一遍。第一次做二词互锁的时候，我在一个循环里套了两个if，然后我又把那两个if做成平行的，其实也就是把两个本来嵌套起来的条件用一个and连接起来，很多时候我们都需要这么干。因为除了要二锁，还要考虑三锁，显然人肉去做这些判断，写一大堆一模一样的东西实在太无聊，所以我又自定义了一个新函数，把需要判断的东西全部都丢掉里面，最终返回True或者False。其实，之前我已经考虑过要直接这么干，但因为前天在做搜索回文词的时候我已经得出了回文词的索引，所以直接用就好。我个人觉得，效果是差不多的。

在搜索互锁单词的时候，输出时我用的是字符串的变体。因为二分法搜索被我丢到了一个多条件复合的判断函数里面，所以返回的东西，只有True与False。如果全部都是True的话，就意味着那些单词辩题应该全部都OK没问题。也正是因为输出的东西已经没有索引返回，所以结果我直接使用单词的变体表示。这样的效果很惊人。之前我套用了两个if，然后我写了一个判断函数把条件都含进去了，这样的改进让脚本的运行时间缩短了一半。如果一开始我没有见过两秒多的那个效果，我肯定不会为一秒多的那个惊叹。这是我一步一步琢磨出来了的。

首先是实现得出结果，然后是对语句进行重构，接下要让这个程序适用于二、三词互锁，所以我做的东西是泛化。一开始我把所有判断都写在主程序里，后来我又把它分出一个函数，也就是封装。无意之中，我在执行着Think Python第四章里说到的开发方法：写小程序、封装、泛化、重构。无论是大程序还是小程序，其实都会经历这些。我会从一些我最熟悉的东西开始实现功能。但是我最熟悉的东西不意味着效率一定会高。循环再循环以后，得出一个词都要好几秒时间，实在让人难以接受，尤其当这个词到下个时中间要相隔几秒甚至是十几秒才有反应的时候。这就逼迫着我一定要改进，不同的语句能实现同样的功能，但是它们之间的效率是非常不一样。

大家都在用着二分法的思路去搜索，但是我的脚本就比参考答案快接近30倍。单词一蹦出来，我就知道我一定会比参考答案快。因为我的程序里，单词是噼里啪啦完全没有停顿就全部出来的，而参考答案的词语出来的时候虽然不会一直有，但总有一些顿卡现象，那相对于我的程序来说，就像是慢镜头。

我从来没有想过自己能做得比参考答案还要好，或许他们要做到的并不是有多快。相比于不是二分法的搜索，二分法已经很快了。他们想做到的，大概是用最简练的语言，用模块化的方法实现功能，效率倒不是他们最看重的，因为做搜索词汇表这种事在列表里完成肯定比不上直接上字典。但是，如果不曾在列表里面死去活来，又怎么会体验到字典的神奇。

无论我的二分法搜索写得多么高效，肯定还是不如字典的。我体验过用词典进行斐波那契常数计算。当要计算第40个的时候，一般的递归和字典递归简直就是天渊之别。

如果不曾经历，不曾被整得很惨，我大概就不能说自己真学会了那个东西。

昨天晚上，在做那些文字游戏的时候，我做到了好像怎么费劲就轻而易举地把题目做出来了，只需要几分钟到十几分钟。从写脚本到测试成功，整个过程没有状况，甚至写完脚本后，所有东西下面红色波浪线都没有。通常，我都会习惯忘记在句子的结束加上冒号。Python要求必须严格缩进，多了少了都不行，而且使用缩进必须用一样的方式，通常必须要求用4个空格。习惯了用VSCode以后，我会设置缩进为4个空格，当我在上一行回车之后，如果上面是冒号，下一行就会自动缩进4个空格。但如果某段代码不是我写的，而是从某个地方复制过来的，就可能会出现状况。所以为了避免这种无聊的出错，我把所有占位符都显示出来。比如空格，也比如tab。大概对其他人来说，写代码就应该是行云流水的。知道自己要实现的功能是什么，知道自己应该用什么方法，然后按照思路按部就班。调试这种东西没有个尽头，没有说用了某些方法测试就能一定保证调试完以后程序没有任何的bug。只能做到尽可能少bug，不可能做到完全没有bug。不知道从什么时候开始，我觉得不把话说死非常重要。

昨天我终于体验到云流水般写代码，是因为在行云流水之前我已经纠结过好几个小时。在行云流水之后，我也遇到了命令行的光标卡在那里，不显示程序有错误，但是程序也不进行下去。如果我进入了死循环，程序出不来，Python会提示我上面已经进行了超过994行，别浪浪费大家精力了。之前我已经见识过了。而昨晚我遇到的是光标停在那里，没有任何提示。脚本那里也没有任何红色波浪线，说明语法是对的，起码静态语法没问题。当我再次看到脚本的时候，发现原来是我在用while进行循环迭代的时候，没有设置改变条件的东西，于是while的循环就停在那里了。在我构想那个循环的时候，其实我是设定好增量条件的。我的脑子已经准备好了，但我的手指并没有把增量条件敲上去，所以就出现了之前死在了终端的状况。我不知道光标死在了终端我还能做些什么，反正我的处理方式是把终端关了。光标停在那里，输入什么都没有反应，又或许如果我在单独的CMD命令行里搞那个的话，我可以用某些什么方式从那里跳出来。只是我现在不知道该做些什么。因为我是在VScode的测试，所以我简单地把那个终端的窗口关掉，重开一个就好。

还记得，在大学里学习C语言的时候，其实我不怎么喜欢用while这个东西循环，我更喜欢用for。拿Python跟C语言比，我觉得后者需要我们在写代码的时候更加仔细严谨。比如花括号这种东西绝对不能省。也比如某个对象在使用之前必须先声明，不只要说明它存在，而且要确定好那是一个什么类型的东西。在循环控制方面，C语言一开始就必须得想好所有。相对而言，Python很自由。昨天我突然发现原来in这个东西可以让if这种语句也具备循环的功能。在实现某个功能的时候，我用了两个for嵌套，而参考答案只用了一个for和一个if，出来的结果完全是一样的。我在两个for里还得加个if做判断，相对参考答案而言，显然就有点臃肿了。

我明明知道做习题会让我死去活来，但是一定程度上，我却在享受那种征服未知的刺激。

大学学习C语言的时候，基本上我不会写单独的函数，所有要解决的事都在主函数里搞定了。当时我学过判断和循环，但是，我却从来没学过递归。在解决一些简单事情的时候，循环跟递归，没什么差别。从理解程度来说，我觉得循环更简洁一些，但是，当某个东西像套娃那样一层叠一层，每层里面依然用同样的规则继续套叠，不知道要叠多少层的时候。递归就会展现它无穷的魔力。循环难以实现这个，又或者循环并非实现不了，但是递归在完全不需要体现循环的框架下，简洁的语言就已经在做着循环的事情。

昨天，我第一次在Python里见到这个恐怖的递归。外国人的书，我觉得都有一个特点。正文的时候举的例子都很简单，但是一到习题，就会把你彻底搞死。习题里面会偷偷带入一些超纲的东西。大概写书的人理所当然默认你应该知晓。这种事情我已经在学习Java的时候领略过。当时那本书之所以没法看下去，就是因为我没办法想象出作者的脑洞到底是什么。他们的习题几乎可以说大多是一些填空题，但要实现一个功能，其实未必一定就得用某种方法。你给我一个条件，给我一些目标值，我能做出来也就OK了，为啥必须走你的路呢，这非常难。之前我不觉得自己跟外国人的脑洞到底差多远，但是当我对比过自己和他们写的程序以后，我发现真的差挺远的。虽然我们都能实现某个功能，就效率而言，感觉上没差多少，因为我只是在做一些非常初级的东西。应试教育的时候，有标准答案，当然好判定成绩，但实际上，编程这种东西真心应该天马行空。给我一个效率的限制，比如说完成某件事，必须在多长时间之内解决，代码长度不能多于多少，至于我用什么办法，这是我的事。

说回递归函数这件事，在处理几个简单数字的时候，可能你感觉不到它的强大，但是，当我见识过用那个东西画出来的层级图形以后，我简直就只有站在旁边瑟瑟发抖的份儿。真的不知道是哪个神经质想出来这么强大的东西。但实际上，深究下去，那也不是很强大，那不过是不断地重复一些已经设计好的事情而已。如果要人去做那些重复，一开始还好，但是随着事情的深入，会慢慢乱套，但是计算机不会，他们会一根筋地执行我们的指令。最终出来的结果是令人惊叹的优雅，还是乱七八糟一坨屎：就得看设定规律的人的功力了。

递归现在对我来说是一个非常恐怖的东西。因为我不了解它，所以我害怕它，就像当年认识循环一样。但是，用好递归以后，我的武器库里就会增加一个杀伤性非常大的家伙。说到递归，让我联想起新冠病毒。这个东西的递归到底什么时候才是个头？我觉得这肯定不是一个死循环，自然界非常擅长递归，处处都是数学和逻辑你知道吗？！但是，到底要递归多少次，全人类才最终能看到隧道尽头的曙光呢？到底这个新冠病毒函数的递归里埋伏了多少个随机数呢？学习递归让我明白到，层级少好对付，层级一旦扩增，那就是次数级的增长，而且，说不准到达一定层级的以后就会触发某些大招炸弹，想想都心寒。

编程是一个让我重新理解自然规律的过程。