স্লাইডিং উইন্ডো মিডিয়ান গণনার জন্য অনানুষ্ঠানিক অ্যালগরিদম

আমার চলমান মিডিয়ান গণনা করা দরকার:

ইনপুট: , , ভেক্টর । $n$ $k$ $(x_1, x_2, \dotsc, x_n)$
আউটপুট: ভেক্টর , যেখানে হ'ল । $(y_1, y_2, \dotsc, y_{n-k+1})$ $y_i$ $(x_i, x_{i+1}, \dotsc, x_{i+k-1})$

(আনুমানিক সাথে কোনও প্রতারণা নয়; আমি সঠিক সমাধান পেতে চাই উপাদানসমূহ বৃহত্তর পূর্ণসংখ্যা)) $x_i$

একটি তুচ্ছ অ্যালগরিদম আছে যা সাইজের এর অনুসন্ধান গাছ বজায় রাখে ; মোট চলমান সময় হ'ল । (এখানে একটি "অনুসন্ধান ট্রি" কিছু কার্যকর ডেটা স্ট্রাকচারকে বোঝায় যা লগারিদমিক সময়ে সন্নিবেশ, মুছে ফেলা এবং মিডিয়ান কোয়েরিকে সমর্থন করে)) $k$ $O(n \log k)$

তবে এটি আমার কাছে কিছুটা বোকা মনে হচ্ছে। আমরা কার্যকরভাবে শিখতে হবে সব আকারের সকল উইন্ডো মধ্যে অর্ডার পরিসংখ্যান , শুধু মধ্যমা। তদুপরি, এটি অনুশীলনে খুব আকর্ষণীয় নয়, বিশেষত কে বড় হলে (বড় সন্ধানের গাছগুলি ধীরে ধীরে থাকে, মেমরির ব্যবহারে ওভারহেড অপ্রয়োজনীয় হয়, ক্যাশে-দক্ষতা প্রায়শই দুর্বল থাকে ইত্যাদি)। $k$ $k$

আমরা কি যথেষ্ট পরিমাণে আরও ভাল করতে পারি?

কোন নিম্ন সীমানা আছে (উদাহরণস্বরূপ, তুলনা মডেল জন্য তুচ্ছ আলগোরিদম asympototically অনুকূল)?

সম্পাদনা করুন: তুলনা মডেলটির জন্য দাউদ এপস্টিন একটি দুর্দান্ত নীচে দিয়েছিলেন! আমি ভাবছি তবুও তুচ্ছ অ্যালগরিদমের চেয়ে কিছুটা চালাক কিছু করা সম্ভব কিনা?

উদাহরণস্বরূপ, আমরা এই লাইনগুলি বরাবর কিছু করতে পারি: ইনপুট ভেক্টর আকারের কিছু অংশে ভাগ করুন ; প্রতিটি অংশকে বাছাই করুন (প্রতিটি উপাদানগুলির মূল অবস্থানগুলি লক্ষ্য রাখছেন); এবং তারপরে কোনও সহায়ক ডেটা স্ট্রাকচার ছাড়াই চলমান মিডিয়েনসকে দক্ষতার সাথে খুঁজে পেতে টুকরোড়া সাজানো ভেক্টর ব্যবহার করবেন? অবশ্যই এটি এখনও , তবে অনুশীলন অনুসারে অ্যারে বাছাই করা অনুসন্ধানের গাছগুলি রক্ষণাবেক্ষণের চেয়ে অনেক দ্রুত হতে পারে। $k$ $O(n \log k)$

সম্পাদনা 2: সা Saeedদ অনুসন্ধানের ক্রিয়াকলাপগুলির চেয়ে বাছাই করা কেন দ্রুত বলে মনে করি তার কয়েকটি কারণ দেখতে চেয়েছিলেন। , জন্য এখানে খুব দ্রুত মানদণ্ড রয়েছে : $k = 10^7$ $n = 10^8$

S 8s: প্রতিটি উপাদানগুলির সাথে ভেক্টর বাছাই করা $n/k$ $k$
≈ 10s: উপাদানগুলির সাথে একটি ভেক্টর বাছাই করা $n$
≈ 80s: সন্নিবেশ & আকারের একটি হ্যাশ টেবিল মুছে $n$ $k$
≈ 390s: সন্নিবেশ & আকারের একটি সুষম অনুসন্ধান গাছে মুছে $n$ $k$

হ্যাশ টেবিলটি কেবল তুলনার জন্য রয়েছে; এটি এই অ্যাপ্লিকেশনটিতে সরাসরি ব্যবহারের নয়।

