Khi nào (hoặc nên) CS lý thuyết quan tâm đến bằng chứng trực giác?

Từ những gì tôi hiểu (rất ít, vì vậy xin vui lòng sửa cho tôi biết tôi sai ở đâu!), Lý thuyết về ngôn ngữ lập trình thường liên quan đến các bằng chứng "trực giác". Theo cách hiểu của riêng tôi, cách tiếp cận đòi hỏi chúng ta phải thực hiện nghiêm túc các hậu quả của tính toán đối với logic và khả năng chứng minh. Một bằng chứng không thể tồn tại trừ khi có một thuật toán xây dựng hậu quả từ các giả thuyết. Chẳng hạn, chúng ta có thể từ chối như một tiên đề của nguyên tắc trung gian bị loại trừ, vì nó thể hiện một số đối tượng, đó là hoặc , không có cấu trúc.¬ $X$$\lnot X$

Các triết lý trên có thể khiến chúng ta thích các bằng chứng có giá trị trực giác hơn các bằng chứng không có. Tuy nhiên, tôi chưa thấy bất kỳ mối quan tâm nào về việc thực sự sử dụng logic trực giác trong các bài báo trong các lĩnh vực khác của CS lý thuyết. Chúng tôi có vẻ hạnh phúc để chứng minh kết quả của chúng tôi bằng cách sử dụng logic cổ điển. Ví dụ, người ta có thể tưởng tượng sử dụng nguyên tắc của loại trừ giữa để chứng minh rằng thuật toán là chính xác. Nói cách khác, chúng tôi quan tâm và thực hiện nghiêm túc một vũ trụ bị giới hạn tính toán trong kết quả của chúng tôi, nhưng không nhất thiết là bằng chứng của chúng tôi về những kết quả này.

1. Các nhà nghiên cứu trong CS lý thuyết có bao giờ lo lắng về việc viết bằng chứng trực giác hợp lệ không? Tôi có thể dễ dàng tưởng tượng ra một lĩnh vực của khoa học máy tính lý thuyết tìm cách hiểu khi kết quả TCS, đặc biệt là các thuật toán, nắm giữ logic trực giác (hoặc thú vị hơn, khi chúng không). Nhưng tôi chưa đi qua bất kỳ.

2. Có bất kỳ lập luận triết học nào mà họ nên? Có vẻ như người ta có thể tuyên bố rằng các kết quả khoa học máy tính phải được chứng minh bằng trực giác khi có thể, và chúng ta nên biết kết quả nào yêu cầu, ví dụ như PEM. Có ai đã cố gắng để đưa ra một lập luận như vậy? Hoặc có lẽ có một sự đồng thuận rằng câu hỏi này không quan trọng lắm?

3. Là một câu hỏi phụ, tôi tò mò muốn biết các ví dụ về các trường hợp thực sự có vấn đề: Có kết quả TCS quan trọng nào được biết trong logic cổ điển nhưng không phải là logic trực giác? Hoặc nghi ngờ không giữ trong logic trực giác.

Xin lỗi vì sự mềm mại của câu hỏi! Nó có thể yêu cầu viết lại hoặc diễn giải lại sau khi nghe các chuyên gia.

Như tôi đã nói trong các ý kiến, logic trực giác không phải là điểm chính. Điểm quan trọng hơn là có một bằng chứng xây dựng. Tôi nghĩ lý thuyết loại của Martin-Löf phù hợp với lý thuyết ngôn ngữ lập trình hơn logic logic trực giác và có những chuyên gia cho rằng công việc của Martin-Löf là lý do chính cho sự hồi sinh của mối quan tâm chung trong toán học xây dựng.

Việc giải thích khả năng tính toán của tính xây dựng là một viễn cảnh có thể, nhưng nó không phải là quan điểm duy nhất. Chúng ta nên cẩn thận ở đây khi chúng ta muốn so sánh bằng chứng xây dựng với bằng chứng cổ điển. Mặc dù cả hai có thể sử dụng cùng một biểu tượng, ý nghĩa của những biểu tượng đó là khác nhau.

Luôn luôn tốt để nhớ rằng bằng chứng cổ điển có thể được dịch thành bằng chứng trực giác. Nói cách khác, theo một nghĩa nào đó, logic cổ điển là một hệ thống con của logic trực giác. Do đó, bạn có thể nhận ra (nói sử dụng các hàm tính toán) bằng chứng cổ điển theo một nghĩa nào đó. Mặt khác, chúng ta có thể nghĩ toán học xây dựng như một số hệ thống toán học trong bối cảnh cổ điển.

