循序渐进
我觉得必定把我搞死的筛选词汇表里的二锁三锁单词,居然不怎么费劲就做出来了。
第一次,我在里面用了一个很傻的循环,其实根本就没有必要。可以不用自己的循环就千万不要在词汇表搜索时多用,但我的第一次尝试并不是毫无意义的,,因为已经能得出结果了,而且结果是对的,虽然非常慢,慢到我无法忍受程序继续运行下去。然后,我把要搜索的东西全部都丢到二分法搜索里面,循环只剩下一个必须做的,因为要把词汇表过一遍。第一次做二词互锁的时候,我在一个循环里套了两个if,然后我又把那两个if做成平行的,其实也就是把两个本来嵌套起来的条件用一个and连接起来,很多时候我们都需要这么干。因为除了要二锁,还要考虑三锁,显然人肉去做这些判断,写一大堆一模一样的东西实在太无聊,所以我又自定义了一个新函数,把需要判断的东西全部都丢掉里面,最终返回True或者False。其实,之前我已经考虑过要直接这么干,但因为前天在做搜索回文词的时候我已经得出了回文词的索引,所以直接用就好。我个人觉得,效果是差不多的。
在搜索互锁单词的时候,输出时我用的是字符串的变体。因为二分法搜索被我丢到了一个多条件复合的判断函数里面,所以返回的东西,只有True与False。如果全部都是True的话,就意味着那些单词辩题应该全部都OK没问题。也正是因为输出的东西已经没有索引返回,所以结果我直接使用单词的变体表示。这样的效果很惊人。之前我套用了两个if,然后我写了一个判断函数把条件都含进去了,这样的改进让脚本的运行时间缩短了一半。如果一开始我没有见过两秒多的那个效果,我肯定不会为一秒多的那个惊叹。这是我一步一步琢磨出来了的。
首先是实现得出结果,然后是对语句进行重构,接下要让这个程序适用于二、三词互锁,所以我做的东西是泛化。一开始我把所有判断都写在主程序里,后来我又把它分出一个函数,也就是封装。无意之中,我在执行着Think Python第四章里说到的开发方法:写小程序、封装、泛化、重构。无论是大程序还是小程序,其实都会经历这些。我会从一些我最熟悉的东西开始实现功能。但是我最熟悉的东西不意味着效率一定会高。循环再循环以后,得出一个词都要好几秒时间,实在让人难以接受,尤其当这个词到下个时中间要相隔几秒甚至是十几秒才有反应的时候。这就逼迫着我一定要改进,不同的语句能实现同样的功能,但是它们之间的效率是非常不一样。
大家都在用着二分法的思路去搜索,但是我的脚本就比参考答案快接近30倍。单词一蹦出来,我就知道我一定会比参考答案快。因为我的程序里,单词是噼里啪啦完全没有停顿就全部出来的,而参考答案的词语出来的时候虽然不会一直有,但总有一些顿卡现象,那相对于我的程序来说,就像是慢镜头。
我从来没有想过自己能做得比参考答案还要好,或许他们要做到的并不是有多快。相比于不是二分法的搜索,二分法已经很快了。他们想做到的,大概是用最简练的语言,用模块化的方法实现功能,效率倒不是他们最看重的,因为做搜索词汇表这种事在列表里完成肯定比不上直接上字典。但是,如果不曾在列表里面死去活来,又怎么会体验到字典的神奇。
无论我的二分法搜索写得多么高效,肯定还是不如字典的。我体验过用词典进行斐波那契常数计算。当要计算第40个的时候,一般的递归和字典递归简直就是天渊之别。
如果不曾经历,不曾被整得很惨,我大概就不能说自己真学会了那个东西。
还没有评论