我的天

整个科室的人都出去培训了，除了我，所以一整天下来很安静，几乎没有人过来打搅我。只有一个过来找出去培训的那些人，神奇的是昨天单位微信群上也很安静，没有经常闪动。为什么会如此平静呢？

摸鱼这种事情有别人在跟没别人在对我来说没有区别，当我要摸鱼的时候，谁也阻止不了我。虽然有时摸鱼的时候不得不东躲西藏。可当我要认真的时候，同样也是没人能阻止我，不管那是上班还是下班，是白天还是半夜，只要我想干下去，哪怕那跟加班费没有半点关系，我也不会停下来，因为那是我想要干的事。

四周很安静，没有任何的干扰，也没有什么特殊的任务突然降临，所以我该做些什么呢？在做完平时应该做的那些事以后，我应该做些什么呢？摸鱼什么的摸多了也会觉得无聊，所以还是要找一些正经事干一下。有事可干的时候，你就只管去干，干就完了，但是当你无事可干又得找些事干的时候，的确挺烦恼。我觉得这个烦恼对我来说已经存在了好长一段时间。究其原因是有些时候你根本打不起去干某事。一方面你没什么事干，另一方面是有些事你或许可以干，但是你不想去干。这两个因素凑起来就变成了一个死循环，人就是在这个死循环里。慢慢地耗费着生命。

前天下午，我突然想到要以另外一个数据模板写一个VBA的汇总脚本。汇总脚本之前我已经写过，而且已经用了一个入户周期，2.1万吨的玉米入库绝大多数都是通过那个东西生成的，一直都没有问题，所以根据我的数据模板生成那个东西是完全没有毛病的，但如果我换了一个数据模板呢？我自己的数据模板没有毛病，其中一个很重要的原因是里面一些关键参数的设定我是以我的模板的某些数据量身定做的，但如果我换了一个模板我就得把某些数据转换过来。比如把两列的数据有条件地合并为一列，这是可以预知的，另外一些不可预知的我只能尽可能的把我想到的都做出来。当我遇到这个问题的时候。我感觉明明很简单的东西，为什么就要搞出那么多的花样呢？为什么这个不应该随心所欲的东西，实际上就这般随心所欲呢？大家都是说根据某个国标去做的列表，但实际上用起来的时候五花八门。我自己用的那个转换脚本是完全根据我的那些乱七八糟理出来的，但我不知道别人的乱七八糟到底乱成一个什么模样。这是一个无底洞，我自己的处理方式是嵌套很多层replace，但显然对小白来说，这样的操作非常不友好。所以在新的汇总脚本里，我采取的方式是建立一个索引，把集合五花八门的索引得先建立好了，然后我再以左外的方式匹配某些关键词，把所有的内容给关联上去。因为是开放的，可以很容易进行编辑，而且不需要他们懂得任何公式嵌套技术。这是我能想到的一个很大的坑，但我觉得还有一些更大的坑隐藏在阴暗处，比如别人生成汇总的那个数据模板不是我理解的那一款，他们需要在那个模板上手动编辑才能出结果。这就意味着索引的方式得发生变换了。还有一个就是万一在另外一个参数的地方，他们那个基础数据表还得进行某些修改才是他们汇总表的那个格式，那么那个地方也需要进行加工。综上所述，我觉得其实这些坑可以完全不存在，但问题就是设计软件的人和使用软件的人思路不一致，使用软件的人没有考虑到以后会被要求进行这样的操作，所以一开始默认套用了某些增加参数的方式。最终结果是他们得绕一大个圈、人肉查找好几个表才最终汇总出一个结果。这样就会导致汇总出错的概率提高，同时也会让人没有必要地忙乎一大轮，而且是天天都得这么忙。

如果把这些事情都理清了，根本不是问题，但可以肯定的是，不是所有人都愿意在这个理清上面花时间、把这一整套人肉的操作变成自动化。因为从根本上说大部分的他们只是为了仅仅完成任务，而从来没想过要把那做得更好、做到极致。