সংক্ষেপে, ভারসাম্যপূর্ণ অনুসন্ধান ট্রি ক্রিয়াকলাপগুলি বাছাইয়ের পারফরম্যান্সে আমাদের প্রায় 50 টি পার্থক্য রয়েছে। এবং আমরা বাড়িয়ে দিলে জিনিসগুলি আরও খারাপ হয়ে যায় । $k$

(প্রযুক্তিগত বিবরণ: ডেটা = এলোমেলো 32-বিট পূর্ণসংখ্যা। কম্পিউটার = একটি আদর্শ আধুনিক ল্যাপটপ। স্ট্যান্ডার্ড লাইব্রেরি রুটিনগুলি (স্ট্যান্ড :: সাজান) এবং ডেটা স্ট্রাকচার (স্টাড :: মাল্টিসেট, স্টেড ::) ব্যবহার করে পরীক্ষার কোডটি সি ++ তে লেখা হয়েছিল was আনসোর্টড_মলিটসেট) আমি দুটি পৃথক সি ++ কম্পাইলার (জিসিসি এবং ক্ল্যাং) এবং স্ট্যান্ডার্ড লাইব্রেরির দুটি পৃথক বাস্তবায়ন (libstdc ++ এবং libc ++) ব্যবহার করেছি ditionতিহ্যগতভাবে, std :: মাল্টিসেটটি একটি অত্যন্ত অনুকূলিত লাল-কালো গাছ হিসাবে প্রয়োগ করা হয়েছে))

ds.algorithms ds.data-structures lower-bounds

— জুক্কা সুমেলা
সূত্র

আমি মনে করি না আপনি

উন্নতি করতে সক্ষম হবেন । কারণ, যদি আপনি একটি উইন্ডোতে তাকান

, আপনি

কোনও সংখ্যার বাইরে যেতে পারবেন না

n l o g k

$nlogk$

x_{t}, . . ., x_{t + k - 1}

$x_t,...,x_{t+k-1}$

ভবিষ্যতের উইন্ডোর মিডিয়ান হওয়ার থেকে। এর অর্থ হ'ল যে কোনও সময় আপনাকে কোনওডেটা স্ট্রাকচারেকমপক্ষেপূর্ণসংখ্যার রাখতে হবে এবং লগ সময়ের চেয়ে কম আপডেট হবে বলে মনে হয় না।

x_{t + \frac{k}{2}}, . . ., x_{t + k - 1}

$x_{t+\frac{k}{2}},...,x_{t+k-1}$

\frac{k}{2}

$\frac{k}{2}$

— আরবি

আমাকে তোমার তুচ্ছ অ্যালগরিদম হবে বলে মনে হয়

না

, আমি ভুল বুঝে ভাবেন কিছু নই? এবং আমি মনে করি এর কারণে আপনার বড়

নিয়ে সমস্যা আছে , অন্যথায় লোগারিদমিক ফ্যাক্টর ব্যবহারিক প্রয়োগগুলিতে কিছুই নয়, এছাড়াও এই অ্যালগরিদমে কোনও বড় লুকানো ধ্রুবক নেই।

O ((n - k) \cdot k \cdot \log k)

$O((n-k)\cdot k \cdot \log k)$

O (n \log k)

$O(n \log k)$

k

$k$

— Saeed

@ সাeedদ: তুচ্ছ অ্যালগরিদমে আপনি একের পর এক উপাদান প্রক্রিয়া করেন; ধাপে

আপনি যোগ

অনুসন্ধান বৃক্ষ এবং (যদি

) আপনার কাছে অপসারণ

অনুসন্ধান গাছ থেকে। এটি

পদক্ষেপ, যার প্রত্যেকটিতে

সময় লাগে ।

i

$i$

x_{i}

$x_i$

i > k

$i > k$

x_{i - k}

$x_{i-k}$

n

$n$

O (\log k)

$O(\log k)$

— Jukka Suomela

সুতরাং আপনার অর্থ কি আপনার ভারসাম্যযুক্ত অনুসন্ধানের গাছটি ন্যায্য অনুসন্ধানের গাছ নয়?

— Saeed

@ সাeedদ: দয়া করে নোট করুন যে আমার মানদণ্ডে আমি মধ্যস্থদের সন্ধান করার চেষ্টাও করি নি। আমি মাত্র সাইজের

এর অনুসন্ধান বৃক্ষে

সন্নিবেশ এবং

মোছা করেছি এবং এই ক্রিয়াকলাপগুলিতে

