Có bất kỳ vấn đề nào trở nên dễ dàng hơn khi chúng tăng kích thước không?

62

Đây có thể là một câu hỏi lố bịch, nhưng liệu có thể có một vấn đề thực sự trở nên dễ dàng hơn khi các đầu vào tăng kích thước? Tôi nghi ngờ bất kỳ vấn đề thực tế nào là như thế này, nhưng có lẽ chúng ta có thể phát minh ra một vấn đề thoái hóa có tính chất này. Chẳng hạn, có lẽ nó bắt đầu "tự giải quyết" khi nó lớn hơn, hoặc hành xử theo một cách kỳ quái khác.

algorithms asymptotics

— DSaxton
nguồn

7

Một vấn đề thực sự với tài sản này xuất hiện trong tâm trí là bẻ khóa mật khẩu không được bẻ khóa khi nó được xây dựng giống như hàm băm đưa ra, bẻ khóa ít nhất một hàm băm. Vì tốc độ bẻ khóa sẽ chia tỷ lệ tuyến tính với n, thời gian chạy sẽ tỷ lệ thuận với 1 / n - ngoại trừ việc chúng ta thực sự không thể chỉ định thời gian xác định vì việc bẻ khóa là ngẫu nhiên và không có giới hạn trên không đổi theo thời gian.

— amon

1

@amon Thời gian chạy không quy mô như . Phải mất thời gian để đọc băm mà bạn đã đưa ra làm đầu vào!

1 / n

$1/n$

n

$n$

n

$n$

— David Richerby

3

Bạn có nghĩa là dễ dàng hơn trong điều khoản tuyệt đối hoặc tương đối? Những biện pháp chi phí nào bạn cho phép? Bạn có yêu cầu giảm chi phí nghiêm ngặt, hoặc không tăng (từ một số điểm trở đi) là đủ?

— Raphael

2

@DavidR Richby Trong ví dụ này, việc bỏ qua chi phí đọc đầu vào là hợp pháp miễn là tôi không đưa ra bất kỳ tuyên bố nào về chi phí tuyệt đối. Thay vào đó, tốc độ tăng tuyến tính với đầu vào. Do đó, n • T (1)> T (n) ngay cả khi xem xét chi phí đọc đầu vào. Tức là đối với vấn đề này, việc giải quyết một đầu vào lớn cùng một lúc sẽ dễ dàng hơn thay vì chia nhỏ đầu vào, mặc dù vấn đề là chia hết. Tôi không nói rằng T (n)> T (n + 1) cho tất cả n.

— amon

4

Đối với tất cả những người muốn đăng một câu trả lời khác của biểu mẫu, "Một số vấn đề trong đó đầu vào là một câu hỏi cộng với một loạt các gợi ý về câu trả lời": Điều này không hoạt động. Đầu vào khó nhất của độ dài là những đầu vào mà bạn sử dụng tất cả bit để đặt câu hỏi và không đưa ra gợi ý nào. Thực tế là dễ dàng xử lý các câu hỏi ngắn với nhiều gợi ý không có nghĩa là thời gian chạy trong trường hợp xấu nhất là tốt.

n

$n$

n

$n$

— David Richerby

39

Không, điều đó là không thể: ít nhất, không phải theo nghĩa không có triệu chứng, nơi bạn yêu cầu vấn đề để tiếp tục trở nên dễ dàng hơn, mãi mãi, như . $n \to \infty$

Đặt là thời gian chạy tốt nhất có thể để giải quyết vấn đề như vậy, trong đó là kích thước của đầu vào. Lưu ý rằng thời gian chạy là một số lượng các lệnh được thực hiện bởi thuật toán, vì vậy nó phải là một số nguyên không âm. Nói cách khác, cho tất cả . Bây giờ nếu chúng ta xem xét một hàm , chúng ta thấy không có hàm nào bị giảm đơn điệu. (Dù là gì, nó phải là hữu hạn, giả sử ; nhưng sau đó vì giảm đơn điệu, và $T(n)$ $n$ $T(n) \in \mathbb{N}$ $n$ $T: \mathbb{N} \to \mathbb{N}$ $T(0)$ $T(0)=c$ $T$ $T(c) \le 0$ $T(c+1) \le -1$ , điều này là không thể.) Vì những lý do tương tự, không có chức năng nào giảm nghiêm trọng về mặt triệu chứng: chúng ta có thể chứng minh tương tự rằng không có chức năng thời gian chạy trong đó tồn tại sao cho tất cả , đang giảm nghiêm trọng về mặt đơn điệu (bất kỳ chức năng nào như vậy sẽ phải trở thành tiêu cực). $T(n)$ $n_0$ $n \ge n_0$ $T(n)$

