LeetCode 403. Frog Jump 题解

本文介绍了LeetCode 403题《Frog Jump》的解题思路,主要采用动态规划的方法。题目要求计算青蛙能否通过每次跳跃1、2或3个单位到达河对岸的最后一块石头。文章分析了动态规划的状态转移方程,并讨论了不同搜索顺序对算法效率的影响,指出DFS在某些情况下可能更快,但DP避免了重复计算。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

LeetCode 403. Frog Jump 题解

题目描述


A frog is crossing a river. The river is divided into x units and at each unit there may or may not exist a stone. The frog can jump on a stone, but it must not jump into the water.

Given a list of stones’ positions (in units) in sorted ascending order, determine if the frog is able to cross the river by landing on the last stone. Initially, the frog is on the first stone and assume the first jump must be 1 unit.

If the frog’s last jump was k units, then its next jump must be either k - 1, k, or k + 1 units. Note that the frog can only jump in the forward direction.

Note:

The number of stones is ≥ 2 and is < 1,100.
Each stone’s position will be a non-negative integer < 231.
The first stone’s position is always 0.


Example 1:
[0,1,3,5,6,8,12,17]

There are a total of 8 stones.
The first stone at the 0th unit, second stone at the 1st unit,
third stone at the 3rd unit, and so on…
The last stone at the 17th unit.
Return true. The frog can jump to the last stone by jumping
1 unit to the 2nd stone, then 2 units to the 3rd stone, then
2 units to the 4th stone, then 3 units to the 6th stone,
4 units to the 7th stone, and 5 units to the 8th stone.


Example 2:

[0,1,2,3,4,8,9,11]

Return false. There is no way to jump to the last stone as
the gap between the 5th and 6th stone is too large.


题目分析

这道题大意就是一个过河问题。 从step=1 开始, 每次只能有 abs(stepstep)1. 而且不能往回跳。
没有多想, 直接用的DP做的。 发现效果还不错。

具体就是用一个canReach数组, 记录是否能够到达某个stones[i].仅仅这样还不够, 要记录完整状态, 还得再加一个维度, 用于描述 是否能跳 k 步到达stones[i]

这就是整个动规了。完全没有其他东西。只是因为是道 Hard,所以写写。 感觉像是Medium

状态转移方程就是下面代码中两层循环里面那句话, 相信是很好懂的吧。无非就是把题目约束用代码翻译了一遍~。~

代码如下:

class Solution {
public:
    bool canCross(vector<int>& stones) {
        vector< vector<bool> > canReach(stones.size());
        for (int i = 0; i < canReach.size(); ++i) {
            canReach[i].resize(stones.size() + 1);
        }
        canReach[0][0] = true;

        for (int i = 1; i < stones.size(); ++i) {
            for (int j = i - 1; j >= 0; --j) {
                if (stones[i] - stones[j] >= stones.size()) break;
                if(canReach[j][stones[i] - stones[j] - 1] || canReach[j][stones[i] - stones[j] + 1] || canReach[j][stones[i] - stones[j]]) {
                    canReach[i][stones[i] - stones[j]] = true;
                }
            }
        }

        for (int i = 0; i < stones.size(); ++i) {
            if (canReach[stones.size() - 1][i]) return true;
        }
        return false;
    }
};

其他细节

既然这篇在前面基本没写什么内容, 就在这里多写一点吧。感觉还是挺重要的。
1. 这并不是唯一做法。 甚至运行时比DFS还要高, 但是DFS肯定有其局限性的。 看到discuss里面有人说用JAVA+DFS跑出很好的情况, 大致看了一下其做法。首先要肯定的是, DFS的做法耗时肯定要更少是真的。 原因在于, DFS优先往大了跳, 指不定就还真跳到了就赚到了。 即使不济总搜索次数还是和DP相同。 而DP是稳定每次都会把状态全部计算了一遍。 虽然避免了重复计算, 但是可能产生无用计算。

  1. 最原先我AC的DP代码其实和上面那个不太一样, 贴出来对比:
        for (int i = 1; i < stones.size(); ++i) {
            for (int j = 0; j < i; ++j) {
                if (stones[i] - stones[j] >= stones.size()) continue;
                if(canReach[j][stones[i] - stones[j] - 1] || canReach[j][stones[i] - stones[j] + 1] || canReach[j][stones[i] - stones[j]]) {
                    canReach[i][stones[i] - stones[j]] = true;
                }
            }
        }

之后我做了两次修改, 有促进的那次在上面代码中已经体现了: 换了一下搜索顺序, 可以及时避免无用计算。 还有一次, 我把状态转移的那行代码写成了这样:

      canReach[i][stones[i] - stones[j]] = (canReach[j][stones[i] - stones[j] - 1] || 
      canReach[j][stones[i] - stones[j] + 1] || canReach[j][stones[i] - stones[j]]);

结果耗时反而比使用if多了不少, 以后注意避免这种写法。 (看来果然访问内存在执行速度上是最慢的啊。。。)

The End.

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值