1. 程式人生 > >【原創】Sliding Window Maximum 解法分析

【原創】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)複雜度的演算法。 解體思路比較有特點,所以容易想到參考 最小棧 的解題辦法。 但是最小棧用棧維護最小值很直觀,這道題是佇列,用什麼資料結構好呢?也許看完暴力解會有點啟發。 但是思路還是一樣的,最大的要在最前

LeetcodeSliding 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