Tại sao kích thước đầu vào lớn hơn ngụ ý các trường hợp khó hơn?

Dưới đây, giả sử chúng tôi đang làm việc với một máy Turing băng vô hạn.

Khi giải thích khái niệm về độ phức tạp thời gian cho ai đó và lý do tại sao nó được đo tương đối với kích thước đầu vào của một thể hiện, tôi tình cờ phát hiện ra tuyên bố sau:

[..] Ví dụ, điều tự nhiên là bạn cần nhiều bước hơn để nhân hai số nguyên với 100000 bit, hơn là, nhân hai số nguyên với 3 bit.

Yêu cầu này rất thuyết phục, nhưng bằng cách nào đó vẫy tay. Trong tất cả các thuật toán tôi đã gặp, kích thước đầu vào càng lớn, bạn càng cần nhiều bước. Nói một cách chính xác hơn, độ phức tạp thời gian là một hàm tăng đơn điệu của kích thước đầu vào.

Có phải trường hợp phức tạp thời gian luôn là một hàm tăng trong kích thước đầu vào? Nếu vậy, tại sao nó là trường hợp? Có bằng chứng nào cho việc vẫy tay không?

complexity-theory time-complexity intuition

— Kaveh
nguồn

"Tỷ lệ thuận" có ý nghĩa toán học cụ thể có nghĩa là, về cơ bản là thời gian tuyến tính. Nói cách khác, nếu đầu vào của bạn có kích thước , nếu thời gian tỷ lệ thuận trực tiếp thì thuật toán sẽ chạy theo thời gian . Tôi tưởng tượng đó không phải là ý bạn, vì nhiều thuật toán không chạy trong thời gian tuyến tính, tức là sắp xếp. Bạn có thể giải thích thêm?

n

$n$

c n

$cn$

— SamM

Vì vậy, bạn đang hỏi về một thuật toán chạy trong thời gian

có nghĩa là thuật toán chạy cùng lúc bất kể kích thước đầu vào,

có nghĩa là thuật toán chạy nhanh hơn khi đầu vào lớn hơn. Tôi không thể nghĩ ra cái nào chạy trong thời gian đó ngoài đỉnh đầu, nhưng ký hiệu khá phổ biến vì thuật toán thường sẽ chạy trong một cái gì đó như thời gian

- nói cách khác , phải mất

o (1)

$o(1)$

O (1)

$O(1)$

o (1)

$o(1)$

O (n^{2}) + o (1)

$O(n^2) + o(1)$

O (n^{2})

$O(n^2)$ thời gian, và có một số thuật ngữ khác phát triển nhỏ hơn khi đầu vào trở nên lớn hơn.

— SamM

Câu hỏi hay. Điều gì về ví dụ ngược của việc tính toán các yếu tố chính của

đối với một số