Vì vậy, một vấn đề như vậy không thể tồn tại, vì lý do đơn giản là thời gian chạy phải là số nguyên không âm.

Lưu ý rằng câu trả lời này chỉ bao gồm các thuật toán xác định (nghĩa là thời gian chạy trong trường hợp xấu nhất). Nó không loại trừ khả năng các thuật toán ngẫu nhiên có thời gian chạy dự kiến sẽ giảm dần một cách đơn điệu. Tôi không biết liệu có thể tồn tại một thuật toán như vậy không. Tôi cảm ơn Beni Cherniavsky-Paskin vì sự quan sát này .

— DW
nguồn

9

Đây là một bằng chứng tốt đẹp, nhưng tôi không đồng ý với tiền đề. Thay vì yêu cầu thời gian chạy giảm dần đơn điệu, câu hỏi có thể hợp lý hơn là yêu cầu một hàm tồn tại a, b với <b sao cho T (a)> T (b), tức là giảm không đơn điệu. Sau đó, tất nhiên có thể tìm thấy các hàm số nguyên phù hợp. Nhưng tại sao số nguyên? Tôi có ấn tượng rằng thời gian chạy biểu thị một thời gian, không phải là số lệnh (tất nhiên trừ máy Turing) và biểu thức T có thể sử dụng các phép toán không nguyên như log () hoặc số mũ không nguyên.

— amon

2

@amon "thời gian chạy biểu thị một thời gian, không phải là số chỉ dẫn" Hoàn toàn không. Thời gian chạy luôn là một chỉ dẫn. Bất cứ điều gì khác sẽ không thể lý giải vì nó sẽ phụ thuộc vào rất nhiều chi tiết thực hiện.

— David Richerby

3

Như mơ hồ như câu hỏi, tôi không thấy nó loại trừ hàm chi phí của, giả sử, . Bây giờ, nhưng cho "nhỏ" , do đó, vấn đề "trở nên dễ dàng hơn", nói một cách tương đối. (Tất nhiên chi phí tăng trưởng không có triệu chứng).

T (n) = n^{2} \cdot (1 + ϵ)^{- n} + n

$T(n) = n^2 \cdot (1+\epsilon)^{-n} + n$

T (n) \sim n

$T(n) \sim n$

T (n) \approx n^{2}

$T(n) \approx n^2$

n

$n$

— Raphael

2

@Raphael, không phải là vấn đề trở nên dễ dàng hơn: trở nên lớn hơn khi lớn hơn, vì vậy vấn đề trở nên khó khăn hơn khi lớn hơn, khi đủ lớn. Tôi đã nói trong câu đầu tiên của câu trả lời của tôi rằng không có vấn đề có thể tiếp tục trở nên dễ dàng hơn mãi mãi. Tất nhiên, một vấn đề có thể trở nên dễ dàng hơn trong một thời gian ( có thể giảm trong , giả sử), nhưng nó không thể tiếp tục trở nên dễ dàng hơn mãi mãi.

T (n) \sim n

$T(n) \sim n$

T (n)

$T(n)$

n

$n$

n

$n$

n

$n$

T (n)

$T(n)$

n \leq c

$n \le c$

— DW

1

Ngay cả với số nguyên, đối với thuật toán ngẫu nhiên , thời gian dự kiến (hoặc bất kỳ biện pháp phân phối nào khác) có thể là phân số và dần dần có thể tiếp cận một số hằng số từ phía trên. [Điều này không có nghĩa là những vấn đề như vậy thực sự tồn tại, chỉ có điều là đối số "không có chức năng như vậy tồn tại" là không đủ.]

T

$T$

— Beni Cherniavsky-Paskin

25

