Những sai lầm chính trong các giấy tờ FOCS / STOC được chấp nhận [đã đóng]


23

Bạn đã đi qua một dịp như thế trong quá khứ? Vâng, có một khả năng cho tất cả mọi thứ nhưng tôi muốn biết tỷ lệ này có thể thực tế đến mức nào. Tất nhiên, tôi đang đề cập đến những sai lầm nghiêm trọng làm thay đổi mục tiêu của bài báo và không phải là những lỗi nhỏ. Cảm ơn



3
Tôi không muốn làm cho một vấn đề lớn. Nếu Lance đăng nó, điều đó tốt :)
Suresh Venkat

5
@ N27: "Câu hỏi không yêu cầu danh sách các giấy tờ" có, nhưng có một danh sách lớn các lỗi như vậy sẽ hữu ích hơn nhiều. Mặt khác, bình luận của Suresh là kết thúc của câu chuyện, vì nó trả lời câu hỏi trong câu khẳng định. Tôi cũng đề nghị thay đổi FOCS / STOC để cho phép các hội nghị "có uy tín" khác, và thậm chí là các tạp chí.
MS Dousti

6
Tôi hơi ngạc nhiên khi câu hỏi này chưa được đóng lại. Tất cả các ví dụ về những sai lầm như vậy có thể gây bối rối, và chúng tôi có thể xúc phạm các tác giả bằng cách thử lại những sai lầm cũ của họ. Chúng ta nên lịch sự và chuyên nghiệp, và câu hỏi này là một yêu cầu cho những lời lăng mạ. Tôi đang bỏ phiếu để đóng cái này ("lạc đề" chỉ vì thiếu lý do tốt hơn).
Jukka Suomela

4
Tôi đồng ý với Jukka về điều này. Bỏ phiếu ảo để đóng.
Dave Clarke

Câu trả lời:


10
  • Một trường hợp là giấy STOC '88 của Blum-Feldman-Micali's . Lỗ hổng được chỉ ra bởi họ bởi Mihir Bellare (giao tiếp riêng). Bạn có thể tìm thấy các cuộc thảo luận có liên quan ở đây .

  • Các Petri net reachability vấn đề có một lịch sử phong phú, nơi chứng minh không đầy đủ hoặc thiếu sót sau dẫn đến kết quả mới. GS Sacerdote và RL Tenney đã trình bày một bằng chứng quyết định không đầy đủ tại STOC '77 , tuy nhiên là công cụ trong bằng chứng sau này của EW Mayr tại STOC '81 và cải tiến của SR Kosaraju tại STOC '82 . Những bằng chứng có thể quyết định này không đi kèm với giới hạn trên phức tạp (họ sử dụng các thứ tự gần đúng để chấm dứt). Z. Bouziane sau đó tuyên bố đã tìm thấy thuật toán 2ExpSpace tại FOCS '98 . Một lỗ hổng đã được P. Jančar chỉ ra (và cuối cùng được công bố trong một ghi chú), nhưng công việc của Bouziane đã giúp làm mới mối quan tâm vào câu hỏi cũ này. Mặc dù vẫn chưa có giới hạn trên được biết về sự phức tạp của vấn đề này, J. Leroux gần đây đã đưa ra một bằng chứng xác định mới tại POPL '11 .

Không có trong STOC / FOCS:


Một trường hợp khác đã xảy ra trong hội thảo Cấu trúc trong Lý thuyết phức tạp (1988) (Nếu tôi không nhầm, giờ đây nó được gọi là Hội nghị về độ phức tạp tính toán.) Tiêu đề của bài báo là về sức mạnh của các giao thức tương tác đa năng . Hai năm sau, các tác giả (Fortnow, Rompel và Sipser) đã xuất bản một bài báo dài hai trang "Errata for On the Power of Multi-Prover Protocol Protocol" trong cùng một hội nghị. Thật không may, IEEE không cung cấp tài liệu này để tải xuống.


2
@Andras: Vâng. Hơn nữa, luận án của Fortnow bao gồm điều này. @Jukka: Câu trả lời ban đầu của tôi sau đó đã được chỉnh sửa. Tôi không thể nhận xét về câu trả lời được chỉnh sửa, nhưng trong phần câu trả lời tôi đã viết, quan điểm của bạn không áp dụng. Điều này là do những người ban đầu viết bài báo (thiếu sót), sau đó đã chỉ ra những sai sót trong bài báo gốc của họ, và sửa chúng. Do đó, không có vấn đề gì khi đề cập đến chúng ở đây.
MS Dousti

1
@Sadeq: Bạn có nghĩ rằng nếu mọi người đã trải qua sự bối rối khi công bố một kết quả thiếu sót, và sau đó xuất bản một sửa chữa cho sai lầm của họ, họ sẽ rất vui khi thấy sự cố cũ này được xử lý lại và công khai ở đây một lần nữa? Bạn không thấy lý do nào để cẩn thận và cân nhắc hơn một chút ở đây? Tất nhiên là hoàn toàn ổn khi đề cập đến lỗi lầm nếu ai đó có câu hỏi kỹ thuật liên quan đến một vấn đề cụ thể, nhưng trong câu hỏi này, mục tiêu duy nhất dường như là kết hợp một loại hội trường xấu hổ, không vì lý do chính đáng, chỉ để thỏa mãn sự tò mò.
Jukka Suomela

2
Nhưng sau đó toàn bộ câu hỏi này không nên được hỏi, phải không? có lẽ thời gian cho một cuộc thảo luận meta.
Suresh Venkat

2
@Jukka: Tôi đã chỉnh sửa bản chỉnh sửa của mình để nhấn mạnh hơn rằng những kết quả không hoàn hảo này có tác dụng rất tích cực. Nếu bạn nghĩ rằng điều này vẫn gây khó chịu, tôi không ngại xóa các chỉnh sửa của mình.
Sylvain

2
@Suresh: Vâng, tôi nghĩ rằng câu hỏi không nên được hỏi; Tôi đã nhận xét câu hỏi và bỏ phiếu để đóng.
Jukka Suomela
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.