সময় নেওয়ার নিশ্চয়তা রয়েছে । আপনাকে কেবল এটি গ্রহণ করতে হবে যে বাছাইয়ের তুলনায় অনুসন্ধান ট্রি ক্রিয়াকলাপগুলি অনুশীলনে খুব ধীর। আপনি এটি সহজে দেখতে পাবেন যদি আপনি একটি বাছাই করা অ্যালগরিদম লিখতে চেষ্টা করেন যা ভারসাম্যযুক্ত অনুসন্ধানের গাছগুলিতে উপাদান যুক্ত করে কাজ করে - এটি অবশ্যই

সময়ে কাজ করে তবে এটি হাস্যকরভাবে অনুশীলনে ধীর হয়ে যাবে এবং প্রচুর অপচয়ও করবে also স্মৃতি।

n

$n$

n

$n$

k

$k$

O (\log k)

$O(\log k)$

O (n \log n)

$O(n \log n)$

— Jukka Suomela

উত্তর:

এখানে বাছাই থেকে কম আবদ্ধ। একটি ইনপুট সেট দেওয়া দৈর্ঘ্যের সাজাতে হবে, আপনার গঠিত মধ্যমা সমস্যা চলমান একটি ইনপুট তৈরি একটি সংখ্যা সর্বনিম্ন চেয়ে ছোট কপি , তারপর নিজেই, তারপর চেয়ে বড় একটি সংখ্যা কপি সর্বাধিক এবং সেট করুন । এই ইনপুটটির চলমান মিডিয়ানগুলি বাছাই করা ক্রমের সমান । $S$ $n$ $n-1$ $S$ $S$ $n-1$ $S$ $k=2n-1$ $S$

সুতরাং গণনার তুলনা মডেলটিতে, সময় প্রয়োজন। সম্ভবত যদি আপনার ইনপুটগুলি পূর্ণসংখ্যা হয় এবং আপনি পূর্ণসংখ্যার বাছাই করা অ্যালগরিদম ব্যবহার করেন তবে আপনি আরও ভাল করতে পারেন। $\Omega(n\log n)$

— ডেভিড এপস্টিন
সূত্র

এই উত্তরটি আমাকে সত্যিই বিস্মিত করে তোলে যদি কনভার্সটিও ধরে রাখে: একটি দক্ষ বাছাই অ্যালগরিদম দেওয়া, আমরা কি একটি কার্যকর চলমান মিডিয়ান অ্যালগরিদম পাই? (উদাহরণস্বরূপ, দক্ষ পূর্ণসংখ্যার বাছাই অ্যালগরিদমটি কি পূর্ণসংখ্যার জন্য দক্ষ চলমান মিডিয়ান অ্যালগরিদমকে বোঝায়? বা কোনও আইও-দক্ষ বাছাই করা অ্যালগরিদম কোনও আইও-দক্ষ চালিত মিডিয়ান অ্যালগরিদম সরবরাহ করে?)

— Jukka Suomela

আবারও, আপনার উত্তরের জন্য অনেক ধন্যবাদ, এটি আমাকে সত্যিকারের ট্র্যাকের উপরে ফেলেছে এবং বাছাই-ভিত্তিক মিডিয়াল ফিল্টার অ্যালগরিদমের জন্য অনুপ্রেরণা দিয়েছে! শেষ পর্যন্ত আমি 1991 সালের একটি কাগজ সন্ধান করতে সক্ষম হয়েছিল যা আপনি এখানে যা দেন তা মূলত একই যুক্তি উপস্থাপন করে এবং প্যাট মরিন ২০০৫ সাল থেকে অন্য প্রাসঙ্গিক কাগজে একটি পয়েন্টার দিয়েছেন; রেফারেস দেখুন। []] এবং [9] এখানে ।

— Jukka Suomela

সম্পাদনা: এই অ্যালগরিদমটি এখন এখানে উপস্থাপন করা হয়েছে: http://arxiv.org/abs/1406.1717

হ্যাঁ, এই সমস্যাটি সমাধান করার জন্য নিম্নলিখিত ক্রিয়াকলাপগুলি সম্পাদন করা যথেষ্ট:

উপাদান সহ প্রতিটি ভেক্টর বাছাই করুন । $n/k$ $k$
রৈখিক-সময় পোস্ট-প্রসেসিং করুন।

খুব মোটামুটিভাবে, ধারণাটি হ'ল:

ইনপুট দুটি সংলগ্ন ব্লক, এবং , উভয় উপাদান সহ বিবেচনা করুন; উপাদান হতে দিন এবং ইনপুট ভেক্টর এর উপস্থিতি অনুসারে । $a$ $b$ $k$ $a_1, a_2, ..., a_k$ $b_1, b_2, ..., b_k$ $x$
এই ব্লকগুলি বাছাই করুন এবং ব্লকের মধ্যে প্রতিটি উপাদানের অবস্থান শিখুন।
পূর্বসূরি / উত্তরসূরি পয়েন্টারগুলির সাথে ভেক্টরগুলিকে এবং সংযোজন করুন যাতে পয়েন্টার চেইনগুলি অনুসরণ করে আমরা উপাদানগুলিকে একটি ক্রমবর্ধমান ক্রমে অতিক্রম করতে পারি। এই ভাবে আমরা নির্মাণ করেছি দোকর তালিকা লিঙ্ক এবং । $a$ $b$ $a'$ $b'$
একের পর এক যুক্ত তালিকা থেকে সব উপাদান মুছে দিন, চেহারা বিপরীত ক্রম, । যখনই আমরা কোনও উপাদান মুছি, মনে রাখবেন মোছার সময় এর উত্তরাধিকারী ও পূর্বসূরী কী ছিল । $b'$ $b_k, b_{k-1}, ..., b_1$
এখন বজায় রাখা "মধ্যমা পয়েন্টার" এবং যে তালিকাতে বিন্দু এবং যথাক্রমে। ইনিশিয়ালাইজ এর মিডপয়েন্ট থেকে , এবং ইনিশিয়ালাইজ খালি তালিকার লেজ থেকে । $p$ $q$ $a'$ $b'$ $p$ $a'$ $q$ $b'$
প্রত্যেকের জন্য : $i$
- মুছুন তালিকা থেকে (এই হল সময়, শুধু যুক্ত তালিকা থেকে মুছে)। তুলনা করুন উপাদান এর মাধ্যমে নির্দিষ্ট যদি আমরা আগে বা পরে মুছে দেখতে । $a_i$ $a'$ $O(1)$ $a_i$ $p$ $p$
- রাখুন তালিকাতে ফিরে তার মূল অবস্থানে থাকে (এটি সময়, আমরা পূর্বসুরী এবং উত্তরাধিকারী মুখস্ত )। তুলনা উপাদান দ্বারা ইশারা দিয়ে যদি আমরা আগে বা পরে উপাদান যোগ দেখতে । $b_i$ $b'$ $O(1)$ $b_i$ $b_i$ $q$ $q$
- পয়েন্টার আপডেট এবং যাতে যোগদান তালিকার মধ্যমা এ যেকোনো হয় বা । (এটি সময়, সমস্ত কিছু সংশোধন করার জন্য কেবল লিঙ্কযুক্ত তালিকাগুলি অনুসরণ করুন each প্রতিটি তালিকায় এবং এর আগে / পরে কতগুলি আইটেম রয়েছে তা আমরা পর্যবেক্ষণ করব এবং আমরা আক্রমণকারীটি বজায় রাখব যে উভয় এবং এমন উপাদানগুলির দিকে নির্দেশ করুন যা সম্ভব যতটা মধ্যকের কাছাকাছি থাকে)) $p$ $q$ $a' \cup b'$ $p$ $q$ $O(1)$ $p$ $q$ $p$ $q$

লিঙ্কযুক্ত তালিকাগুলি কেবলমাত্র সূচিগুলির এলিমেন্ট অ্যারে, তাই এগুলি লাইটওয়েট হয় (মেমরি অ্যাক্সেসের লোকেশনটি কম নয়)। $k$

এখানে একটি নমুনা বাস্তবায়ন এবং মানদণ্ড রয়েছে:

https://github.com/suomela/median-filter

এখানে চলমান সময়গুলির একটি প্লট ( ): $n \approx 2\cdot 10^6$

নীল = বাছাই + পোস্ট-প্রক্রিয়াজাতকরণ, । $O(n \log k)$
সবুজ = https://github.com/craffel/median-filter থেকে দুটি কার্যকর, বজায় রাখুন $O(n \log k)$
লাল = দুটি অনুসন্ধান গাছ বজায় রাখুন, । $O(n \log k)$
কালো = বাছাই করা ভেক্টর বজায় রাখুন, । $O(n k)$
এক্স অক্ষ = উইন্ডোর আকার ( )। $\approx k/2$
Y অক্ষ = সেকেন্ডে চলমান সময়।
ডেটা = 32-বিট পূর্ণসংখ্যা এবং এলোমেলোভাবে 64-বিট পূর্ণসংখ্যা, বিভিন্ন বিতরণ থেকে।

running times

— জুক্কা সুমেলা
সূত্র

