Làm thế nào để bắn hạ bằng chứng của bạn

Hướng dẫn chung để kiểm tra bằng chứng của bạn là gì? Tôi tin rằng điều này rất quan trọng đối với những sinh viên tốt nghiệp như tôi. Tôi đã biết những gì chúng ta cần làm để chứng minh điều gì đó, nhưng bạn luôn phải kiểm tra mọi thứ trước khi gửi đi. Ngay cả để cố vấn của riêng bạn.

Tôi đã tự mình phát triển một số chiến lược bằng cách thử và sai, và nhận được rất nhiều lời khuyên từ cố vấn của tôi. Nhưng đây luôn là một công việc rất tẻ nhạt. Thông thường, khi bạn hoàn thành một việc gì đó, bạn chỉ muốn tiếp tục vấn đề tiếp theo, nhưng bạn vẫn phải bám sát vấn đề hiện tại cho đến khi mọi thứ hoàn hảo. Ở đây tôi trình bày một ví dụ về danh sách các thủ thuật của riêng tôi:

1. Điền vào các chi tiết. Rất nhiều sai lầm ở những nơi bạn đã viết "rõ ràng là ...", "không mất tính tổng quát ...", v.v.
2. Hãy thử một vài con số. Hãy thử các trường hợp cực đoan, như "điều gì xảy ra khi tôi đặt hoặc n = 1000 ".$n=1$$n=1000$
3. Giữ một cuốn sổ tay sạch sẽ. Viết mỗi ngày trên đó, và so sánh nó với các ghi chú thô của bạn. Tôi cố gắng viết cũng bằng latex, tôi đã tìm thấy nhiều sai lầm theo cách này.

Các chiến lược chung mà bạn áp dụng để kiểm tra bằng chứng của bạn là gì?

Mục tiêu của câu hỏi này là biến nó thành một wiki cộng đồng.

Các kỹ sư phần mềm có một khái niệm mà họ gọi là " mùi mã ". Đây là những triệu chứng trong mã có thể chỉ ra một vấn đề sâu sắc hơn. Các kỹ sư phần mềm thu thập danh sách tinh thần của các mùi cần chú ý (nghĩa là các phương pháp quá dài hoặc quá nhiều tham số). Điều đó không nhất thiết có nghĩa là có vấn đề, nhưng chỉ đơn giản chỉ ra rằng người viết có thể muốn kiểm tra lại.

Tôi đề nghị rằng chúng ta cũng nên xem xét "mùi bằng chứng" . Điều này sẽ không cung cấp cho bạn một thuật toán để kiểm tra bằng chứng của bạn nhưng nó đưa ra một ngôn ngữ và phép ẩn dụ để nhận ra các vấn đề có thể xảy ra trong các bằng chứng. Một số ví dụ về bằng chứng có mùi:

1. Các trạng từ "Rõ ràng", "Rõ ràng", v.v.
2. Tham chiếu đến bằng chứng của một kết quả trước đó thay vì tham chiếu đến chính kết quả đó.
3. Flippant sử dụng một kết quả với nhiều điều kiện tiên quyết kỹ thuật.

Ngoài ra còn có mùi tinh tế hơn. Ví dụ: nếu một bằng chứng sử dụng định lý nhị thức để mở rộng một biểu thức và sau đó sử dụng định lý nhị thức để trở về dạng đóng, thì có thể có một thao tác trực tiếp trên dạng đóng cho kết quả tương tự.

Đề nghị của tôi là thu thập một danh sách (tinh thần hoặc bằng văn bản) của những mùi như vậy và kiểm tra chúng khi bạn đọc qua công việc của bạn. Tác dụng phụ tốt đẹp của phương pháp này là nó cũng sẽ giúp bạn đọc tốt hơn.

Lưu ý: Hy vọng của tôi trong câu trả lời này là đưa ra khía cạnh trực quan cho câu trả lời nghiêm ngặt được cung cấp bởi Cách viết một bằng chứng được tham chiếu trong câu trả lời của M. Alaggan.

Có một bài viết rất hay của Leslie Lamport ( Cách viết một bằng chứng ). Đó thực sự là một đề xuất của ông về một phong cách viết bằng chứng chi tiết theo cách:

