我的天

循环和递归，对路人甲来说那是差不多的玩意，反正就是在那里转圈圈。但是，虽然已经认识递归好些时间了，但我依然非常害怕这个存在。之所以害怕递归，是因为我很难想象到底递归什么时候才是个头，而我又非常明白，达不到递归的头，就不能把东西返回出来，得到我想要的答案。这个玩意就像一个无底洞。于是每次当我遇到递归，我都会在那里瑟瑟发抖，大概要克服这个，我需要非常大量的递归练习，让理解这个东西变成我的条件反射。

我不知道，在实际编程过程之中，到底会不会真的经常用到递归这种恐怖的东西。在Think Python 2这本书里面，很早就已经在说递归。还记得递归这种东西他们是结合小海龟一起折腾人的。现在回想起来，这或许是个正确的选择。因为小海龟是一个画图的东西，会让你用更直观地去理解递归到底在做什么。我还记得他们要我们理解的那个树杈和雪花。树杈那个图还算是一个比较正经的东西，雪花那个图案，简直是让我头皮发毛。每次说起递归，我就会想起小时候家里那个卷纸筒。黄色的卷纸筒上面，有一个卡通熊猫在拉卷纸的图案，而它拉的那个卷纸筒上面也贴着一个熊猫在拉卷纸。每次看到纸筒上的那个图案，我就会盯着看，然后脑子就会不断想象，熊猫卷纸筒，熊猫卷纸筒……想着想着甚至会觉得好恐怖，到底什么时候才是个头！这跟俄罗斯的套娃不一样。我总觉得，俄罗斯套娃无论套子多精细，总会有个头，但是，拉卷纸的熊猫，对我来说简直是个噩梦。我觉得，拉卷纸的熊猫是递归，而套娃是循环。

昨天我花了大半天的时间查单位的某些账本。查出了一箩筐的问题，我不知道为什么之前他们检查居然没发现。绝大多数都是弱智的问题，不弱智的问题则代表了他们做事的时候根本没用脑子去思考。那些莫名其妙的错误几乎到达了一种人人都有永不落空的境地。这也实在是太强大了吧！归根到底，是因为根本没有人去统一他们。每个人都看着那个规则，每个人都有自己的理解，又或者他们没看规则，只是按照上一个人的方法去做，但是他们对上一个人的做法的理解又各不相同。情况就像一个人不断地传话给下一个人，当人数传到一定程度的时候，原本的故事就会变得乱七八糟。我还记得第一次发现这个现象是在翡翠台的综艺节目超级掌门人上。这是我第一次认真地去揪他们的错误。不只是核对核心数据，也看了格式上到底合不合要求。有时我真的不明白他们，这样干活，他们觉得自己对得住自己的工资吗？他们晚上为什么居然能睡得着觉？换个说法，为什么他们这般吊儿郎当却没有东西惩罚他们？即便不是金钱上的惩罚，但起码也要让他们心里不好过，比如批评一下。但或许批评根本无效，就像你妈妈骂你一样，左耳进右耳出，就只是一阵耳边风。既然不能用惩罚，能不能用奖励的机制呢？在这个单位，爬上去的那些人你也说不上到底牛逼在哪里。没有惩罚，也没有奖励，于是也就可以理解，为什么他们会这样。

不是人人都能自律，对不自律的人必须用铁手腕。

在我记忆之中，我从来没有把一本编程类的书完整看完过，以前我都是挑着来看。自己需要用哪些功能，就去找哪些章节去看，而这次学习python，我是下了狠心的。几乎可以这么说，一天到晚我的脑子里就只有那些东西，即便是睡着了也一样。做梦的时候，我依然是想着python。还记得在学习递归的时候，某天晚上我做梦梦见了一个瀑布，但实际上瀑布并不是真的瀑布，那不过是一个正在流着很多水的建筑物外墙。那个瀑布从一个分成两个，再分成多个。不同的水量有不同的效果。我第一个感觉是那应该是一个自然形成的瀑布吧。但当水全部停住的以后我才发现，原来一切都是人造的。瀑布是在一个玻璃屋的外墙上形成的。之所以有这个脑洞，大概是因为我的记忆深处借鉴了东站广场的那个瀑布。还记得初中的时候我们几个同学还专门过去那里看人造瀑布。后来我不记得那里变成怎样了。反正那应该是东方宝泰外面的吧。再到后来，去东站附近通常都只是为了去宜家家私，然后下到东方宝泰里面的吉之岛，其它的东西一点印象都没有了。至于从前的那个瀑布还有没有，我实在想不起来。自从宜家家私再也不在东站的那个卖场以后，感觉我好久都没有去过那个地方了。光是东方宝泰一家，对我和我妈都没有什么吸引力。

城市的变迁，总免不了会发生东西不断消亡，但当从前熟悉的东西消失，会让人觉得无比怀念、依依不舍，但即便这样，它们还是会消失，除了在从前的照片和影像资料里再次重温，无论如何我们都回不到那个时候了。