Mặc dù nó không hoàn toàn là một câu trả lời cho câu hỏi của bạn, thuật toán tìm kiếm chuỗi Boyer-Moore đã đến gần. Như Robert Moore nói trên trang web của mình về thuật toán,

Thuật toán của chúng tôi có thuộc tính đặc biệt, nói một cách đại khái, mẫu càng dài thì thuật toán càng nhanh.

Nói cách khác, nói chung, thuật toán tìm kiếm một thể hiện của chuỗi mục tiêu trong chuỗi nguồn và đối với chuỗi nguồn cố định, chuỗi mục tiêu càng dài thì thuật toán chạy càng nhanh.

— Rick Decker
nguồn

10

Có thể cho rằng, mẫu không phải là kích thước của vấn đề mà thay vào đó là độ dài của chuỗi được tìm kiếm. Như trong nhận xét của David Richerby ở trên , tôi sẽ cho rằng độ dài của mẫu có nhiều gợi ý về cách giải quyết vấn đề (nhận về việc tìm kiếm chuỗi) so với chính vấn đề (xem mẫu có khớp với chuỗi có độ dài cụ thể không .)

— Kevin

4

\sqrt{n}

$\sqrt{n}$

n

$n$

\log n

$\log n$

10

Rõ ràng, từ quan điểm toán học thuần túy, thuần túy của thuật toán CS, điều này là không thể. Nhưng trên thực tế, có một số ví dụ trong thế giới thực khi mở rộng dự án của bạn sẽ giúp việc này dễ dàng hơn, nhiều ví dụ không trực quan cho người dùng cuối.

Chỉ đường : chỉ đường của bạn càng dài, đôi khi chúng có thể trở nên dễ dàng hơn. Ví dụ, nếu tôi muốn Google Maps để cho tôi hướng cho đi về hướng tây 3000 dặm, tôi có thể lái xe đến bờ biển phía Tây - và sẽ nhận được hướng dẫn lái xe xuyên quốc gia. Nhưng nếu tôi muốn đi 6000 dặm về phía tây, tôi sẽ kết thúc với các hướng dẫn đơn giản hơn đáng kể: có được trên một chiếc máy bay từ New York đến Hokkaido. Cung cấp cho tôi một tuyến đường xuyên quốc gia kết hợp giao thông, đường bộ, thời tiết, v.v ... khá khó khăn về mặt thuật toán, nhưng việc bảo tôi lên máy bay và tìm kiếm các chuyến bay trong cơ sở dữ liệu tương đối đơn giản hơn đáng kể. Biểu đồ ASCII về độ khó so với khoảng cách:

           |     /
           |    /
Difficulty |   /                  ____-------
           |  /           ____----
           | /    ____----
            ---------------------------------
                       Distance

Kết xuất : giả sử tôi muốn kết xuất một mặt và kết xuất 1000 mặt; đây là cho một quảng cáo biển quảng cáo để cả hai hình ảnh cuối cùng phải là 10000px x 5000px. Hiển thị một mặt thực tế sẽ khó - ở độ phân giải vài nghìn pixel trên toàn bộ bạn phải sử dụng các máy thực sự mạnh mẽ - nhưng đối với đám đông 1000 khuôn mặt, mỗi mặt chỉ cần có mười pixel và có thể dễ dàng được nhân bản! Tôi có thể có thể hiển thị 1000 khuôn mặt trên máy tính xách tay của mình, nhưng việc hiển thị một khuôn mặt thực tế 10000px sẽ mất rất nhiều thời gian và máy móc mạnh mẽ. Biểu đồ độ khó của ASCII so với các đối tượng được hiển thị, cho thấy mức độ khó của việc hiển thị n đối tượng thành hình ảnh có kích thước được đặt giảm nhanh chóng nhưng sau đó quay lại chậm:

           | -    
           |- -                     _________
Difficulty |   --      ______-------            
           |     ------      
           |       
            ---------------------------------
                        Objects

Kiểm soát phần cứng : nhiều thứ với phần cứng trở nên dễ dàng hơn nhiều. "Di chuyển động cơ X 1 độ" là khó khăn và / hoặc không thể, và bạn phải đối phó với tất cả các loại việc mà bạn sẽ không phải đối phó với "di chuyển động cơ X 322 độ".

