อัลกอริทึมที่ไม่สำคัญสำหรับการคำนวณค่ามัธยฐานหน้าต่างบานเลื่อน

ฉันต้องการคำนวณค่ามัธยฐานที่ทำงานอยู่:

การป้อนข้อมูล: $n$ ,เวกเตอร์x_n) $k$ $(x_1, x_2, \dotsc, x_n)$
เอาท์พุท:เวกเตอร์ที่เป็นค่ามัธยฐานของK-1}) $(y_1, y_2, \dotsc, y_{n-k+1})$ $y_i$ $(x_i, x_{i+1}, \dotsc, x_{i+k-1})$

(ไม่มีการโกงโดยประมาณฉันต้องการคำตอบที่ถูกต้ององค์ประกอบเป็นจำนวนเต็มขนาดใหญ่) $x_i$

มีอัลกอริทึมเล็ก ๆ น้อย ๆ ที่รักษาโครงสร้างการค้นหาขนาด ; เวลาทำงานรวมเป็นk) (นี่คือ "แผนผังการค้นหา" หมายถึงโครงสร้างข้อมูลที่มีประสิทธิภาพบางอย่างที่รองรับการแทรกการลบและการสอบถามค่ามัธยฐานในเวลาลอการิทึม) $k$ $O(n \log k)$