有时我会很怀念从前到万松园市场。万松园市场在我的脑子里印象非常深刻，那些卖鱼的、卖菜的，还有卖杂货的，我都记忆犹新。我甚至还记得了当年不同品种货物的布局。虽然有些小店在我印象之中已经很模糊了，但是我还非常记得，卖鱼的在哪里，卖烧腊的在哪里。那个卖烧腊对出的通道上，某年过节，有人在那里卖老鼠肉。虽然我根本不记得卖的老鼠肉是什么样的，我甚至没有见过一眼，但是从叫卖声让我知道，有人在路中央卖老鼠肉。万松园市场对我来说是一个神奇的地方，虽然跟沙园市场比起来，那个地方不大。那条叫做万松路的路永远都是熙熙攘攘，我甚至记不起汽车是怎么在那条路上行驶的，因为上面总是挤满人。不是每个市场都会让一整条马路不复存在。那里对我来说就是最早的步行街。从前的万松园市场，或者不是这样的，或许我只记住了它热闹的一面。很久以前，这个市场进行了改造，全部都档口都入室经营。我一直觉得，新的万松园市场我很陌生。不只是我，我的家人也很少再去那里买菜了。之所以这样，其中一个很重要的原因是他们把蔬菜和水果档口放到了二楼，对老人来说，这非常不方便，因为没有电梯。我甚至一点都记不起2楼到底是怎么布局的。过去十几二十年我加起来，估计上去5次都不到。

在南丰商场下车，穿过人挤人的万松园市场，再过一条马路，山货铺的上面就是外婆的家了。

我看的那个中文版Think Python 2的第11章，习题几乎可以这么说，没一道题的相关是做对的。有些东西，习题跟现在的Think Python 2英文版不一样，我觉得可能是英文版修正了某些东西。修正完以后，英文版并没有写什么更新说明之类的东西，但即便有，中文版翻译的人翻译完以后大概也不会时刻关注英文版有没有变动。同一道题的关联引用，这种东西怎么可以凭着感觉来呢？第一次遇到的时候，我云里雾里，因为按照中文版的那个说法，在某一章书的习题里根本找不到那个东西，但在我印象中，我的确是做过那些习题，到底是在哪一章书里的呢？另外一个版本的中文版那里的索引做对了。当我回看英文原版的时候，发现他们引用某个习题真的写得超简单，但是那些习题全部都是有超连接的，而且锚点到了某一章书的某个确切位置。所以我看的那个中文版之所以是现在这个样子，是不是因为他只是进行了文字上的翻译，还没有仔细研究那些超链接之类的东西呢？又或者在他翻译的时候，他并不是看着英文电子版，我是看英文纸质或者PDF等没有超链接之类的东西。电子版这种东西最让人觉得舒服的应该是哪怕你不标明是那是哪一章书的习题，你只是说那是习题几，只要你把超链接做上去，一切好办。

我看的那个中文版让我无语，但是英文原版也好不到哪里去。因为英文原版的作者脑洞实在太大，让人不知道如何言表。我觉得变成编程这东西，你得给出一个范围，然后再给出一个参考结果，才能让人有奔头。但是他只叫你这般测试，然后再给出一个参考的脚本。在不看脚本之前，如果我只是运行的脚本，而一开始的时候，我们设定的自定义参数不同，该如何判断读者自己的脚本写得对不对呢？有些参数他们完全可以先给出来，或者你会说，那岂不是成了一个提示。这又不是测验考试，重要的不是结果，而是如何整出那个结果，所以即便给你看到最终结果，你不懂过程，还是折腾不出来。英文原版的作者把那些条件参数写在他的脚本里面，而当你写自己的脚本的时候，你又清楚明白到你必须得设定那些参数，但是应该确定为什么呢？拿不准。这就会进入一个怪圈。首先是读者看着题目，自己解答，解答完以后测试，觉得没问题，打开参考答案运行，因为参数答案的结果跟读者得到的不一样，接着我们还得去仔细研究参考答案到底用了什么参数。然后把那个参数放在我们自己的脚本里再运行。对比两个运行的效果。这不是非常折腾吗？如果没有那个隐藏的参数，读者完全可以自己运行一遍，拿参考答案再运行一遍，对比结果就行了。我们最终要做到的不就是那个结果吗？当然，如果得出结果完全一致以后，还是建议大家再研究一下参考答案跟自己的脚本有什么区别，想一想这些区别会不会导致什么问题。

Think Python 2这本书，不只是习题参数设置很让人迷茫。在某些章节里，写得也不细致，比如说元组那一章。元组这个东西据说在其他编程语言里面是没有的。在介绍元组之前，已经说过字符串、列表以及字典。前面三个东西一个套一个，挺容易理解，但是加了元祖进去以后，世界就变得混沌了。因为列表字典元组这三个东西可以互相组合互相转化。有些可变，有些不可变。有些人可排序，有些无效。要真的说清楚元组，第12章书里面已经说到的东西以及已经举过的例子还不足以解决问题。如果他们不把所有东西都说一遍，起码他们得给我们一个列表。告诉我们这些东西可以控制元组，至于具体的使用方法，大家可以查手册。

或许当我把一整本书都看完以后，我的想法又不是我现在这个了。

用了几分钟时间，写了个用字典法查找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个的时候，一般的递归和字典递归简直就是天渊之别。

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