Nhiệm vụ trong thời gian ngắn: Giả sử bạn muốn mục X được bật (lượng thời gian rất nhỏ) mỗi giây. Bằng cách tăng lượng thời gian mà X chạy, bạn sẽ cần phần mềm cũng như phần cứng ít phức tạp hơn.

— Owen Versteeg
nguồn

Trong ví dụ "chỉ đường" của bạn, vui lòng nêu chính xác vấn đề tính toán là gì và ví dụ là gì. Nó không phải ở tất cả rõ ràng với tôi rằng 6k dặm ví dụ của bạn là một ví dụ lớn hơn hay chỉ là một ví dụ về một bộ phận không dễ dàng của một cái gì đó (ví dụ, nếu tôi cung cấp cho bạn một biểu đồ kết nối graph lớn cộng với một đỉnh cô lập, yêu cầu cho con đường ngắn nhất nói chung là "Khó" nhưng yêu cầu một con đường ngắn nhất từ đỉnh bị cô lập đến bất cứ nơi nào là tầm thường). Một lần nữa, cho ví dụ kết xuất của bạn, vấn đề tính toán thực tế là gì? Ví dụ mà bạn đang đo độ phức tạp là gì?

— David Richerby

Ví dụ kết xuất dường như không phải là trường hợp của cùng một vấn đề: điều đầu tiên là kết xuất một hình ảnh duy nhất; cái thứ hai là hiển thị nhiều hình ảnh nhỏ và sau đó dán nhiều bản sao của những hình ảnh đó vào một số khu vực.

— David Richerby

Tôi nghĩ rằng wrt để di chuyển các tham số sẽ là tên của 2 thành phố và n sẽ là số lượng ký tự để mã hóa chúng.

— emory

3

Có trường hợp. Chúng là những trường hợp mà tiêu chí thành công là một chức năng của dữ liệu, thay vì cố gắng tìm một câu trả lời duy nhất. Ví dụ, các quy trình thống kê có kết quả được thực hiện theo các khoảng tin cậy có thể trở nên dễ dàng hơn.

Một trường hợp cụ thể mà tôi nghĩ đến là các vấn đề có sự chuyển đổi từ các hành vi rời rạc sang các hành vi liên tục, như dòng chảy chất lỏng. Giải quyết vấn đề nhỏ trong một mức độ lỗi có thể liên quan đến việc mô hình hóa tất cả các tương tác riêng biệt, có thể yêu cầu một siêu máy tính. Các hành vi liên tục thường cho phép đơn giản hóa mà không mang lại kết quả bên ngoài một lỗi liên quan bị ràng buộc.

— Corton
nguồn

2

Câu hỏi rất thú vị và HỮU ÍCH, bởi vì triết lý của chúng tôi về tin học là giải quyết các vấn đề chúng ta càng đọc nhiều thì càng khó hiểu. Nhưng, trên thực tế, MOST của các vấn đề được trình bày theo cách điển hình (khó) có thể dễ dàng được trình bày theo cách "dễ dàng"; ngay cả khi biết phản hồi của DW (sai lầm khi cho rằng dễ dàng không có nghĩa là nhanh hơn, có nghĩa là "chậm hơn"; vì vậy bạn không phải tìm thời gian tiêu cực, bạn phải tìm thời gian không có triệu chứng).

Mẹo để tìm một là đặt một phần của giải pháp như gợi ý làm mục, và xem xét mục nhập của vấn đề như một tham số không đổi.

Ví dụ: Con đường dài nhất trong ô tô giữa Luân Đôn và Paris tránh đi hai lần một thị trấn của Pháp và Anh và không đến thăm quốc gia khác là gì? Hãy cân nhắc, bạn phải đến Birmingham trước Ashford, Orleans trước Versailles, La Rochelle trước Limoge, v.v ...

Rõ ràng là vấn đề này với các mục dài sẽ dễ dàng hơn với các mục ngắn.

Ví dụ về việc sử dụng: Hãy tưởng tượng một trò chơi do máy quản lý và IA của máy tính phải xác định xem anh ta có phải khám phá thêm trong trò chơi để tìm thêm gợi ý hay không, nếu bây giờ là lúc đưa ra quyết định tốt nhất để đưa ra quyết định nào .

— Juan Manuel Dato
nguồn