又花了大半个下午的时间，我把python跨表查询版最后的那个小计功能也开发出来了。其实前一天晚上我已经找到了类似的案例，只要按研究透的那个东西，接着往我自己那里套就可以了。我大概明白里面用到的公式到底是干什么用的，但是把它们套起来了以后，我发现用在我的那里无论如何都不对，所以我就在案例里不断套脚手架，不断地做注视去掉东西。最终发现让我失败的原因是我的那个dataframe是没有索引的，这就让我后面折腾了好长一段时间。

要在dataframe里加小计，首先需要对进行小计的项目进行分组处理。前一天我已经了解过，这样分组出来结果就只是那些聚合的数据。这些聚合的数据如果你不需要带入特殊的分组词，那么你跟原数据合并，然后根据你的分组项目名排序，小计就会合体到原来的dataframe里。如果你要加入小计这样的词语，你就得虚拟新增一列以非分组项目为名称的列名，内容就是小计之类的词。这样的分组结果我不知道为什么那个案例最后要设定以分组项目为索引，因为我在折腾那个案例的时候发现做不做这一步出来的结果没区别。

最最关键，让我折腾半天的根本原因是我要加小计的那个dataframe在从Excel读取数据的时候就已经设定了不添加索引。我发现当我去掉了案例的默认索引以后，和我的脚本出现了同样的问题。所以解决方案是先给我的datafame添加一个默认索引，然后再进行上面说到的分组操作，接着把有默认索引的dataframe跟分组结果结合在一起。同时对分组项目排序。分组后的结果有没有默认索引都无所谓，因为合并时都得重置索引。我没有试过如果这个dataframe也自带了默认索引，最后能不能成功合并。纯粹为了探索，我应该了解这个，但因为我运气好，在研究之前就已经得到了我想要的结果，所以我就没有继续下去，接下来我会继续拿那个案例把玩一下。

为什么会在Excel的单元格数据传入pandas的时候就把默认索引禁止掉呢？其实不禁止也完全没有问题。因为在最后把加工过的东西输出的时候，我可以控制不输出。之所以会有这样的习惯，写出这样的控制，是因为我看的第一本用python批处理Excel的书里面是这么写的。在看那本书的时候，我觉得那本书写得一般般，因为他给出了一个例子，然后大概告诉你要实现什么功能，接着就是展示脚本。我觉得起码你得在介绍那个例子的时候，除了源数据本身，也得展示一下你最终的效果是什么。他们还偶尔说不清具体需求是什么，唯有去研究他们的代码，你才知道原来具体他们要干那个。

在一个明细数据表里加入小计这东西是完全可以实现的，但是从数据处理的角度考虑，为什么我要把明细跟汇总合并在一起呢？如果用我的Excel思维去考虑这个问题，我觉得明细表就是，明细表汇总表用透视表表达出来就好了。因为数据透视表是很灵活的，可以用任意的汇总维度去观察同一个源数据。python可以轻松处理Excel的数据，但是到了Excel以后，展示的方式的控制好像python的插件就有点难以直接控制，而要控制这个最好的方法就是通过api，用VBA控制，因为vba是原生office的自带工具。

我发现python批处理Excel脚本的运行速度跟电脑的CPU有很大关系，跟内存大小关系不大。用我办公室的电脑运行，但需不到6秒，用我宿舍的电脑运行大概需要7秒，用我家里的电脑运行大概需要7.5秒。这是在正常的情况下，如果我的电脑正在执行多任务，这些时间就会说不准了。之所以我说这跟电脑的CPU性能有关，因为运行脚本的时候我盯着任务管理器。发现有段时间Excel的CPU会飙升最大40%，虽然维持的时间很短。不同性能的电脑同样CPU，封顶都会飙到40，这就意味着CPU的核数越多，单核的性能越好，那么这个脚本的运行速度就会越快。6系的i5运行6秒，2系的i3运行8秒，是有差距，但经历过Power Pivot得12秒起，python很爽了。

