เหตุใด Quickized Quicksort จึงมีค่าใช้จ่ายรันไทม์ที่แย่ที่สุดในกรณี O (n log n)

การจัดเรียงแบบด่วนแบบสุ่มเป็นส่วนขยายของการเรียงแบบด่วนซึ่งองค์ประกอบของเดือยจะถูกเลือกแบบสุ่ม สิ่งที่สามารถซับซ้อนเวลากรณีที่เลวร้ายที่สุดของอัลกอริทึมนี้ ตามที่ผมมันควรจะเป็น$O(n^2)$เป็นกรณีที่เลวร้ายที่สุดที่เกิดขึ้นเมื่อหมุนสุ่มเลือกถูกเลือกในเรียงหรือเรียงย้อนกลับการสั่งซื้อ แต่ในบางตำรา [1] [2]ความซับซ้อนของเวลากรณีที่เลวร้ายที่สุดถูกเขียนเป็น$O(n\log{n})$

ถูกต้องอะไร

ทั้งสองของแหล่งที่มาของคุณดูที่ "เลวร้ายที่สุดกรณีที่คาดว่าเวลาทำงาน" ของฉันเดาว่านี่หมายถึงความต้องการเวลาที่คาดหวังซึ่งแตกต่างจากกรณีที่เลวร้ายที่สุด$O(n \log n).$

quicksort มักจะมีความต้องการเวลาที่เลวร้ายที่สุดกรณีที่แน่นอนของ ) กรณีที่เลวร้ายที่สุดเกิดขึ้นเมื่อในทุกขั้นตอนขั้นตอนพาร์ทิชันแยกnมีความยาวอาร์เรย์ลงในอาร์เรย์ขนาด1และn - 1 การเลือกองค์ประกอบ "โชคร้าย" นี้ต้องใช้O ( n ) การโทรซ้ำเพื่อนำไปสู่กรณีที่เลวร้ายที่สุดO ( n 2$O(n^2)$$n$$1$$n-1$$O(n)$$O(n^2)$

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

แก้ไข:

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

คุณพลาดที่ข้อความเหล่านี้พูดถึง " เวลาที่คาดว่าจะเกิดกรณีเลวร้ายที่สุด" ไม่ใช่ "รันไทม์กรณีที่แย่ที่สุด"

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

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

ดังนั้นเราจึงคำนวณ "runtime ที่คาดไว้" สำหรับแต่ละอินพุตที่เป็นไปได้และเพื่อให้ได้ "runtime case ที่แย่ที่สุดที่คาดหวัง" เราจะค้นหาอินพุตที่เป็นไปได้หนึ่งตำแหน่ง และเห็นได้ชัดว่าพวกเขาแสดงให้เห็นว่ากรณีที่เลวร้ายที่สุดสำหรับ "รันไทม์ที่คาดหวัง" เป็นเพียง O (n log n) ฉันจะไม่แปลกใจถ้าเพียงแค่เลือกเดือยแรกที่สุ่มจะเปลี่ยนกรณีที่เลวร้ายที่สุดที่คาดว่าจะรันไทม์เป็น o (n ^ 2) (เล็ก ๆ น้อย ๆ แทน Big O) เพราะเพียงไม่กี่ pivots จะนำไปสู่กรณีที่เลวร้ายที่สุด พฤติกรรม.

โปรดทราบว่ามีสองสิ่งที่จะคาดหวัง / เฉลี่ยมากกว่า: การเปลี่ยนแปลงอินพุตและ pivots (หนึ่งรายการต่อการแบ่งพาร์ติชัน)

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

การใช้งานอื่น ๆ มี runtime-case ที่แย่ที่สุดที่เป็นจริงใน $\Theta(n \log n)$

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

$O(n^2)$

กรณีที่เลวร้ายที่สุดสำหรับ quicksort แบบสุ่มคือองค์ประกอบเดียวกับอินพุต เช่น 2,2,2,2,2,2

$T(n) = T(n-1) + n$$O(n^2)$