2

Ví dụ của bạn không hoạt động. Các thực thể lớn bởi vì chúng có rất nhiều gợi ý mà các gợi ý xác định thứ tự tuyến tính của các đỉnh của đồ thị thực sự dễ dàng. Tuy nhiên, các trường hợp lớn vì chúng đưa ra một biểu đồ lớn mà hầu như không có gợi ý nào cũng khó như bài toán đường dẫn Hamilton thông thường. Do đó, thời gian chạy trường hợp xấu nhất của bất kỳ thuật toán nào giải quyết được vấn đề này sẽ ít nhất là tồi tệ như thời gian chạy trường hợp xấu nhất của thuật toán tốt nhất cho đường dẫn Hamilton, dường như không phải là "siêu dễ dàng".

— David Richerby

@David, phản hồi của bạn là hoàn toàn không chính xác: 1. Mục nhập không phải là biểu đồ: biểu đồ lớn là PARAMETER. Vì vậy, vấn đề hamiltonian được chuyển đổi thành một hằng số (rất lớn, nhưng không đổi). 2. Mục nhập là giải pháp của vấn đề, vì vậy: nếu lớn hơn, bạn đang đưa ra một khám phá kết hợp gợi ý. Một mục nhập của một gợi ý giúp đỡ, hai gợi ý gấp đôi, ba gợi ý sẽ gần với 4 twice ..., bởi vì bạn đang loại bỏ các giải pháp có thể. Vì vậy, đây không phải là người Hamilton, đây là một giải pháp từ một biểu đồ đặc biệt và vấn đề là phải làm gì với các phần của giải pháp.

— Juan Manuel Dato

Tôi nghĩ rằng tranh luận của bạn rất thú vị vì các trường hợp lớn hơn "dễ hiểu" hơn, nhưng tôi nghĩ câu trả lời cho câu hỏi ban đầu cuối cùng là "không". Vì đồ thị là hữu hạn, do đó, chỉ có rất nhiều gợi ý có thể có. Do đó, mọi trường hợp có thể được giải quyết trong thời gian không đổi (ví dụ: sử dụng bảng tra cứu). Mặc dù các trường hợp lớn hơn (theo trực giác) dễ dàng hơn trong quan điểm khoa học máy tính (không triệu chứng), tất cả các trường hợp đều khó như nhau (có thể giải quyết trong thời gian không đổi).

— Tom van der Zanden

@Tom, tôi đồng ý rằng sự cân nhắc của bạn về sự phức tạp sẽ không đổi, nhưng vấn đề là làm thế nào chúng ta chấp nhận những gợi ý mới: nếu với triết lý tính toán mục dài của chúng ta không tốt hơn một mục ngắn, thì chúng ta phải thay đổi triết lý của mình - bởi vì đó là một thực tế: các mục dài ngụ ý các vấn đề dễ dàng hơn. Vì vậy, chúng tôi không thể làm việc theo cách đó ... Tôi muốn giới thiệu cuốn sách của mình, nhưng tôi không có tiếng tăm ...

— Juan Manuel Dato

n \log n

$n\log n$

1

Hãy xem xét một chương trình lấy đầu vào là những gì bạn biết về mật khẩu và sau đó cố gắng bẻ khóa nó. Tôi nghĩ rằng điều này làm những gì bạn muốn. Ví dụ:

Không có đầu vào-> Brute force crack trên tất cả các ký hiệu và một từ có độ dài bất kỳ
Độ dài của mật khẩu -> Bắt buộc tất cả các ký hiệu trong một từ có độ dài đó
Biểu tượng có chứa -> Thu nhỏ danh sách các biểu tượng để kiểm tra
...
Biểu tượng có chứa bao gồm nhiều lần xuất hiện và độ dài -> Chỉ tính toán hoán vị
Tất cả các biểu tượng theo đúng thứ tự -> về cơ bản đã tự giải quyết

Tôi nên thêm rằng đây là một mẹo, vì vấn đề được nêu như thế này ngược với kích thước đầu vào. Bạn có thể bỏ qua một lớp trừu tượng và nói rằng kích thước đầu vào lớn không có đầu vào (kiểm tra tất cả các ký hiệu và độ dài của từ) và nhỏ nếu bạn nhập mật khẩu chính xác vào đầu.

