本文探讨了Vijos中的渡河问题，指出直接搜索方法因询问过多而不可行，建议预先计算答案数组。作者尝试了SPFA算法，遇到空间和时间复杂度挑战，并分享了洪水填充的解法遇到的问题。最终，作者提出了一种在建图过程中计算答案数组的优化方法，但无法证明其正确性，并邀请读者帮助证明。
题目在这里：Vijos 渡河
这题最直接的想法就是搜索，但是因为询问数过大所以无法直接针对每一个询问去搜索结果，所以应该算出答案数组，之后针对每个询问直接查询答案。
但是问题又出来了，如何快速的计算答案数组呢？
在Vijos上找到了几种做法，大概有以下几种：
将边界上的点的答案值设为0，然后SPFA，共有n*n个点，每个点可以向八个方向扩展，从1到0的时候答案加1，各种修改拿了五十分，不知道怎样才能改的更好，所以换了一种思路。
基于洪水填充的几种解法，首先为所有节点染色，然后接下来：
建图，然后SPFA，过了6个点，但是碰上了几个问题，假如使用邻接矩阵，128M的空间开不下，假如使用邻接表，STL中的map判重又会带来很大的开销（只得了50分），所以放弃了这种解法。
还有一种解法，从网上看过来的，贴一下原文链接，原文讲的很好理解，这里就不再多说了。
我本来打算采用上一种方法，但是之前建图时曾经加过一句优化，当附近有与该节点不同颜色的节点时才对该节点进行扩展，于是我就想，可不可以在建图时计算出答案数组呢？试验了一下，发现还真的可以，而且速度还挺快：我的提交记录
先贴代码：
#include <bits/stdc++.h>
const int color_cnt = 200000;
int n, k
最低0.47元/天 解锁文章
扫一扫
1141
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
