Thời gian không đổi và thời gian liên tục được khấu hao có hiệu quả được coi là tương đương không?

Tôi cần phải viết RandomQueue cho phép nối thêm và xóa ngẫu nhiên trong Thời gian không đổi (O (1)).

Suy nghĩ đầu tiên của tôi là sao lưu nó với một số loại Array (tôi đã chọn một ArrayList), vì các mảng có quyền truy cập liên tục thông qua một chỉ mục.

Nhìn qua tài liệu mặc dù, tôi nhận ra rằng các bổ sung của ArrayLists được coi là Thời gian không đổi được khấu hao, vì một bổ sung có thể yêu cầu phân bổ lại mảng bên dưới, đó là O (n).

Là thời gian liên tục được khấu hao và thời gian không đổi có hiệu quả như nhau hay tôi cần xem xét một số cấu trúc thay thế không yêu cầu phân bổ lại đầy đủ cho mỗi lần bổ sung?

Tôi đang hỏi điều này bởi vì các cấu trúc dựa trên mảng sang một bên (mà theo như tôi biết sẽ luôn có các bổ sung Thời gian không đổi được khấu hao), tôi không thể nghĩ ra bất cứ điều gì sẽ đáp ứng các yêu cầu:

• Bất cứ thứ gì dựa trên cây sẽ có quyền truy cập O (log n) tốt nhất
• Một danh sách được liên kết có khả năng có thể có các bổ sung O (1) (nếu tham chiếu đến đuôi được giữ), nhưng loại bỏ ngẫu nhiên nên ở mức tốt nhất là O (n).

Đây là câu hỏi đầy đủ; trong trường hợp tôi dán mắt vào một số chi tiết quan trọng:

Thiết kế và triển khai RandomQueue. Đây là một triển khai của giao diện Hàng đợi trong đó thao tác remove () loại bỏ một phần tử được chọn ngẫu nhiên trong số tất cả các phần tử hiện có trong hàng đợi. .

Thời gian liên tục được khấu hao hầu như luôn có thể được coi là tương đương với Thời gian liên tục và không cần biết chi tiết cụ thể về ứng dụng của bạn và loại sử dụng mà bạn dự định thực hiện cho hàng đợi này, rất có thể bạn sẽ được bảo hiểm.

Một danh sách mảng có khái niệm về công suất , về cơ bản bằng với kích thước / chiều dài / số lượng lớn nhất của các mặt hàng đã từng được yêu cầu cho đến nay. Vì vậy, điều sẽ xảy ra là vào đầu danh sách mảng sẽ tiếp tục tự phân bổ lại để tăng công suất khi bạn tiếp tục thêm các mục vào nó, nhưng đến một lúc nào đó, số lượng vật phẩm trung bình được thêm vào mỗi đơn vị thời gian chắc chắn sẽ khớp với số lượng vật phẩm trung bình bị loại bỏ trên mỗi đơn vị thời gian, (nếu không cuối cùng bạn sẽ hết bộ nhớ,) tại thời điểm đó, mảng sẽ ngừng phân bổ lại chính nó và tất cả các phụ lục sẽ được đáp ứng tại thời điểm không đổi của O (1).

Tuy nhiên, hãy nhớ rằng theo mặc định, loại bỏ ngẫu nhiên khỏi danh sách mảng không phải là O (1), đó là O (N), vì danh sách mảng di chuyển tất cả các mục sau khi vị trí bị xóa xuống một vị trí để thay thế vị trí bị xóa mục. Để đạt được O (1), bạn sẽ phải ghi đè hành vi mặc định để thay thế mục bị xóa bằng một bản sao của mục cuối cùng của danh sách mảng, sau đó xóa mục cuối cùng để không có mục nào bị di chuyển. Nhưng sau đó, nếu bạn làm điều đó, bạn không chính xác có một hàng đợi nữa.

Câu hỏi dường như đặc biệt yêu cầu thời gian không đổi, và không phải là thời gian không đổi được khấu hao . Vì vậy, đối với câu hỏi được trích dẫn, không, chúng không thực sự giống nhau *. Có phải họ tuy nhiên trong các ứng dụng thế giới thực?

Vấn đề điển hình với hằng số khấu hao là đôi khi bạn phải trả khoản nợ tích lũy. Vì vậy, trong khi các phần chèn thường không đổi, đôi khi bạn phải chịu chi phí cho việc tái xác nhận mọi thứ một lần nữa khi một khối mới được phân bổ.