Vì vậy, tất cả xuất phát từ mức độ trừu tượng mà bạn cho phép.

— RunOrVeith
nguồn

2

b

$b$

0

Trên thực tế, tôi có một vấn đề trở nên nhỏ hơn khi dữ liệu tăng lên. Một trong những ứng dụng của tôi ghi lại các thuộc tính của một sản phẩm cụ thể, nói là phô mai. Các thuộc tính là CheeseType, Brand, Country, Area, MilkType, v.v ... Mỗi tháng hoặc lâu hơn, tôi nhận được một danh sách các loại phô mai mới xuất hiện trên thị trường trong thời gian đó, cùng với các thuộc tính của chúng. Bây giờ, những thuộc tính này được gõ bằng tay bởi một nhóm người. Một số người mắc lỗi chính tả hoặc chỉ không biết giá trị cho tất cả các thuộc tính.

Khi bạn thực hiện tìm kiếm trong cơ sở dữ liệu của mình, tôi cố gắng dự đoán từ thống kê xem phô mai có vị như thế nào, dựa trên các thuộc tính này. Điều gì xảy ra, là với mỗi thuộc tính, tôi kết thúc với một loạt các giá trị; một số là hợp lệ một số không hợp lệ. Loại bỏ hoặc sửa những cái không hợp lệ này chỉ có thể nếu tôi có đủ dữ liệu. Đó là về việc tạo ra sự khác biệt giữa giá trị thực và tiếng ồn, mà không loại bỏ các giá trị hiếm nhưng hợp lệ.

Như bạn có thể tưởng tượng, với âm lượng thấp, tiếng ồn quá quan trọng để khắc phục mọi thứ đúng cách. Nếu bạn có 5 trường hợp của Cheddar, 1 của Brie, 1 của Bri và 1 của Chedar, làm thế nào để tôi biết cái nào đúng và cái nào là lỗi đánh máy? Với âm lượng lớn hơn, các lỗi chính tả có xu hướng giữ ở mức rất thấp, nhưng các giá trị hiếm gặp có một vài mức tăng quan trọng, khiến chúng thoát khỏi tiếng ồn (được hỗ trợ bởi kinh nghiệm). Trong trường hợp này, tôi có thể tưởng tượng 50000 Cheddar, 3000 Brie, 5 Bri, 15 Chedar chẳng hạn.

Vì vậy, có, một số vấn đề tự giải quyết cuối cùng, khi bạn có đủ dữ liệu.

— chris
nguồn

1

Điều này thất bại vì lý do thông thường. Một đầu vào lớn có thể là một trong đó mọi người nói với bạn về nhiều loại phô mai khác nhau, thay vì một loại trong đó họ nói với bạn về một vài loại phô mai nhưng một số trong đó đánh vần sai. Ngoài ra, không rõ ràng rằng "dễ dàng hơn" được cho là được hiểu là "cho phép độ tin cậy cao hơn trong kết quả".

— David Richerby

Đây là một vấn đề thực tế (tôi đã có hai lần rồi), không thể giải quyết được với lượng dữ liệu thấp. Nó có thể, và thậm chí còn dễ dàng hơn để phân biệt, các giá trị tốt từ những cái sai, khi âm lượng tăng cao. Nó có giá trị trả lời câu hỏi "Có bất kỳ vấn đề nào trở nên dễ dàng hơn khi chúng tăng kích thước không?" Không quan trọng có bao nhiêu loại phô mai xuất hiện, cuối cùng, với khối lượng đủ lớn, chúng sẽ có nhiều "hit" hơn so với lỗi chính tả. Đây là cs .stackexchange, không phải toán học, vì vậy các vấn đề là khác nhau và việc giải quyết chúng đôi khi chỉ đơn giản là có sự tự tin cao hơn trong kết quả.

— chris

Đây có phải cũng là tiền đề của chương trình truyền hình Số không? Hoặc ít nhất là một số tập phim - tôi biết tôi đặc biệt nhớ lại một cảnh trong đó anh chàng toán học nhận xét rằng thuật toán anh ta sử dụng để giải quyết vấn đề trong tay có hiệu quả hơn với một tập dữ liệu lớn hơn.