Cuối cùng, các hình thức, cho dù cổ điển hay xây dựng, là công cụ để chúng tôi thể hiện các tuyên bố. Lấy một định lý cổ điển và cố gắng chứng minh nó một cách xây dựng mà không có quan điểm này không có ý nghĩa gì nhiều IMHO. Khi tôi nói cách cổ điển tôi có nghĩa là một cái gì đó khác với những gì tôi nói A ∨ B một cách xây dựng. Bạn có thể tranh luận gì "nên" được ý nghĩa thực sự của " ∨ " nhưng tôi nghĩ đó không phải là thú vị nếu chúng ta không thảo luận về những gì chúng tôi muốn thể hiện ở nơi đầu tiên. Chúng tôi có nghĩa là (ít nhất) một trong số họ nắm giữ và chúng tôi biết cái nào? Hay chúng ta chỉ đơn giản có nghĩa là một trong số họ nắm giữ?$A \lor B$$A \lor B$$\lor$

Giờ đây, với quan điểm này, nếu chúng ta muốn chứng minh một tuyên bố như và chúng tôi muốn liên hệ này cho một ánh xạ từ x đến một số y thỏa mãn φ ( x , y ) thì cách tốt hơn để thể hiện có thể là cách xây dựng. Mặt khác, nếu chúng ta chỉ quan tâm đến sự tồn tại của y và không quan tâm đến cách tìm ra chúng thì cách cổ điển có lẽ sẽ có ý nghĩa hơn. Khi bạn chứng minh câu lệnh một cách xây dựng, bạn cũng đang ngầm xây dựng một thuật toán để tìm y từ $\forall x \ \exists y \ \varphi(x,y)$$x$$y$$\varphi(x,y)$$y$$y$$x$. Bạn có thể làm điều tương tự một cách rõ ràng với một công thức phức tạp hơn như "thuật toán có tài sản đó cho tất cả x , φ ( x , A ( x ) ) ", nơi Một là một số thuật toán được một cách rõ ràng. Nếu không rõ lý do tại sao người ta có thể thích cách xây dựng này để diễn đạt điều này, hãy nghĩ về ngôn ngữ lập trình như một sự tương tự: bạn có thể viết chương trình cho thuật toán MST của Kruskal bằng ngôn ngữ lắp ráp x86 trong đó bạn phải quan tâm đến nhiều vấn đề phụ hoặc bạn có thể viết một chương trình bằng Python.$A$$x$$\varphi(x,A(x))$$A$

Bây giờ tại sao chúng ta không sử dụng logic trực giác trong thực tế? Có một số lý do. Ví dụ, hầu hết chúng ta không được đào tạo với thiết lập tâm trí đó. Ngoài ra, việc tìm một bằng chứng cổ điển của một tuyên bố có thể dễ dàng hơn nhiều so với việc tìm một bằng chứng mang tính xây dựng của nó. Hoặc chúng ta có thể quan tâm đến các chi tiết cấp thấp bị ẩn và không thể truy cập trong cài đặt mang tính xây dựng (xem thêm logic tuyến tính ). Hoặc đơn giản là chúng ta có thể không quan tâm đến việc có thêm những thứ đi kèm với một bằng chứng mang tính xây dựng. Và mặc dù có các công cụ để trích xuất các chương trình từ bằng chứng, các công cụ này thường cần bằng chứng rất chi tiết và không đủ thân thiện với người dùng cho lý thuyết chung. Tóm lại, quá nhiều nỗi đau cho quá ít lợi ích.

$\Pi^0_2$$PA$$PA$$PA$

Tôi nhớ rằng Douglas S. Bridges trong phần giới thiệu về cuốn sách lý thuyết tính toán của mình đã lập luận rằng chúng ta nên chứng minh kết quả của mình một cách xây dựng. Ông đưa ra một ví dụ mà IIRC về cơ bản như sau:

Giả sử rằng bạn làm việc cho một công ty phần mềm lớn và người quản lý của bạn yêu cầu bạn cho một chương trình để giải quyết vấn đề. Có thể chấp nhận quay lại với hai chương trình và nói với người quản lý của bạn một trong hai giải pháp này một cách chính xác nhưng tôi không biết chương trình nào?

Cuối cùng, chúng ta nên nhớ rằng mặc dù chúng ta sử dụng cùng một biểu tượng cho logic cổ điển và trực giác, những biểu tượng này có ý nghĩa khác nhau, và biểu tượng sử dụng phụ thuộc vào những gì chúng ta muốn thể hiện.