อย่างไรก็ตามนี่มันช่างโง่เหลือเกินสำหรับฉัน เราจะเรียนรู้สถิติการสั่งซื้อทั้งหมดอย่างมีประสิทธิภาพภายในหน้าต่างทุกขนาด $k$ ไม่ใช่เฉพาะค่ามัธยฐาน ยิ่งไปกว่านั้นสิ่งนี้ไม่น่าดึงดูดในทางปฏิบัติโดยเฉพาะถ้า $k$ มีขนาดใหญ่ (ต้นไม้ค้นหาขนาดใหญ่มีแนวโน้มที่จะเชื่องช้าค่าใช้จ่ายในการใช้หน่วยความจำนั้นไม่น่ารำคาญเลย

เราสามารถทำอะไรที่ดีกว่าอย่างมีนัยสำคัญได้หรือไม่

มีขอบเขตที่ต่ำกว่า (เช่นอัลกอริธึมเล็กน้อยนั้นเหมาะที่สุดสำหรับการเปรียบเทียบแบบจำลองหรือไม่)

แก้ไข: David Eppstein ให้ขอบเขตล่างที่ดีสำหรับรุ่นเปรียบเทียบ! ฉันสงสัยว่ามันเป็นไปได้ไหมที่จะทำสิ่งที่ฉลาดกว่าอัลกอริทึมเล็กน้อย?

ตัวอย่างเช่นเราสามารถทำอะไรบางอย่างตามเส้นเหล่านี้ได้หรือไม่: แบ่งเวกเตอร์อินพุตให้เป็นส่วนของขนาด $k$ ; จัดเรียงแต่ละส่วน (ติดตามตำแหน่งเดิมของแต่ละองค์ประกอบ) แล้วใช้เวกเตอร์ที่เรียงลำดับตามเข็มเพื่อหาค่ามัธยฐานการวิ่งที่มีประสิทธิภาพโดยไม่มีโครงสร้างข้อมูลเสริม? แน่นอนว่านี่จะยังคงเป็น $O(n \log k)$ แต่ในการเรียงลำดับในทางปฏิบัติมีแนวโน้มที่จะเร็วกว่าการดูแลโครงสร้างการค้นหา

แก้ไข 2: Saeed ต้องการเห็นเหตุผลบางอย่างว่าทำไมฉันคิดว่าการเรียงลำดับเร็วกว่าการค้นหาทรี นี่คือมาตรฐานที่รวดเร็วมากสำหรับ $k = 10^7$ , $n = 10^8$ :

≈ 8s: การเรียงเวกเตอร์ $n/k$ มีองค์ประกอบ $k$ แต่ละอัน
≈ 10s: การจัดเรียงเวกเตอร์ที่มีองค์ประกอบ $n$
≈ 80:แทรกและลบในตารางแฮชขนาด $n$ $k$
≈ 390S:แทรกและลบในต้นไม้ค้นหาสมดุลขนาด $n$ $k$

ตารางแฮชมีไว้เพื่อเปรียบเทียบเท่านั้น มันไม่มีประโยชน์โดยตรงในแอปพลิเคชันนี้

โดยสรุปเรามีความแตกต่างของประสิทธิภาพการเรียงลำดับกับการค้นหาทรีที่สมดุลเกือบ50เท่า และสิ่งที่ได้รับเลวร้ายมากถ้าเราเพิ่มk $k$

(รายละเอียดทางเทคนิค: ข้อมูล = จำนวนเต็ม 32- บิตสุ่มคอมพิวเตอร์ = แล็ปท็อปทันสมัยทั่วไปรหัสทดสอบถูกเขียนใน C ++ โดยใช้ไลบรารีมาตรฐาน (std :: sort) และโครงสร้างข้อมูล (std :: multiset, std :: unsorted_multiset) ฉันใช้คอมไพเลอร์ C ++ สองตัว (GCC และ Clang) และการใช้งานที่แตกต่างกันสองอย่างของไลบรารี่มาตรฐาน (libstdc ++ และ libc ++) ตามเนื้อผ้า std :: multiset ได้รับการนำมาใช้เป็นต้นไม้สีแดงดำที่ได้รับการปรับให้เหมาะสมที่สุด)

ds.algorithms ds.data-structures lower-bounds

— Jukka Suomela
แหล่งที่มา

ผมไม่คิดว่าคุณจะสามารถที่จะปรับปรุง

เหตุผลคือถ้าคุณดูที่หน้าต่าง

nlogk $nlogk$

, คุณไม่สามารถแยกแยะตัวเลขใด ๆ ได้เลย

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

จากการเป็นค่ามัธยฐานของหน้าต่างในอนาคต ซึ่งหมายความว่าในเวลาใดก็ตามคุณต้องเก็บอย่างน้อย

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

จำนวนเต็มในโครงสร้างข้อมูลและดูเหมือนว่าจะไม่อัปเดตในเวลาน้อยกว่าบันทึก k2 $\frac{k}{2}$

— RB

อัลกอริธึมเล็กน้อยของคุณสำหรับฉันดูเหมือนว่าจะเป็น

ไม่ใช่

O((n−k)⋅k⋅logk) $O((n-k)\cdot k \cdot \log k)$

, สิ่งที่ฉันเข้าใจผิด? และผมคิดว่าเพราะเหตุนี้คุณมีปัญหากับใหญ่

มิฉะนั้นปัจจัยลอการิทึมอะไรในการใช้งานจริงยังไม่มีคงซ่อนใหญ่ในขั้นตอนวิธีนี้ O(nlogk) $O(n \log k)$

k $k$

— Saeed

@Saeed: ในอัลกอริทึมแบบเล็กน้อยคุณจะประมวลผลองค์ประกอบทีละชุด ในขั้นตอนที่

คุณเพิ่ม

ลงในแผนผังการค้นหาและ (ถ้า

) คุณยังลบ

ออกจาก

การค้นหา นี่คือ

ขั้นตอนของแต่ละคนซึ่งจะใช้เวลา

เวลา i $i$

xi $x_i$

i>k $i > k$

xi−k $x_{i-k}$

n $n$

O(logk) $O(\log k)$

— Jukka Suomela

ดังนั้นคุณหมายความว่าคุณมีแผนผังการค้นหาที่สมดุลไม่ใช่โครงสร้างการค้นหาทั่วไป?

— Saeed

@Seed: โปรดทราบว่าในเกณฑ์มาตรฐานของฉันฉันไม่ได้พยายามหาค่าเฉลี่ย ผมก็ไม่ได้

แทรกและ

ลบในต้นไม้ค้นหาขนาด

n $n$

k $k$ และการดำเนินงานเหล่านี้มีการรับประกันที่จะใช้

เวลา คุณต้องยอมรับว่าการดำเนินการค้นหาต้นไม้ช้ามากในทางปฏิบัติเมื่อเปรียบเทียบกับการเรียงลำดับ คุณจะเห็นสิ่งนี้ได้อย่างง่ายดายหากคุณพยายามเขียนอัลกอริทึมการเรียงลำดับที่ทำงานโดยการเพิ่มองค์ประกอบลงในแผนผังการค้นหาที่สมดุล - มันใช้งานได้ในเวลา

แต่มันจะช้าลงอย่างมากในทางปฏิบัติ ของหน่วยความจำ O(logk) $O(\log k)$

O(nlogn) $O(n \log n)$

— Jukka Suomela

คำตอบ:

นี่คือขอบเขตที่ต่ำกว่าจากการเรียงลำดับ เมื่อกำหนดชุดอินพุตของความยาวเพื่อจัดเรียงให้สร้างอินพุตสำหรับปัญหาค่ามัธยฐานที่ใช้อยู่ของคุณซึ่งประกอบด้วยสำเนาของจำนวนที่น้อยกว่าค่าต่ำสุดของและตัวเองจากนั้นสำเนาของจำนวนที่มากกว่า สูงสุดของ $S$ $n$ $n-1$ $S$ $S$ $n-1$ และชุด 1มีเดียการทำงานของการป้อนข้อมูลนี้เป็นเช่นเดียวกับเรียงลำดับของS $S$ $k=2n-1$ $S$

ดังนั้นในรูปแบบการเปรียบเทียบของการคำนวณจึงจำเป็นต้องใช้เวลาอาจเป็นไปได้ว่าหากอินพุตของคุณเป็นจำนวนเต็มและคุณใช้อัลกอริทึมการเรียงลำดับจำนวนเต็มคุณสามารถทำได้ดี $\Omega(n\log n)$

— David Eppstein
แหล่งที่มา

คำตอบนี้ทำให้ฉันสงสัยว่าการสนทนานั้นดีหรือไม่: ด้วยอัลกอริธึมการเรียงลำดับที่มีประสิทธิภาพเราจะได้อัลกอริทึมมัธยฐานการรันที่มีประสิทธิภาพหรือไม่? (ตัวอย่างเช่นไม่เกี่ยวกับจำนวนเต็มเรียงลำดับขั้นตอนวิธีการที่มีประสิทธิภาพบ่งบอกถึงประสิทธิภาพการทำงานขั้นตอนวิธีการแบ่งจำนวนเต็มหรือไม่ขั้นตอนวิธีการเรียงลำดับ IO-ที่มีประสิทธิภาพให้ IO-ที่มีประสิทธิภาพการทำงานขั้นตอนวิธีการแบ่ง?)

— Jukka Suomela

ขอขอบคุณอีกครั้งสำหรับคำตอบของคุณมันทำให้ฉันอยู่บนเส้นทางที่ถูกต้องและสร้างแรงบันดาลใจให้กับอัลกอริทึมการกรองแบบมัธยฐานตามการเรียงลำดับ! ในท้ายที่สุดฉันสามารถค้นหากระดาษจาก 1991 ซึ่งนำเสนอข้อโต้แย้งโดยทั่วไปเหมือนกับที่คุณให้ที่นี่และ Pat Morin ให้ตัวชี้ไปยังกระดาษอื่นที่เกี่ยวข้องจากปี 2005 ดูอ้างอิง [6] และ [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$ x
เรียงบล็อกเหล่านี้และเรียนรู้อันดับของแต่ละองค์ประกอบภายในบล็อก
เพิ่มเวกเตอร์และด้วยพอยน์เตอร์ของบรรพบุรุษ / ตัวตายตัวแทนเพื่อให้การติดตามตัวชี้โซ่เราสามารถสำรวจองค์ประกอบในลำดับที่เพิ่มขึ้น วิธีนี้เราได้สร้างรายการเชื่อมโยงทวีคูณและ ' $a$ $b$ $a'$ $b'$
หนึ่งโดยหนึ่งลบองค์ประกอบทั้งหมดจากรายการที่เชื่อมโยงในลำดับย้อนกลับของการปรากฏตัว 1เมื่อใดก็ตามที่เราลบองค์ประกอบจำสิ่งที่เป็นทายาทและบรรพบุรุษของมันในช่วงเวลาของการลบ $b'$ $b_k, b_{k-1}, ..., b_1$
ตอนนี้รักษา "ชี้ค่ามัธยฐาน" และที่ชี้ไปที่รายการและตามลำดับ initialise เพื่อจุดกึ่งกลางของและ Initialise หางของรายการที่ว่างเปล่า $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$
- ปรับปรุงตัวชี้และเพื่อให้ค่ามัธยฐานของรายการที่เข้าร่วมเป็นทั้งที่หรือQ(นี่คือเวลาเพียงทำตามรายการที่เชื่อมโยงหนึ่งหรือสองขั้นตอนเพื่อแก้ไขทุกอย่างเราจะติดตามจำนวนรายการก่อน / หลังและในแต่ละรายการและเราจะรักษาค่าคงที่ที่และชี้ไปที่องค์ประกอบที่ใกล้เคียงกับค่าเฉลี่ยที่เป็นไปได้.) $p$ $q$ $a' \cup b'$ $p$ $q$ $O(1)$ $p$ $q$ $p$ $q$

รายการที่เชื่อมโยงเป็นเพียงอาร์เรย์ -element ของดัชนีดังนั้นจึงมีน้ำหนักเบา (ยกเว้นว่าการเข้าถึงหน่วยความจำท้องถิ่นไม่ดี) $k$

นี่คือตัวอย่างการใช้งานและมาตรฐาน:

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

นี่คือพล็อตของเวลาทำงาน (สำหรับ ): $n \approx 2\cdot 10^6$

สีน้ำเงิน = การเรียงลำดับ + การโพสต์ ) $O(n \log k)$
Green = รักษาสอง heaps, , การนำไปใช้จากhttps://github.com/craffel/median-filter $O(n \log k)$
สีแดง = รักษาต้นไม้สองต้นค้นหา ) $O(n \log k)$
= ดำรักษาเวกเตอร์เรียง ) $O(n k)$
แกน X = ขนาดหน้าต่าง ( $\approx k/2$ )
แกน Y = ใช้เวลาเป็นวินาที
Data = จำนวนเต็ม 32 บิตและสุ่ม 64 บิตจากการแจกแจงแบบต่างๆ