我觉得这个python脚本还有继续改进的空间，继续努力。

我是看着题目的中文版做题的

练习10：要检查一个单词是不是在上面这个词汇列表里，你可以使用 in 运算符，但可能会很慢，因为这个 in 运算符要从头到尾来搜索整个词汇表。我们知道这些单词是按照字母表顺序组织的，所以我们可以加速一下，用一种对折搜索（也叫做二元搜索），这个过程就和你在现实中用字典来查单词差不多。你在中间部分开始，看看这个要搜索的词汇是不是在中间位置的前面。如果在前面，就又对前半部分取中间，继续这样来找。当然了，不在前半部分，就去后半部分找了，思路是这样的。不论怎样，每次都会把搜索范围缩减到一半。如果词表包含了113809个单词，最多就是17步就能找到单词，或者能确定单词不在词汇表中。那么问题来了，写一个函数，名为 in_bisect，接收一个整理过的按照字母顺序排列的列表，以及一个目标值，在列表中查找这个值，找到了就返回索引位置，找不到就返回空。

做到死去活来词语在词汇表里有索引正确，没有时却会疯掉的时候我不得不去看答案，看到答案后傻眼了，答案对单词的判断只有True和False，再去找原题，我那个去，题目改了！不要求索引了好吗！

Exercise 10: To check whether a word is in the word list, you could use the in operator, but it would be slow because it searches through the words in order. Because the words are in alphabetical order, we can speed things up with a bisection search (also known as binary search), which is similar to what you do when you look a word up in the dictionary (the book, not the data structure). You start in the middle and check to see whether the word you are looking for comes before the word in the middle of the list. If so, you search the first half of the list the same way. Otherwise you search the second half. Either way, you cut the remaining search space in half. If the word list has 113,809 words, it will take about 17 steps to find the word or conclude that it’s not there. Write a function called in_bisect that takes a sorted list and a target value and returns True if the word is in the list and False if it’s not. Or you could read the documentation of the bisect module and use that! Solution: http://thinkpython2.com/code/inlist.py.

又纠结一番后我终于写出了一句“first > last”返回例外情况，终于，世界被拯救了！记录索引和不记录索引很不一样啊，按照参考答案的解法，i即便返回也永远是1，索引无能。纠结是有好处的，让我明白到二分法搜索有多么的高效，简直甩while循环几十条街，但如果真索引的话，估计我会很懒地直接用list.index()，虽然用之前必须用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 None
    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)
myword = 'zoo' # input('myword is: ')
i = 0
library = []
fin = open('words.txt')
for line in fin:
    word = line.strip()
    library.append(word)
library.sort()
start = time.time()
 
# j = 0
# while i < len(library) - 1: # 我的脑洞第一反应用的循环
#     if myword == library[i]:
#         j = i
#         break
#     i += 1
# if j == 0:
#     print('myword is not in library')
# else:
#     print('index =', j)
 
# if myword in library: # 伟大列表自带的查询索引号，但先得确定单词在那里
#     i = library.index(myword, 0, len(library)-1)
# if i == 0:
#     print('myword is not in library')
# else:
#     print('index =', i)
 
if in_bisect(library, 0, len(library), myword) == None: 
    print('myword is not in library')
else:
    print('index =', in_bisect(library, 0, len(library), myword))
end = time.time()
print(end-start)
# myword is not in library while 0.07   index 0.003  bisect 0.001
# apple 4450               while 0.003  index 0.001  bisect 0.001
# zoo 113707               while 0.07   index 0.005  bisect 0.001
# while，index和bisect没有对比就没有伤害

