Codeforces - 598D Igor In the Museum
Codeforces - 598D Igor In the Museum 解题报告,带记忆的深度优先搜索
前文曾提到过解决一个算法问题,大概可以划分为三个阶段。第一阶段是算法设计,即人脑准确无误理解算法问题,并设计算法,这一阶段属于模型在思维上的构建。第二阶段是算法实施,即程序员用自己钟爱的语言对思维上的模型进行现实化,依靠计算机来获得结果,这一阶段属于模型在代码上的构建。最后一阶段,即计算机执行程序员给定的命令,并返回其所希望的结果,这一阶段属于模型在计算机硬件上的构建。为了保证最终输出的正确性,这三个阶段不能发生任何可预见或者意想不到的错误。算法运行中的精度问题在前文中已有所描述,这一次我们来谈谈算法实施阶段,并以Codeforces 598D来说明如何写更精简的代码。
问题描述
.
表示通道, *
表示一堵墙,每一堵墙的两面都挂着画。然后问给定Igor的起始位置,他最多能够观赏多少副画。
初步思考
分析
Igor只能在连通的通道里移动,因此问最多能够观赏多少幅画,那么首先先确定Igor可移动的连通区域,然后确定其边界,最后对每个边界,确定可看到的画作的数目再加和即可。确定连通空间的范围可以转化成深度优先搜索,既以当前位置为搜索树的根节点,然后其上下左右连接点为四个子节点。若子节点为墙,则搜索完毕;若子节点为已搜索过的通道,则毋需再次搜索;若子节点为通道且未搜索,那么利用同样的法则递归的搜索。
代码
由此,我们可以得到如下的算法。
1: #%% Version 1: given (x,y) search valide empty regions and calculate max_pic_num |
然而,这段代码并没有通过Codeforces的测试,在第10号测试数据上超时了。那么有什么可以优化的地方么?
生成缓存
分析
注意到这道题的测试数据里每一次都要计算若干起始点下最多可看到的画作数量,因此有可能出现某些起始点实际上归属于同一个连通区域。而先前的算法针对每一个新的起始点,都进行新的计算,因而可能会出现大量的重复计算。因此,我们可以有如下的第一个算法优化思路,即进行缓存,
代码
相应的代码如下所示
1: #%% Version 4: based on Version 1, but make indexing for already retrieved information |
然而即使这样操作了,这段算法还是卡在了第11号测试数据上(后来发现是 Python3
的效率缘故,换做 C++
后,一次AC)。
全方位的深度优先搜索
分析
回到正题,那么这道题对我们算法实施有什么借鉴意义呢?回想前面的分析,我们主要有两个想法
- 通过深度优先搜索确定连通区域,然后确定边界,并计算可观赏到的画作数量。
- 解决一个初始点问题,便同时解决了以该连通区域其他点为初始点的问题。因此对已解决的初始点问题的连通区域也进行缓存标记。
也就是说我们程序的输出有两个,一是可观赏到的最多画作数量,二是起始点的连通区域。那么能否再进行深度优先搜索的同时,兼顾这两个任务,以减少代码数量呢?前述算法在进行深度优先搜索时,仅仅把递归函数当做一个过程,而并无返回值。实际上,当我们搜索到一个节点为墙时,即意味着我们看到了一副画,返回1;如果搜索到通道节点时,那么什么也没看到,返回0。同时,再搜索的过程,我们便可以标记出这些连通点的区域代号。这给了我们第二个算法优化思路,
代码
相应的代码如下
1: #%% Version 5: inspired by 14440455 |
最终通过测试的是如下 C++
代码,
1: //version 1 |
代码量是不是比之前要少多了啊~
反思
本题目其实就是深度优先搜索的变种,并且给了我如下两个经验。
- 如果日后有需要解决类似问题的需求,那么最好现在做缓存,以减少日后的重复计算。【恰逢AlphaGo 3:0获胜人机大战,值得一提的是这次AlphaGo的大量自我对弈以及棋谱学习,其实也是一种缓存】
- 更高效的利用过程主导的递归函数来更新所需要的输出值
本作品采用知识共享署名 2.5 中国大陆许可协议进行许可。欢迎转载,但请注明来自Mount Greenwicher的文章《Codeforces - 598D Igor In the Museum》,并保持转载后文章内容的完整与无歧义。本人保留所有版权相关权利。