Quicksort và đừng bận tâm?


9

Đặc biệt là khi viết các ứng dụng 'tiêu chuẩn' (không phải HPC), bạn có xem xét chọn thuật toán sắp xếp nào, hoặc chỉ giải quyết với quicksort (đó là điều mà hầu hết các thư viện chỉ gọi là sắp xếp)? Ở một mức độ nào đó, nó có thể mang lại lợi nhuận trong các tình huống cụ thể, nhưng mặt khác tối ưu hóa thích hợp đòi hỏi một chút thời gian để phân tích vấn đề và đưa ra các tiêu chuẩn.

Câu trả lời:


12

Nói chung, sử dụng các phương thức mặc định trừ khi có nhu cầu cụ thể để làm một cái gì đó kỳ lạ hơn giúp mọi thứ dễ đọc / dễ hiểu hơn rất nhiều trong IMHO.

Nếu bạn gặp phải (hoặc trong một số trường hợp, nghi ngờ mạnh mẽ) rằng bạn có một vấn đề về hiệu suất là thời gian để thêm độ phức tạp.

Mặt khác, nếu bạn đang sử dụng một ngôn ngữ đủ thấp mà không có loại tích hợp sẵn cho loại đối tượng bạn cần sắp xếp, hãy thử chọn một hoặc hai ngôn ngữ bao gồm tất cả các cơ sở của bạn và thực hiện những điều đó.


6

Luôn gọi các thói quen thư viện được cung cấp, trừ khi bạn có lý do rất, rất tốt để không làm như vậy (và bạn cần ghi lại lý do tại sao nó lại như vậy).

Điều này là do các thuật toán sắp xếp rất khó để có được hoàn toàn đúng. Có một lỗi trong quicksort Java với các bộ dữ liệu rất lớn, được Sun xác định, sửa chữa và giao cho khách hàng, vì vậy bạn không phải làm vậy.

Ngoài ra, sắp xếp mặc định trong Java 7 đã được nâng cấp lên một loại mới hơn, tốt hơn. Cũng miễn phí.

Trừ khi sắp xếp mặc định là có thể chứng minh không đủ tốt cho bạn, gắn bó với nó.


3

Tại một hội nghị một lần tôi đã nghe một câu chuyện hay về điều này.

Tại Microsoft, một người nào đó đang viết một ứng dụng VB (ví dụ VB 3) và gửi cho một nhóm người nói rằng anh ta có rất nhiều giá trị và anh ta muốn chúng xuất hiện trong combobox theo thứ tự, anh ta nên làm thế nào.

Mọi người đã lặn tìm sách giáo khoa khoa học máy tính cũ của họ, tìm kiếm các thói quen hiệu quả cao và chuyển chúng đến Visual Basic và gửi chúng cho anh ta. Một người chỉ cần gửi lại "có bao nhiêu giá trị trong combobox?".

"Khoảng 50" đã trả lời.

"Chỉ cần đặt thuộc tính được sắp xếp thành TRUE".

Trong 99.9999% việc sắp xếp các trường hợp được thực hiện tốt nhất bằng cách sử dụng thư viện, điều khiển hoặc trong SQL chọn vì sự khác biệt hiệu suất giữa thói quen thư viện và bất cứ điều gì bạn viết sẽ không đáng kể và nỗ lực và chi phí bảo trì sẽ vượt quá nhiều hậu quả.


1

Đây là thời gian để đưa ra các trích dẫn cổ điển về tối ưu hóa sớm. Trong hầu hết các trường hợp, nó thực sự không quan trọng. Heck, với tốc độ của CPU ngày nay, có lẽ bạn có thể sắp xếp bong bóng hầu hết các tập dữ liệu và không thực sự chú ý nhiều. Nhưng khi bạn sắp xếp các tập dữ liệu thực sự lớn và hiệu suất sắp xếp bắt đầu trở thành một vấn đề, thì bạn chắc chắn nên xem xét các tùy chọn khác.


Sắp xếp bong bóng? Hiệu suất của nó là kém nhất đối với trường hợp trung bình và trường hợp xấu nhất và bằng với cách sắp xếp chèn cho trường hợp tốt nhất. Không có lý do mà nó nên được sử dụng.

1
@ Hippo: Tôi thực sự không ủng hộ việc sử dụng sắp xếp bong bóng. Tôi có nghĩa là các máy tính hiện đại đủ nhanh để trong hầu hết các trường hợp, thuật toán của bạn chậm đến mức nào vì người dùng sẽ không chú ý.
Mason Wheeler

Làm thế nào về Bogosort ?
dsimcha

0

Mặc dù nó rõ ràng không quan trọng đối với các bit và thời gian. Tôi thấy sắp xếp hợp nhất để dễ viết và dễ hiểu hơn quicksort. Vì vậy, nếu tôi sẽ viết thuật toán sắp xếp của riêng tôi, tôi sẽ sử dụng thuật toán đó.


Viva sáp nhập! Và một thuật ngữ liên tục tốt hơn nhẹ, và không có trường hợp xấu nhất khủng khiếp.
Frank Shearar

0

Ít nhất là trong một thư viện được viết thành thạo, tôi mong muốn việc tích hợp sortsẽ được triển khai như một Introsort thay vì chỉ là Quicksort. Sự khác biệt hiếm khi quan trọng lắm, nhưng Introsort loại bỏ hiệu năng xấu nhất của Quicksort với hiệu quả tối thiểu đối với các trường hợp phổ biến hơn.

Tuy nhiên, để trả lời câu hỏi của bạn: có - đó là những gì bạn thường bắt đầu và cho đến khi / trừ khi bạn có kết quả hồ sơ cho thấy đó là một vấn đề, đó là nơi vẫn nên tồn tại.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.