(1) Cho phép phát hiện lỗi theo cách đơn giản

(2) Làm cho nó rõ ràng những giả định và định lý được sử dụng trong phần nào, điều này giúp dễ dàng thấy điều gì xảy ra nếu bạn muốn (ví dụ) sử dụng các giả định yếu hơn

Ngoài ra còn có một số kinh nghiệm cộng đồng và bình luận đầy cảm hứng về kỹ thuật này trên MO cho thấy kinh nghiệm tích cực nói chung (và một số tài nguyên khác).

Cập nhật: có phiên bản mới Cách viết bằng chứng thế kỷ 21 .

Dick Lipton có một bài viết rất hay có tiêu đề ' Cách chứng minh bằng chứng là bằng chứng '

Tôi dường như nhớ đọc một tài khoản phổ biến từ lâu về cách các nhà vật lý đối phó với một vấn đề tương tự. Ai biết phiên bản sau của nó chính xác đến mức nào; sửa chữa được chào đón. Nhưng tôi thấy chiến lược cơ bản khá đáng chú ý.

Họ giải thích làm thế nào họ tin vào lỗ đen. Các lỗ đen ban đầu hoàn toàn là các cấu trúc toán học, giống như các vật thể lạ khác trong vật lý như lỗ sâu đục. Chiến lược của họ rất ấn tượng: họ sẽ ném một cách toán học các vật thể khác vào vật thể cần thử nghiệm. Wormholes đã thất bại trong các thử nghiệm của họ vì họ phát hiện ra rằng lỗ giun sẽ sụp đổ ngay cả khi có vật thể bình thường, có thể là một tiểu hành tinh. Nhưng các lỗ đen đã vượt qua bài kiểm tra này: lỗ đen sẽ sống sót khi có một tiểu hành tinh ném vào nó. Vì vậy, họ đã cố gắng ném một ngôi sao vào nó. Cùng một kết quả. Cuối cùng, họ đã ném một lỗ đen khác vào lỗ đen và nó đã sống sót. Do đó, họ đã đủ tự tin vào sự tồn tại của các lỗ đen để thực sự bắt đầu tìm kiếm chúng trong vũ trụ thực.

Vì vậy, sự liên quan và áp dụng chiến lược trên là bắt đầu ném mọi thứ vào bằng chứng của bạn. Liệu nó có tồn tại kiểm tra sự tỉnh táo ? Nếu bạn loại bỏ một giả định cần thiết, nó có sụp đổ như nó cần không? Nó có sụp đổ như bình thường khi áp dụng cho các trường hợp ngoài phạm vi của nó không? Liệu nó có thể chịu được sự khái quát hóa và chuyên môn hợp lý? Hãy xem danh sách các heuristic trong Cách giải quyết nó của Polya . Hãy thử làm thay đổi bằng chứng của bạn với các heuristic này và xem liệu nó có đứng và rơi như bình thường không.

Tôi nghĩ một trong những cách tiếp cận an toàn nhất là đưa ra nhiều bằng chứng độc lập. Sau đó, bạn có thể tự tin rằng kết quả chính của bạn là chính xác, ngay cả khi bạn có sai sót trong một số chi tiết của một bằng chứng.

Một kỹ thuật tôi thấy hữu ích là suy nghĩ về những kết quả khác mà chiến lược bằng chứng có thể chứng minh. Nếu tôi dễ dàng điều chỉnh chiến lược chứng minh để chứng minh một vấn đề mở lớn hoặc thậm chí là một vấn đề không mở nhưng có một giải pháp quá phức tạp so với sự phức tạp của chiến lược chứng minh, thì đó là một lý do lớn để nghi ngờ bằng chứng.

Tôi luôn kiểm tra lại bằng chứng của mình bằng công cụ kiểm tra bằng chứng như COQ hoặc ISABELLE . Nếu bạn có thể chứng minh bằng chứng của mình bằng bất kỳ ngôn ngữ lập trình nào, bạn có thể chắc chắn bằng chứng của mình là chính xác. Đơn giản như một thuật ngữ lambda;).