— Dan Henderson

2

"Được hiệu quả hơn"! = "Trở nên dễ dàng hơn".

— David Richerby

-1

Hãy xem xét bài toán NP-hoàn thành 3-SAT. Nếu bạn tiếp tục gia tăng vấn đề bằng cách cung cấp các đầu vào có dạng x_i = true / false, cuối cùng bạn sẽ chuyển đổi các bất đồng riêng lẻ thành các mệnh đề hai biến, từ đó tạo ra vấn đề 2-SAT được quyết định là P, hoặc đơn giản là bạn sẽ nhận được một câu trả lời đúng / sai.

Đối với trường hợp có sự dư thừa trong các đầu vào x_i = true / false (cùng một đầu vào được cung cấp nhiều lần hoặc các đầu vào mâu thuẫn), bạn có thể dễ dàng sắp xếp các đầu vào và bỏ qua các giá trị dự phòng hoặc báo cáo lỗi nếu các giá trị mâu thuẫn.

Trong mọi trường hợp, tôi nghĩ rằng điều này đại diện cho một vấn đề 'thực tế', dễ giải quyết hơn khi số lượng đầu vào tăng lên. Khía cạnh 'dễ dàng hơn' là trong việc chuyển đổi một vấn đề hoàn thành NP thành vấn đề P. Bạn vẫn có thể chơi trò chơi hệ thống bằng cách cung cấp các đầu vào vô lý sao cho việc sắp xếp sẽ mất nhiều thời gian hơn so với việc buộc phải xử lý vấn đề.

Bây giờ, một kịch bản thực sự thú vị sẽ là nếu chúng ta sẵn sàng chấp nhận T (0) (sử dụng ký hiệu của DW trong câu trả lời ở trên) có thể là vô hạn. Ví dụ: T (0) có thể tương đương với việc giải quyết vấn đề dừng của Turing. Nếu chúng ta có thể nghĩ ra một vấn đề như việc thêm nhiều đầu vào chuyển đổi nó thành một vấn đề có thể giải quyết được, thì chúng ta đã đạt được vàng. Lưu ý rằng nó không đủ để chuyển đổi nó thành một vấn đề có thể giải quyết được một cách không có triệu chứng - bởi vì điều đó cũng tệ như vũ phu buộc vấn đề.

— vvvvvv
nguồn

1

Những đầu vào cụ thể trở nên dễ dàng hơn. Tuy nhiên, khi bạn xem xét tất cả các đầu vào có thể, 3SAT nói chung sẽ khó hơn đáng kể khi bạn thêm nhiều mệnh đề: đầu vào cứng là những đầu vào không có các mệnh đề "gợi ý" này. Nếu bạn không cho phép các đầu vào chung, bạn cần nêu chính xác những gì bạn cho phép.

— David Richerby

Trước hết: chúng tôi đồng ý rằng việc thêm nhiều đầu vào có thể tăng thời gian chạy. Tôi nói về cơ bản điều tương tự ở trên. Thứ hai, tôi nói rõ rằng chúng tôi đang thi 3-SAT hiện có và chỉ thêm các đầu vào có dạng x_i = true / false. Tôi nghĩ rằng điều này là đủ rõ ràng và tôi không cần phải làm rõ thêm. Tôi nghĩ rằng bạn đang gặp khó khăn để hình thành sự giải thích sai lầm nhất về những gì tôi đã viết. Xin đừng tự làm phiền mình.

— v vv cvvcv

1

Không, nghiêm túc. Bạn đang giải quyết vấn đề tính toán nào? Một vấn đề tính toán là quyết định tư cách thành viên của một chuỗi các chuỗi (giả sử một tập hợp các công thức để tránh những phiền toái về mã hóa). Tập hợp các công thức mà bạn cho rằng việc quyết định xem một công thức dài có trong tập hợp dễ dàng hơn so với việc quyết định rằng một công thức ngắn có trong tập hợp không? Ngay khi bạn cố gắng thực hiện chính xác điều này, tôi khá chắc chắn rằng yêu cầu của bạn sẽ sụp đổ.

— David Richerby

Bạn có thể vui lòng làm rõ sự hiểu biết của bạn về 'yêu cầu của tôi' không? Ngay khi bạn cố gắng thực hiện chính xác điều này, tôi khá chắc chắn rằng bạn sẽ ngừng lãng phí băng thông internet.