ডেভিডের সীমাবদ্ধতার পরিপ্রেক্ষিতে এটি সম্ভবত আপনি সবচেয়ে খারাপ ক্ষেত্রে করতে পারবেন না, তবে আরও ভাল আউটপুট সংবেদনশীল অ্যালগরিদম রয়েছে। বিশেষত, ফলাফলটিতে মিডিয়ান সংখ্যায় যদি হয় তবে আমরা সময়ে সমস্যাটি সমাধান করতে পারি । $m$ $O(n \log m + m \log n)$

এটি করার জন্য, ভারসাম্য বাইনারি গাছের সাথে ভারসাম্যযুক্ত বাইনারি গাছের সাথে প্রতিস্থাপন করুন কেবলমাত্র সেই উপাদানগুলিতে যা অতীতে মধ্যযুগীয় ছিল, এবং পূর্ববর্তী মিডিয়ানদের প্রতিটি জোড় (প্রতিটি দিকের জন্য একটি) এর মধ্যে দুটি ফিবোনাচি হ'ল, এবং আরও গুনে যাতে আমরা করতে পারি কোন ফিবোনাচি হিপটিতে ক্রমে একটি নির্দিষ্ট উপাদান রয়েছে তা সনাক্ত করুন। উপাদানগুলি মুছতে কখনও বিরক্ত করবেন না। যখন আমরা একটি নতুন উপাদান সন্নিবেশ করি তখন আমরা সময়ে আমাদের ডেটা স্ট্রাকচার আপডেট করতে পারি । যদি নতুন গণনাগুলি ইঙ্গিত দেয় যে মিডিয়ানটি ফিবোনাচি হিপগুলির মধ্যে একটিতে রয়েছে তবে নতুন মিডিয়ানটিকে বাইরে টেনে আনতে অতিরিক্ত লাগে । এই $O(\log m)$ $O(\log n)$ $O(\log n)$ চার্জ প্রতি মিডিয়ান প্রতি একবার হয়।

যদি সুন্দর ফিবোনাচি হিপ জটিলতার ক্ষতি না করে উপাদানগুলি মুছতে কোনও পরিষ্কার উপায় থাকে তবে আমরা , তবে আমি নিশ্চিত নই যে এটি সম্ভব কিনা। $O(n \log m + m \log k)$

— জিওফ্রে ইরভিং
সূত্র

ওহো, এটি লিখিত হিসাবে কাজ করবে না, কারণ আপনি যদি উপাদানগুলি মুছেন না তবে গণনাগুলি নতুন উইন্ডোকে প্রতিফলিত করবে না। এটি ঠিক করা যায় কিনা তা সম্পর্কে আমি নিশ্চিত নই, তবে কোনও উপায় থাকলে আমি উত্তরটি ছেড়ে দেব।

— জেফ্রি ইরভিং

সুতরাং আমি মনে করি এই অ্যালগরিদমটি আসলে ফিনোনাচি হিপগুলি থেকে নোডগুলি মুছে ফেললে

নিতে পারে , যেহেতু ডিলিট-মিনিট বলা হয় তখনই ফিবোনাচি হিপ গভীরতা বৃদ্ধি পায়। ডিলিট-মিনিটের কলগুলিকে অ্যাকাউন্টে গ্রহণ করে কেউ কি ফিবোনাচি হিপ জটিলতায় সুন্দর সীমানা জানে?

O (n \log m)

$O(n \log m)$

— জেফ্রি ইরভিং

পার্শ্ব দ্রষ্টব্য: প্রশ্ন পরিষ্কার নয়, আন্ডারলিং ডেটা স্ট্রাকচারটি সংজ্ঞায়িত করা হয়নি, আমরা কেবল খুব অস্পষ্ট কিছু জানি। আপনি কীভাবে এমন কোনও উন্নতি করতে চান যা আপনি জানেন না এটি কী? আপনি কিভাবে আপনার পদ্ধতির তুলনা করতে চান?

— Saeed

অসম্পূর্ণ কাজের জন্য আমি ক্ষমা চেয়ে নিচ্ছি। আমি এই উত্তরটি এখানে ঠিক করার জন্য প্রয়োজনীয় কংক্রিট প্রশ্ন জিজ্ঞাসা করেছি: cstheory.stackexchange.com/questions/21778/… । আপনি যদি এটি যথাযথ মনে করেন তবে দ্বিতীয় উত্তরটি সমাধান না হওয়া পর্যন্ত আমি এই উত্তরটি সরিয়ে ফেলতে পারি।

— জেফ্রি ইরভিং