你永远都猜不到前方有什么奇葩事情在等待你，哪怕你正在做的事你每天都要做，或者你这辈子已经做过很多很多次。比如说在刻Lucha Underground logo的橡皮章之前，我已经刻过超过50个，但那一次，我也不知道为什么居然刻刀切手指了，我自己却毫不知情。直到看到白色的橡皮上出现铁红色，我才恍然大悟。比如说上个周六跑的18K我的心率不知为什么在几K后就飙到了160以上。我已经在那条路线上跑过非常多的18K，合计超过80次，无论是盛夏还是严冬，无论是下雨还是烈日，都没发生过那种事。比如上周在单位我跪在垫子上的时候，脚后跟无论如何碰不到屁股，但今天做完普拉提以后我却发现我跪在瑜伽垫上轻易地做到了。再比如说我已经用Yamb MP4Tools剪过很多视频，也用MeGUI压过很多视频，但今天当我想把字幕通过MeGUI压进剪切出来的mp4的时候，却无论如何都做不到。软件在开始压制之前，已经崩溃了。我的第一个反应是，会不会是因为软件没有做更新？但更新完毕后还是那样。我在官方网站上重新下载，结果还是一致。这是视频源的问题？软件的问题？压制参数的问题？还是电脑开机开太久了，需要歇一下？如果重启电脑就能把这一些都解决，我愿意那么做。但我的直觉告诉我，应该不是那么回事。我要压制的视频是1080p的，虽然实际上那个视频并没有这么高的分辨率，因为从油管上抓取下来1920*1080的视频接近两个半小时，大小却只有2.7GB不到。对1989年的电影，我们实在不能强求太多了，当时还没有什么高清摄像机。油管上的1080p肯定是有些问题的，但总比480p的马赛克好非常多。官方油管上的视频好处是不像普通人用DVD或BD压制那般，技术不好会出现拉丝。看过不少米叔八九十年代的电影后我觉得不知道为什么有一些镜头会很模糊，那应该不是压制的问题而是拍摄的时候对焦失误。这完全可以理解，想想十年前的那些数码相机，因为ISO不高，如果快门时间短到一定程度，又肯定会出现抖动，所以也就只能把光圈调小，光圈调小的后果就是构图里只有目标部分是清晰的，其它地方都有可能糊成一片。十年前的数码相机尚且如此，二十年前的老爷摄像机，估计也逃不出这个。

遇到问题，我觉得妈妈最喜欢在那里嚷嚷，甚至连问题都没说清就在那里嚷嚷！就像着火的时候打电话给119，一直吼，着火了，着火了，却不说到底是在哪里？是什么着火了？既然我觉得那个不好，我就不应该再做那种事。

视频压制不了的那个问题着急也没用。之前在压制DVD的时候我就试过一次，视频源直接拿去压，无论如何都不行。所以之前就得有一个把视频源新索引，然后用索引文件作为视频源输入压制的步骤。这次剪切出来的视频源为什么会压制失败？我发现其中一个现象是，预览的窗口视频的长度并不是我真正剪出来的那个长度，而是整个电影的全长。感觉这就是视频信息没有正确读取的问题。我把视频拿去索引所以然后去洗澡。洗澡回来发现弹出来的预览窗口视频终于正常了。这就意味着压制会成功。实在不知道，1080p的视频该用什么码率压制，于是就选择5000Kbps。出来的效果很不错，不过比之前剪出来的大了1倍而已。如果我的视频源真的是1080p，两个半小时的原视频大小能达到15GB以上，估计我得用8000才行。浏览过原视频播放时的信息，基本上只有少数镜头会超过5000，所以，我选择5000已经算是比较高端的了。

问题会不断出现，但人仍能将其不断地解决掉。不是因为突然发现了什么神器，或者有什么神人给你雪中送炭。过去所做的一切累积回来的经验都是要往后走得更好更快的基础。

所有的努力都不会白费。当质变发生的时候，并不是因为运气突然间变好了，而是因为量变达到了一定程度。