— v vv cvvcv

Tôi là một nhà khoa học máy tính, không phải là một người đọc ý nghĩ. Làm cho yêu cầu của bạn chính xác là công việc của bạn, không phải của tôi.

— David Richerby

-1

Câu hỏi đặt ra: "có thể có một vấn đề thực sự trở nên dễ dàng hơn khi các đầu vào tăng kích thước không?" Điều gì xảy ra nếu các đầu vào là các tài nguyên được thuật toán sử dụng để thực hiện công việc. Đó là kiến thức phổ biến rằng càng nhiều tài nguyên càng tốt. Dưới đây là một ví dụ, trong đó càng có nhiều nhân viên thì càng tốt.

$n$
$t$ $p$

$n$

3) Đầu ra:
Đầu ra là các đường dẫn giữa các nhiệm vụ được thực hiện bởi các nhân viên. Mỗi đường dẫn được liên kết với số lượng nhân viên thực hiện nó. Ví dụ:

$n1$
$n2$
$n3$
$n4$
$n5$

4) Giải pháp khả thi:
Một giải pháp khả thi là trước tiên hãy tính đường đi ngắn nhất tới các nút gần nhất từ A. Đây sẽ là đường dẫn chuyển tiếp. Sau đó tính toán đệ quy đường dẫn chuyển tiếp cho từng tác vụ được truy cập. Kết quả là một cái cây. Ví dụ:

          Một
      BC
    DE

$n$ $n1$ $n2$ $n2 \neq 0$

$n=\infty$ $n = 1$

$n$

— yaffitc
nguồn

6

Cảm ơn bạn đã chia sẻ suy nghĩ của bạn. Thông thường trong khoa học máy tính, một thuật toán được hiểu là chấp nhận một chuỗi bit làm đầu vào của nó và xuất ra một chuỗi bit khác. Với sự hiểu biết tiêu chuẩn đó, tôi không thấy câu trả lời này có thể có ý nghĩa như thế nào. Nếu bạn có một khái niệm khác về thuật toán, tôi nghĩ sẽ hữu ích nếu bạn chỉnh sửa câu hỏi để mô tả ý của bạn bằng thuật toán (vì có vẻ như bạn không sử dụng thuật ngữ theo cách sử dụng tiêu chuẩn của hạn, như tôi hiểu nó).

— DW

Đầu vào có thể chỉ đơn giản là một số (số lượng tài nguyên). Điều này sẽ ảnh hưởng đến số lượng tính toán thêm mà thuật toán sẽ phải trải qua. Tôi sẽ chỉnh sửa câu trả lời để cung cấp một ví dụ cụ thể hơn.

— yemelitc

Cảm ơn bạn đã chỉnh sửa - điều đó làm cho nó rõ ràng hơn nhiều. Bây giờ tôi thấy rằng bạn không nhầm lẫn chi phí tính toán giải pháp với chi phí thực hiện nó như tôi nghĩ ban đầu. Nhưng bây giờ chúng ta đang ở trong tình trạng thông thường. Đầu tiên, phải mất ít nhất thời gian tuyến tính để đọc đầu vào. Thứ hai, những trường hợp khó không phải là những trường hợp bạn cho một cây nhỏ và một người mê mẩn mà là nơi bạn cho một cây lớn và tương đối ít người. (Ví dụ: nếu bạn cho phép tôi một triệu bitcoin, tôi sẽ chọn một cây có khoảng một nghìn đỉnh và cung cấp cho bạn năm người, không phải là một cây có năm đỉnh và một nghìn người.)

— David Richerby

Tôi đồng ý. Có vẻ như tất cả chúng ta đã kết thúc khá quan trọng về nó, không giống như những gì câu hỏi ban đầu cám dỗ chúng ta! Nhưng hy vọng bạn hiểu ý tưởng của tôi về 'đầu vào như một nguồn tài nguyên': cho dù công việc có lớn đến đâu, càng nhiều người càng tốt. Vẫn trong một ý nghĩa tiệm cận, bạn chắc chắn đúng, tôi chỉ nên đổ lỗi cho số nguyên không âm.

— yemelitc