水木社区手机版
首页
|版面-C++程序设计语言(CPlusPlus)|
新版wap站已上线
返回
首页
|
上页
|
2/2
|
转到
主题:数字华容道程序速度快速下降,比C#慢几十倍
30楼
|
finlab
|
2021-12-04 12:07:18
|
展开
开始试了下,要保证最短路径会极大扩大搜查范围,在4x4的情况下,会内存不足
所以放弃A*。
后面的优化是针对问题加入剪枝规则
【 在 here080 的大作中提到: 】
: 这里有A*算法?我读书少你别骗我。
: 【 在 ArchLinux (a lightweight and flexible distribution) 的大作中提到: 】
: : 标 题: Re: 数字华容道程序速度快速下降,比C#慢几十倍
: ....................
--
FROM 117.136.0.*
35楼
|
finlab
|
2021-12-05 07:58:10
|
展开
我贴的答案是后来优化过的。
在主循环中,记录全局最优节点,也就是score最小的。
然后
if (node->gen - best->gen >15 && node->score > best->score)
continue;
就是如果比最优节点多走了15步,还不如最优解点,就不再搜索这个分支。
这时候只要52步就能完成。
我把剪枝额步数跳到14, 就反而要60步。
如果再少, 可能就把正确的路径都剪掉了, 出不来答案了。
【 在 here080 的大作中提到: 】
: 为啥你算出来才60步?我把你的程序用C++重写了一下,算出来要100步……
: 这个结果是秒出的,但是如果我把搜索深度限定在80以内,那我搜了几千万个结点也出不了结果。
: Start Searching =========================
: ...................
--
FROM 123.112.64.*
37楼
|
finlab
|
2021-12-05 08:26:16
|
展开
我确实是试了几次,试出来这个数字,
不过实际上人工求解的时候有固定的解法。 就是固定一行,再摆下一行。
在当前局势下,再多摆好一个,花费的步骤上限是可以确定的。 不过手工我也不熟,不好确定。
还有一个优化思路,就是参照人工,判断第一行摆好了,就做个标记,以后不再动。然后是第二行。
但最后两行要一起完成。
这样应该可以更快找到一个解法,但是用的步数会多一些。
【 在 here080 的大作中提到: 】
: 你这个优化方式太看运气了吧。如果最优节点恰好是个死胡同,那不就卡死所有正确答案了?
: 你选的这个15步标准,是对这一个初始条件有用吧?换一个初始条件是不是就有可能不行了?
:
--
FROM 123.112.64.*
40楼
|
finlab
|
2021-12-05 09:55:04
|
展开
是啊, 中间试了一下, 发现不好又去掉了。 36步的结果已经挺不错了,应该差不多是全局最优解了。
我之前使用 r+k*gen, 不过为了保证最优解,k设的比较大,短时间没法出结果,就放弃了。
【 在 here080 的大作中提到: 】
: 哈哈,我发现了,你的那个打分函数是个坑啊。那个乘以3完全把事情搞砸了。
: 我把那个乘以3去掉,直接就搜出了58步的解。
: 再然后我再优化了一下打分函数,用分数和步数的和作为新的分数,你猜怎么着?36步:
: ...................
--
FROM 123.112.64.*
44楼
|
finlab
|
2021-12-06 13:41:08
|
展开
不错,回头看看
【 在 vwx 的大作中提到: 】
: 对比
http://simonsays-tw.com/web/Klotski/game/klotskiDemo.html
看看?
: 【 在 finlab (挨踢卢瑟) 的大作中提到: 】
: : 是啊, 中间试了一下, 发现不好又去掉了。 36步的结果已经挺不错了,应该差不多是全局最优解了。
: ....................
--
FROM 117.136.0.*
首页
|
上页
|
2/2
|
转到
选择讨论区
首页
|
分区
|
热推
BYR-Team
©
2010.
KBS Dev-Team
©
2011
登录完整版