lớn (đây chỉ là một hàm tăng cho

)? @Sam Lưu ý rằng một hàm tăng nói rằng thời gian phải giảm tại một số điểm dọc theo đường thẳng thực (tức là

c / n

$c / n$

c

$c$

n \geq c

$n \geq c$

f (b) < f (a), a < b

$f(b) < f(a), a < b$

— Casey Kuball

@Darthfett Tôi sợ tôi không theo dõi. Không phải tất cả các chức năng tăng đang giảm tại một số điểm dọc theo đường thực.

— SamM

@Jennifer Vâng, tôi hiểu, điều đó có ý nghĩa. Tôi khuyên bạn nên sử dụng thuật ngữ

vì nó có nghĩa là bạn đang tìm kiếm. Và tôi muốn nhấn mạnh lại rằng tỷ lệ trực tiếp ngụ ý tuyến tính; Tôi thấy những gì bạn đang nhận được nhưng nó có thể gây nhầm lẫn cho những người lần đầu tiên đọc câu hỏi.

o (1)

$o(1)$

— SamM

Câu trả lời:

Có phải trong trường hợp độ phức tạp thời gian luôn là một hàm tăng trong kích thước đầu vào? Nếu vậy, tại sao nó là trường hợp?

Không. Hãy xem xét một máy Turing tạm dừng sau bước khi kích thước đầu vào chẵn và dừng sau bước khi là số lẻ. $n$ $n$ $n^2$ $n$

Nếu bạn có nghĩa là sự phức tạp của một vấn đề , câu trả lời vẫn là không. Độ phức tạp của kiểm tra tính nguyên thủy nhỏ hơn nhiều đối với các số chẵn so với các số lẻ.

— JeffE
nguồn

Có phải trong trường hợp độ phức tạp thời gian luôn là một hàm tăng trong kích thước đầu vào? Nếu vậy, tại sao nó là trường hợp? Có bằng chứng nào cho việc vẫy tay không?

Gọi là kích thước đầu vào. Để đọc toàn bộ đầu vào, một máy turing đã cần bước. Vì vậy, nếu bạn cho rằng một thuật toán phải đọc toàn bộ đầu vào (hoặc cho một số hằng số ), bạn sẽ luôn kết thúc với ít nhất thời gian chạy tuyến tính. $n$ $n$ $n/c$ $c$

Vấn đề với việc xác định các thuật toán với "hàm thời gian chạy giảm đơn điệu" là, bạn phải xác định thời gian chạy cho bằng cách nào đó. Bạn phải đặt nó thành một số giá trị hữu hạn . Nhưng có vô số giá trị có thể có cho , vì vậy bạn kết thúc với một hàm không đổi cho vô số giá trị. $n = 1$ $n > 1$

Có lẽ các thuật toán tuyến tính là mối quan tâm của bạn, không đọc toàn bộ đầu vào. Xem ví dụ: http://www.dcs.warwick.ac.uk/~czumaj/PUBLICATION/DRAFTS/Sublinear-time-Survey-BEATCS.pdf .

— Christopher
nguồn

Có tồn tại các thuật toán tuyến tính. Ví dụ: xem people.csail.mit.edu/ronitt/sublinear.html . Đó là một lĩnh vực mới hợp lý nhưng nó rất thú vị. Có những phản ứng khác cho điều này. Việc tìm một phần tử được đưa ra một danh sách được sắp xếp sẽ mất thời gian

trong mô hình RAM. Tôi đồng ý với ý tưởng đằng sau bài viết của bạn. Sẽ không có nghĩa khi có một thuật toán mất ít thời gian hơn vì đầu vào trở nên lớn hơn bởi vì nó không có thời gian để đọc tất cả các đầu vào (làm thế nào để biết nó mất ít thời gian hơn?). Nhưng tôi không biết làm thế nào để chứng minh rằng họ không tồn tại, và rằng một thủ thuật không thể làm cho nó

O (\log n)

$O(\log n)$

o (1)

$o(1)$

— SamM

@Sam: Xin lỗi, tôi không thấy bình luận của bạn trước khi chỉnh sửa (thêm thuật toán tuyến tính).

— Christopher

hoàn toàn ngược lại; Tôi không thấy chỉnh sửa của bạn trước khi thêm nhận xét của tôi. Tôi sẽ xóa nó nhưng nửa thứ hai vẫn được áp dụng và một liên kết bổ sung không thể làm tổn thương OP

— SamM

một ví dụ mẫu: một hàm hằng như

. Những gì bạn mô tả hoạt động cho các chức năng cần đọc đầu vào của họ.

f (x) = 0

$f(x)=0$

— Kaveh

$(\mathbb{N},\leq)$ $\Omega(1)$

Điều đó nói rằng, thời gian chạy trung bình có thể chứa các thành phần dao động, ví dụ Mergesort .

— Raphael
nguồn

Tôi không thấy câu trả lời này liên quan đến câu hỏi như thế nào.

— A.Schulz

@ A.Schulz Nó đưa ra một bằng chứng cho câu hỏi chính "Có phải trường hợp độ phức tạp thời gian luôn là một hàm tăng trong kích thước đầu vào không?", Đọc "tăng" là "không giảm", nghĩa là không nhất thiết phải tăng một cách nghiêm ngặt.

— Raphael

\neq

$\not=$

@ A.Schulz: Tuy nhiên, sự giải thích của tôi dường như là điều Jennifer quan tâm .

— Raphael