Trường hợp sự khác biệt giữa thời gian không đổi và thời gian không đổi được khấu hao có liên quan đến một ứng dụng phụ thuộc vào việc tốc độ rất chậm thường xuyên này có được chấp nhận hay không. Đối với một số lượng lớn các tên miền, điều này thường ổn. Đặc biệt nếu container có kích thước tối đa hiệu quả (như cache, bộ đệm tạm thời, container hoạt động), bạn có thể trả chi phí một cách hiệu quả chỉ một lần trong khi thực hiện.

Trong các ứng dụng quan trọng đáp ứng những thời điểm này có thể không được chấp nhận. Nếu bạn được yêu cầu đáp ứng một thời gian ngắn đảm bảo quay vòng, bạn không thể dựa vào một thuật toán đôi khi sẽ vượt quá điều đó. Tôi đã làm việc trên các dự án như vậy trước đây, nhưng chúng cực kỳ hiếm.

Nó cũng phụ thuộc vào chi phí thực sự cao như thế nào. Các vectơ có xu hướng hoạt động tốt vì chi phí phân bổ lại của chúng là tương đối thấp. Nếu bạn đi đến bản đồ băm, tuy nhiên việc phân bổ lại có thể cao hơn rất nhiều. Mặc dù một lần nữa, đối với hầu hết các ứng dụng có thể tốt, đặc biệt là các máy chủ tồn tại lâu hơn với giới hạn trên của các mục trong vùng chứa.

* Có một chút vấn đề ở đây. Để làm cho bất kỳ thùng chứa mục đích chung nào là thời gian không đổi để chèn một trong hai điều phải giữ:

• Container phải có kích thước tối đa cố định; hoặc là
• bạn có thể giả sử cấp phát bộ nhớ của các yếu tố riêng lẻ là thời gian không đổi.

Nó phụ thuộc - vào việc bạn đang tối ưu hóa thông lượng hay độ trễ:

• Hệ thống nhạy cảm độ trễ cần hiệu suất phù hợp. Đối với một kịch bản như vậy, chúng tôi phải nhấn mạnh hành vi trong trường hợp xấu nhất của hệ thống. Ví dụ là các hệ thống thời gian thực mềm như các trò chơi muốn đạt được tốc độ khung hình ổn định hoặc các máy chủ web phải gửi phản hồi trong một khung thời gian chặt chẽ nhất định: lãng phí chu kỳ CPU tốt hơn là trễ.
• Các hệ thống được tối ưu hóa thông lượng không quan tâm đến các quầy hàng thường xuyên, miễn là lượng dữ liệu tối đa có thể được xử lý trong thời gian dài. Ở đây, chúng tôi chủ yếu quan tâm đến hiệu suất khấu hao. Đây thường là trường hợp cho crunching số hoặc công việc xử lý hàng loạt khác.

Lưu ý rằng một hệ thống có thể có các thành phần khác nhau phải được phân loại khác nhau. Ví dụ, một bộ xử lý văn bản hiện đại sẽ có một luồng UI nhạy cảm với độ trễ, nhưng các luồng được tối ưu hóa thông lượng cho các tác vụ khác như kiểm tra chính tả hoặc xuất PDF.

Ngoài ra, thuật toán phức tạp thường không quan trọng nhiều như chúng tôi muốn có thể nghĩ rằng: Khi một vấn đề được bao bọc với một số lượng nhất định, sau đó đặc tính hiệu suất thực tế và đo quan trọng hơn hành vi “cho rất lớn n ”.

Nếu bạn được yêu cầu thuật toán "khấu hao thời gian không đổi", thuật toán của bạn đôi khi có thể mất nhiều thời gian. Ví dụ: nếu bạn sử dụng std :: vector trong C ++, một vectơ như vậy có thể đã phân bổ không gian cho 10 đối tượng và khi bạn phân bổ đối tượng thứ 11, không gian cho 20 đối tượng được phân bổ, 10 đối tượng được sao chép và thêm 11 đối tượng mất thời gian đáng kể. Nhưng nếu bạn thêm một triệu đối tượng, bạn có thể có 999.980 hoạt động nhanh và 20 hoạt động chậm, với thời gian trung bình là nhanh.

Nếu bạn được yêu cầu thuật toán "thời gian không đổi", thuật toán của bạn phải luôn nhanh, cho mọi thao tác. Điều đó rất quan trọng đối với các hệ thống thời gian thực nơi bạn có thể cần một sự đảm bảo rằng mỗi hoạt động đơn lẻ luôn nhanh. "Thời gian không đổi" thường không cần thiết, nhưng nó chắc chắn không giống như "thời gian không đổi được khấu hao".