running times

— Jukka Suomela
แหล่งที่มา

เมื่อพิจารณาถึงขอบเขตของเดวิดมันไม่น่าเป็นไปได้ที่คุณจะทำได้ดีที่สุดในกรณีที่เลวร้ายที่สุด โดยเฉพาะถ้าในจำนวนของมีเดียในผลที่เราสามารถแก้ปัญหาในเวลา ) $m$ $O(n \log m + m \log n)$

เมื่อต้องการทำสิ่งนี้แทนที่ต้นไม้ไบนารีที่สมดุลด้วยต้นไม้ไบนารีที่สมดุลซึ่งประกอบด้วยเฉพาะองค์ประกอบที่เป็นค่ามัธยฐานในอดีตบวกสองฟีโบนักชีกองสองตัวระหว่างแต่ละคู่ของค่ามัธยฐานก่อนหน้า (หนึ่งค่าสำหรับแต่ละทิศทาง) บวกจำนวนเพื่อให้เรา ค้นหาว่า Fibonacci heap ใดที่มีองค์ประกอบเฉพาะตามลำดับ ไม่ต้องกังวลกับการลบองค์ประกอบ เมื่อเราใส่องค์ประกอบใหม่ที่เราสามารถปรับปรุงโครงสร้างข้อมูลของเราในเวลา หากการนับใหม่บ่งชี้ว่าค่ามัธยฐานอยู่ในหนึ่งในฟีโบนักชีกองหนึ่งก็จะใช้เพื่อดึงค่ามัธยฐานใหม่ออกมา นี้ $O(\log m)$ $O(\log n)$ $O(\log n)$ ค่าใช้จ่ายเกิดขึ้นเพียงครั้งเดียวต่อค่ามัธยฐาน

If there was a clean way to delete elements without damaging the nice Fibonacci heap complexity, we'd get down to $O(n \log m + m \log k)$ , but I'm not sure if this is possible.

— Geoffrey Irving
แหล่งที่มา

Oops, this doesn't work as written, since if you don't delete elements the counts won't reflect the new window. I'm not sure if it can be fixed, but I will leave the answer in case there is a way.

— Geoffrey Irving

So I think this algorithm may in fact take

O(nlogm) $O(n \log m)$ if you delete nodes from the Fibonacci heaps, since the Fibonacci heap depth increases only when delete-min is called. Does anyone know nice bounds on Fibonacci heap complexity taking the number of delete-min calls into account?

— Geoffrey Irving

side note: Question is not clear, underling data structure is not defined, we just know something very vague. how do you want improve something that you don't know what it is? how do you want compare your approach?

— Saeed

I apologize for the incomplete work. I've asked the concrete question needed to fix this answer here: cstheory.stackexchange.com/questions/21778/…. If you think it's appropriate I can remove this answer until the secondary question is resolved.

— Geoffrey Irving