Đối với câu hỏi cuối cùng của bạn, tôi nghĩ rằng định lý Robertson của Seymour sẽ là một ví dụ về một định lý mà chúng ta biết nó đúng theo kinh điển nhưng chúng ta không có bất kỳ bằng chứng xây dựng nào về nó. Xem thêm

• Có bằng chứng tồn tại thuật toán không xây dựng?

Thật đáng suy nghĩ về lý do TẠI SAO logic trực giác là logic tự nhiên cho tính toán, vì tất cả mọi người quá thường xuyên bị lạc trong các chi tiết kỹ thuật và không nắm bắt được bản chất của vấn đề.

Rất đơn giản, logic cổ điển là logic của thông tin hoàn hảo: tất cả các câu lệnh trong hệ thống được coi là được biết hoặc có thể biết là đúng hoặc sai rõ ràng.

Mặt khác, logic trực giác có chỗ cho các phát biểu với các giá trị chân lý chưa biết và không thể biết được. Điều này rất cần thiết cho việc tính toán, vì, do tính không ổn định của việc chấm dứt trong trường hợp chung, sẽ không phải lúc nào cũng chắc chắn giá trị thật của một số câu sẽ là gì, hoặc thậm chí có thể gán giá trị thật cho một số câu nhất định hay không .

$\neg\neg P \implies P$

Theo tôi, những lý do "ngữ nghĩa" này là một động lực quan trọng hơn nhiều cho việc sử dụng logic trực giác để tính toán hơn bất kỳ lý do kỹ thuật nào khác mà người ta có thể thống trị.

Các hàm băm mật mã trong thế giới thực như MD5 & SHA là không cần thiết. Như vậy, việc áp dụng các kỹ thuật từ mật mã lý thuyết đến lý do về bảo mật của chúng là khá khó khăn. Lý do đơn giản tại sao: đối với bất kỳ hàm băm không khóa nào, tồn tại một chương trình / đối thủ rất nhỏ tạo ra xung đột dưới hàm băm đó; cụ thể là, một chương trình có sự va chạm như vậy - phải tồn tại! - mã hóa cứng.

Bài viết của Phil Rogaway Chính thức hóa sự thiếu hiểu biết của con người: Băm chống va chạm mà không cần chìa khóa giải quyết vấn đề này. Trong đó, ông chỉ ra rằng một số định lý rất chuẩn cho các hàm băm có khóa (như mô hình xây dựng và băm ký hiệu Merkle-Damgård) có thể được điều chỉnh và chứng minh lại bằng các câu lệnh định lý "thân thiện với trực giác" áp dụng cho các hàm băm không khóa.

đây là một chương hay về Logic trực giác từ một cuốn sách trực tuyến toàn diện Logic cho khoa học máy tính , 300 trang. [1] giây 9.5, p210, tóm tắt về p220:

Logic trực giác nảy sinh từ phong trào kiến ​​tạo trong toán học đã bác bỏ các bằng chứng tồn tại phi xây dựng hoặc dựa trên luật của trung gian bị loại trừ. Gần đây, một kết nối giữa toán học trực quan và lập trình đã ra khỏi quan sát rằng các mệnh đề và các loại (theo nghĩa lập trình) là tương đương. Phát triển thuật toán trong hệ thống chính thức này, dựa trên suy luận tự nhiên, bao gồm viết một đặc tả theo ký hiệu logic và sau đó, coi đây là một loại, chứng minh rằng nó không trống. Bởi vì logic cơ bản là mang tính xây dựng, nếu nó có thể được thực hiện,

một viễn cảnh khác gần đó đến từ TCSist Andrej Bauer viết về "Toán học và tính toán; toán học cho máy tính" [2], người đề xuất về cơ bản rằng "toán học trực giác tốt cho vật lý". bài thuyết trình chủ yếu là về mặt vật lý, nhưng đối với những người coi CS kết hợp chặt chẽ với vật lý, thì hệ tư tưởng nói chung sẽ mang đến TCS.

Giải thích tính toán. Đây là cách giải thích logic trực giác thường được trình bày trong khoa học máy tính. Chúng tôi xem tất cả các bộ như được đại diện bởi các cấu trúc dữ liệu phù hợp. Quan điểm hợp lý cho một nhà khoa học máy tính. Sau đó, một tuyên bố được đưa ra là đúng nếu có một chương trình (bằng chứng tính toán) chứng kiến ​​sự thật của nó.

[1] Logic cho khoa học máy tính, Reeves và Clark

[2] Toán học trực giác cho vật lý Bauer