【原創】Sliding Window Maximum 解法分析
這道題是lintcode上的一道題,當然leetcode上同樣有。
本題需要尋找O(N)複雜度的演算法。
解體思路比較有特點,所以容易想到參考 最小棧 的解題辦法。
但是最小棧用棧維護最小值很直觀,這道題是佇列,用什麼資料結構好呢?也許看完暴力解會有點啟發。
但是思路還是一樣的,最大的要在最前面(直接獲取結果),小的值在後面保留下來(防止之後遍歷到的時候丟失資料)。並且某值出視窗的時候需要判斷是否要修改排在最前面的值。
一。暴力解
當然直觀看,暴力求解是 O(NK)的複雜度,大體的程式碼如下:(寫的有點複雜費勁,主要當時是想通過vector構建頭尾可變動的佇列,發現STL裡其實有就放棄了)
vector<int> maxSlidingWindow(vector<int> &nums, int k) { // write your code here if (nums.empty()) return vector<int>(); vector<int> maxVec; int maxV = INT_MIN; vector<int> res; for (int i = 0; i < k && i < nums.size(); i++) {if (maxV < nums[i]) maxV = nums[i]; maxVec.push_back(nums[i]); } res.push_back(maxV); for (int i = k; i < nums.size(); i++) { maxVec.push_back(nums[i]); maxVec.erase(maxVec.begin()); if (nums[i - k] == maxV) { maxV= INT_MIN; for (int j = 0; j < maxVec.size(); j++) if (maxV < maxVec[j]) maxV = maxVec[j]; } if (nums[i] > maxV) maxV = nums[i]; res.push_back(maxV); } return res; }
二。大頂堆
這個其實思路希望通過堆的構造還控制O(1)代價獲得最大元素,複雜度O(N * logK)
三。雙向佇列
終於到它了,其實對自己來說是想提醒自己一下STL裡deque的存在。就像priority_queue一樣容易被忽略。
思路是維持一個不增序的雙向佇列,最大值在隊首(直接獲取結果)。佇列大小最多是視窗大小,由值出視窗控制。
最壞case時間複雜度為2N,所以O(N)複雜度。
vector<int> maxSlidingWindow(vector<int> &nums, int k) { // write your code here deque<int> my_deq; vector<int> res; for (int i = 0; i < nums.size(); i++) { if (i - k >= 0) { // 出佇列踢頭節點判斷 if (!my_deq.empty() && nums[i - k] == my_deq.front()) my_deq.pop_front(); }
// 入佇列踢值判斷 while (!my_deq.empty() && nums[i] > my_deq.back()) my_deq.pop_back(); my_deq.push_back(nums[i]); if (i + 1 - k >= 0) // 視窗大小滿足判斷 res.push_back(my_deq.front()); } if (k > nums.size()) res.push_back(my_deq.front()); return res; }
轉載請註明出處~ http://www.cnblogs.com/xiaoboCSer/p/4895191.html
相關推薦
【原創】Sliding Window Maximum 解法分析
這道題是lintcode上的一道題,當然leetcode上同樣有。 本題需要尋找O(N)複雜度的演算法。 解體思路比較有特點,所以容易想到參考 最小棧 的解題辦法。 但是最小棧用棧維護最小值很直觀,這道題是佇列,用什麼資料結構好呢?也許看完暴力解會有點啟發。 但是思路還是一樣的,最大的要在最前
【Leetcode】Sliding Window Maximum
題目: Given an array nums, there is a sliding window of size k which is moving from the very left of
【原創】聚類思想的分析
聚類演算法在資料探勘中經常使用,思想簡單直接。 在系統中,自己也實現過幾個聚類演算法,做針對性的優化也並無它難度。 由於其方式的簡單,開始也未對它有過深入思考。 但是,如果你想讓資料自己說話,還是離不開聚類。 因此調研了很多聚類演算法,做一些總結。 ---------------
【原創】Linux虛擬化KVM-Qemu分析(一)
# 背景 - `Read the fucking source code!` --By 魯迅 - `A picture is worth a thousand words.` --By 高爾基 說明: 1. KVM版本:5.9.1 2. QEMU版本:5.0.0 3. 工具:Source Insight
【原創】Linux虛擬化KVM-Qemu分析(二)之ARMv8虛擬化
# 背景 - `Read the fucking source code!` --By 魯迅 - `A picture is worth a thousand words.` --By 高爾基 說明: 1. KVM版本:5.9.1 2. QEMU版本:5.0.0 3. 工具:Source Insight
【原創】Linux虛擬化KVM-Qemu分析(三)之KVM原始碼(1)
# 背景 - `Read the fucking source code!` --By 魯迅 - `A picture is worth a thousand words.` --By 高爾基 說明: 1. KVM版本:5.9.1 2. QEMU版本:5.0.0 3. 工具:Source Insight
【原創】Linux虛擬化KVM-Qemu分析(四)之CPU虛擬化(2)
# 背景 - `Read the fucking source code!` --By 魯迅 - `A picture is worth a thousand words.` --By 高爾基 說明: 1. KVM版本:5.9.1 2. QEMU版本:5.0.0 3. 工具:Source Insight
【原創】Linux虛擬化KVM-Qemu分析(五)之記憶體虛擬化
# 背景 - `Read the fucking source code!` --By 魯迅 - `A picture is worth a thousand words.` --By 高爾基 說明: 1. KVM版本:5.9.1 2. QEMU版本:5.0.0 3. 工具:Source Insight
【原創】Linux虛擬化KVM-Qemu分析(六)之中斷虛擬化
# 背景 - `Read the fucking source code!` --By 魯迅 - `A picture is worth a thousand words.` --By 高爾基 說明: 1. KVM版本:5.9.1 2. QEMU版本:5.0.0 3. 工具:Source Insight
【原創】Linux虛擬化KVM-Qemu分析(七)之timer虛擬化
# 背景 - `Read the fucking source code!` --By 魯迅 - `A picture is worth a thousand words.` --By 高爾基 說明: 1. KVM版本:5.9.1 2. QEMU版本:5.0.0 3. 工具:Source Insight
【原創】Linux PCI驅動框架分析(二)
# 背 景 - `Read the fucking source code!` --By 魯迅 - `A picture is worth a thousand words.` --By 高爾基 說明: 1. Kernel版本:4.14 2. ARM64處理器 3. 使用工具:Source Insight
【原創】Linux PCI驅動框架分析(三)
# 背 景 - `Read the fucking source code!` --By 魯迅 - `A picture is worth a thousand words.` --By 高爾基 說明: 1. Kernel版本:4.14 2. ARM64處理器 3. 使用工具:Source Insight
【原創】Linux虛擬化KVM-Qemu分析(八)之virtio初探
# 背景 - `Read the fucking source code!` --By 魯迅 - `A picture is worth a thousand words.` --By 高爾基 說明: 1. KVM版本:5.9.1 2. QEMU版本:5.0.0 3. 工具:Source Insight
【原創】Linux虛擬化KVM-Qemu分析(九)之virtio裝置
# 背景 - `Read the fucking source code!` --By 魯迅 - `A picture is worth a thousand words.` --By 高爾基 說明: 1. KVM版本:5.9.1 2. QEMU版本:5.0.0 3. 工具:Source Insight
【原創】Linux虛擬化KVM-Qemu分析(十)之virtio驅動
# 背景 - `Read the fucking source code!` --By 魯迅 - `A picture is worth a thousand words.` --By 高爾基 說明: 1. KVM版本:5.9.1 2. QEMU版本:5.0.0 3. 工具:Source Insight
【原創】Linux虛擬化KVM-Qemu分析(十一)之virtqueue
# 背景 - `Read the fucking source code!` --By 魯迅 - `A picture is worth a thousand words.` --By 高爾基 說明: 1. KVM版本:5.9.1 2. QEMU版本:5.0.0 3. 工具:Source Insight
【原創】源碼角度分析Android的消息機制系列(一)——Android消息機制概述
run 權限 開發 等待 通過 讀取 概述 走了 color ι 版權聲明:本文為博主原創文章,未經博主允許不得轉載。 1.為什麽需要Android的消息機制 因為Android系統不允許在子線程中去訪問UI,即Android系統不允許在子線程中更新UI。 為什麽不允許
【原創】源碼角度分析Android的消息機制系列(二)——ThreadLocal的工作過程
機制 simple hand 這就是 數據存儲 read etc lena 並且 ι 版權聲明:本文為博主原創文章,未經博主允許不得轉載。 在上一篇文章中,我們已經提到了ThreadLocal,它並非線程,而是在線程中存儲數據用的。數據存儲以後,只能在指定的線程中獲取到數據
【原創】源碼角度分析Android的消息機制系列(三)——ThreadLocal的工作原理
沒有 cit gen 管理 pre 靜態 bsp 允許 clas ι 版權聲明:本文為博主原創文章,未經博主允許不得轉載。 先看Android源碼(API24)中對ThreadLocal的定義: public class ThreadLocal<T>
【原創】源碼角度分析Android的消息機制系列(四)——MessageQueue的工作原理
enc 容易 工作 trie oss 當前 within which ptime ι 版權聲明:本文為博主原創文章,未經博主允許不得轉載。 MessageQueue,主要包含2個操作:插入和讀取。讀取操作會伴隨著刪除操作,插入和讀取對應的方法分別為enqueueMes