LeetCode 11 水池蓄水问题
今天给大家分享的是一道LeetCode中等难度的题,难度不大,但是解法蛮有意思。我们一起来看题目:
Link
Difficulty
Medium
题意
给定n个非负整数,表示水库当中隔板的高度。每两块隔板之间的距离为1,当下要从n个隔板当中选出两个,在其中注水,并且要使得容纳的水尽量多。请问最多能容纳多少水?可以忽略隔板的宽度,将水库看成是正规的长方体。
样例:
Input: [1,8,6,2,5,4,8,3,7]
Output: 49
题解:
由于水库可以看成是正规的长方体,所以水库的体积可以简化为横截面积。也就是说我们要选择两个隔板,使得隔板之间围成的矩形面积最大。
首先思考暴力求解,我们只需要枚举矩形的两边,两边有了之后,矩形的长,也就是两边之间的距离,矩形的宽就是两边的较小值,所以复杂度是\(O(n^2)\)。
这样写的代码也很简单,只有几行:
for i in range(n):
for j in range(i+1, n):
ret = max(ret, (j-i) * min(a[i], a[j]))
return ret
我们来思考怎么优化,显然大部分情况下\(O(n^2)\)的算法往往都不是最优解。考虑一个很简单的问题,为什么取最左边和最右边的隔板不行呢?这样不是矩形的长最长么?
不行的原因很简单,因为矩形的长最长的时候,但是矩形的宽不一定很宽。有可能这样的宽很短,就像上面图中展示的一样。如果这时候的结果不是最佳值,那么最佳答案的长一定小于n。如果我们用i和j指代最优解的左右两边的下标,那么显然有1 <= i < j <= n。
也就是说i, j 的位置应该在1, n的内部。我们可以想象一开始的时候i指向1,j指向n,然后逐渐移动到了最优解的位置。我们应该移动i和j,但是每次应该怎么移动呢?究竟是移动i还是移动j呢?
其实稍微想一下就能想到答案,应该移动i和j两个当中隔板比较短的那个。假设i的隔板长度小于j,即使移动i,即使碰到了更长的隔板,面积也不会变大,因为j的长度并没有变,它依旧是短板。所以我们只有移动其中较短的那个,才有让矩形面积变大的可能。
如果i和j的长度一样怎么办?答案是随便移动哪个都一样,有些同学可能还有顾虑。我们不妨使用一下我们之前介绍贪心算法的时候提到的均等假设法。有忘记的同学可以点击下方的链接回顾一下:
我们来举个例子,假设水库隔板的情况是:
5 10 X .. X 4 5
我们一开始的时候i指向左边的5,j指向右边的5,这时候i和j相等。如果移动左边的i,到10,面积并没有变大。接下来会一直移动右边的j,直到j遇到大于10的为止。并不会出现影响正确结果的情况。如果移动右边的j呢?其实也是一样的,因为如果j没有遇到大于5的元素,无论左边指向什么地方,面积都不会增大。当j遇到5以上的数的时候,必然会移动左边的i,一样可能增大面积。
5 10 X .. X 11 5
我们再看这个例子,如果10和11围成的结果是正确答案,那么不论先移动i还是先移动j都是一样的。本质上来说,如果矩形面积要增大,必须要i和j同时指向比当前更大的元素才行,所以先移动哪个并不会影响结果。
这样一来,写代码就方便了,我们可以人为规定如果出现相等,就移动i。写出来代码如下:
i, j = 0, n-1
ret = 0
while i < j:
ret = max(ret, (j - i) * min(a[i], a[j]))
if a[i] <= a[j]:
i += 1
else:
j -= 1
return ret
这道题既可以认为是贪心算法,也可以认为是两指针维护区间的问题。不论怎么样解释,写出来的代码是一样的,我个人觉得还是很巧妙的,很适合初学者练手,并且难度也不是很大。希望大家都能领会。
今天的文章就到这里,如果觉得有所收获,请顺手点个关注吧,你们的支持是我最大的动力。
LeetCode 11 水池蓄水问题的更多相关文章
- leetcode 最大水池
leetcode 11题 水池最大容积 题目描述 给定 n 个非负整数 a1,a2,...,an,每个数代表坐标中的一个点 (i, ai) .在坐标内画 n 条垂直线,垂直线 i 的两个端点分别为 ( ...
- LeetCode 11. Container With Most Water (装最多水的容器)
Given n non-negative integers a1, a2, ..., an, where each represents a point at coordinate (i, ai). ...
- [LeetCode] 11. Container With Most Water 装最多水的容器
Given n non-negative integers a1, a2, ..., an , where each represents a point at coordinate (i, ai). ...
- Java实现 LeetCode 11 盛最多水的容器
11. 盛最多水的容器 给定 n 个非负整数 a1,a2,-,an,每个数代表坐标中的一个点 (i, ai) .在坐标内画 n 条垂直线,垂直线 i 的两个端点分别为 (i, ai) 和 (i, 0) ...
- 如何装最多的水? — leetcode 11. Container With Most Water
炎炎夏日,还是呆在空调房里切切题吧. Container With Most Water,题意其实有点噱头,简化下就是,给一个数组,恩,就叫 height 吧,从中任选两项 i 和 j(i <= ...
- LeetCode 11
Container With Most Water Given n non-negative integers a1, a2, ..., an, where each represents a poi ...
- LeetCode——11. Container With Most Water
一.题目链接:https://leetcode.com/problems/container-with-most-water/ 二.题目大意: 给定n个非负整数a1,a2....an:其中每一个整数对 ...
- LeetCode 11 Container With Most Water(分支判断问题)
题目链接 https://leetcode.com/problems/container-with-most-water/?tab=Description Problem: 已知n条垂直于x轴的线 ...
- LeetCode(11)题解: Container With Most Water
https://leetcode.com/problems/container-with-most-water/ 题目: Given n non-negative integers a1, a2, . ...
随机推荐
- 阿里云 CentOS8 Repo
# CentOS-Base.repo # # The mirror system uses the connecting IP address of the client and the # upda ...
- 非GUI-Qt程序运行后显示Console(简单好用:在pro文件中加入: CONFIG += console)
----我的生活,我的点点滴滴!! 有很多时候,我们在程序中添加了好Debug信息,方便程序在运行期间打印出一些我们需要的信息或者,想用他来显示一些必要信息时, 那么console就太重要了,曾几何时 ...
- Javascript事件系统
本文内容 事件基础 事件监听方式 事件默认行为 事件冒泡与事件捕获 事件绑定与事件委托 事件基础 注意:本文不会深入探究Javascript的事件循环. 提到事件,相信每位Javascript开发者都 ...
- java 使用 apoi 更新 ppt 中图表的数据
本文源码: 1. https://github.com/zhongchengyi/zhongcy.demos/tree/master/apoi-ppt-chart 2. 在第5节也有核心源码 1 ...
- cs服务器搭建(cobaltstrike)
linux服务器中安装 1.因为cs这个工具需要用到Java环境,新装的linux系统没有Java环境,所以这里先装一下java环境 yum install -y java-1.8.0-openjdk ...
- $bzoj4152\ The\ Captain$ 最短路
正解:最短路+优化连边 解题报告: 传送门$w$ 这种优化连边啥的真的好妙噢$QwQ$ 首先显然离散化下不说$QwQ$.然后对所有横坐标纵坐标分别建点,相邻两横坐标点相连,边权为离散前的坐标差.纵坐标 ...
- 使用这些idea插件让开发效率提高5倍
idea 有很多非常好用的插件,用好了这些插件能够极大的提高开发效率 插件用的好,bug 就追不上了我
- Spring 配置内容外部化
- HBase学习笔记(四)—— 架构模型
在逻辑上,HBase 的数据模型同关系型数据库很类似,数据存储在一张表中,有行有列. 但从 HBase 的底层物理存储结构(K-V)来看,HBase 更像是一个 multi-dimensional m ...
- 大白话带你梳理一下Dubbo的那些事儿
首先声明,本文并不是什么代码实战类型的文章,适合于想对dubbo有更加全面认识的读者阅读,文章不会过于深奥,只是将一系列的知识点串通起来,帮助读者温故而知新. RPC服务的介绍 相信有过一些分布式开发 ...