Cara menembak bukti Anda


59

Apa pedoman umum untuk memeriksa bukti Anda? Saya percaya ini penting bagi mahasiswa pascasarjana seperti saya. Saya sudah tahu apa yang perlu kita lakukan untuk membuktikan sesuatu, tetapi Anda harus selalu memeriksa semuanya sebelum mengirimkannya. Bahkan kepada penasihat Anda sendiri.

Saya telah mengembangkan sendiri beberapa strategi melalui coba-coba, dan mendapat banyak saran dari penasihat saya. Tapi ini selalu merupakan pekerjaan yang sangat membosankan. Biasanya, ketika Anda selesai dengan sesuatu, Anda hanya ingin melanjutkan ke masalah berikutnya, tetapi Anda masih harus tetap berpegang pada masalah saat ini sampai semuanya sempurna. Di sini saya menyajikan contoh daftar trik saya sendiri:

  1. Isi rinciannya. Banyak kesalahan ada di tempat Anda menulis "sudah jelas bahwa ...", "tanpa kehilangan sifat umum ...", dll.
  2. Coba beberapa angka. Coba kasus ekstrim, seperti "apa yang terjadi ketika saya menetapkan atau n = 1000 ".n=1n=1000
  3. Simpan buku catatan yang bersih. Tuliskan setiap hari di atasnya, dan bandingkan dengan catatan kasar Anda. Saya mencoba menulis juga dalam lateks, saya menemukan banyak kesalahan dengan cara ini.

Apa strategi umum yang Anda terapkan untuk memeriksa bukti Anda?

Tujuan dari pertanyaan ini adalah menjadikannya komunitas-wiki.


Jika pertanyaannya muncul subjektif, tolong bantu saya memperbaikinya.
Marcos Villagra

bagaimana cara membuat komunitas-wiki ini?
Marcos Villagra

1
Hei, keren! Saya sangat tertarik dengan jawaban untuk pertanyaan ini. Juga, saya dapat menghargai Anda # 3. (Ketika saya memikirkannya, saya sebenarnya memiliki tumpukan kertas yang berserakan di mana-mana ketika saya sedang mengerjakan suatu masalah, yang kemudian dipindahkan secara acak. Yuck.) Saya pernah mengalami kesalahan sebelumnya karena masalah ini dan akhirnya membuang-buang banyak waktu.
Daniel Apon

@Aniel: Saya punya masalah yang sama !! Itu sebabnya setelah saya selesai dengan bukti, saya langsung menulis versi lateks. Adalah baik untuk mengetahui bahwa saya bukan satu-satunya pria berantakan yang membuat semuanya ada di mana-mana :-)
Marcos Villagra

1
Anda menandainya untuk perhatian moderator.
Suresh Venkat

Jawaban:


39

Insinyur perangkat lunak memiliki gagasan yang mereka sebut " bau kode ". Ini adalah gejala dalam kode yang dapat mengindikasikan masalah yang lebih dalam. Insinyur perangkat lunak mengumpulkan daftar bau yang harus diwaspadai (yaitu metode yang terlalu panjang atau terlalu banyak parameter). Itu tidak selalu berarti ada masalah, tetapi hanya menunjukkan bahwa penulis mungkin ingin memeriksa ulang.

Saya mengusulkan bahwa kita juga harus mempertimbangkan "bukti bau" . Ini tidak akan memberi Anda algoritma untuk memeriksa bukti Anda, tetapi memberikan bahasa dan metafora untuk mengenali kemungkinan masalah dalam bukti. Beberapa contoh bukti berbau:

  1. Kata keterangan "Jelas", "Jelas", dll.
  2. Referensi ke bukti hasil sebelumnya dan bukan referensi ke hasil itu sendiri.
  3. Penggunaan hasil yang sembrono dengan banyak prasyarat teknis.

Ada juga aroma yang lebih halus. Misalnya, jika bukti menggunakan teorema binomial untuk memperluas ekspresi dan kemudian menggunakan teorema binomial untuk kembali ke bentuk tertutup, maka mungkin ada manipulasi langsung pada formulir tertutup yang memberikan hasil yang sama.

Saran saya adalah untuk mengumpulkan (bau atau tertulis) daftar bau tersebut dan memeriksanya saat Anda membaca pekerjaan Anda. Efek samping yang bagus dari pendekatan ini adalah bahwa itu juga akan membuat Anda menjadi pembaca yang lebih baik.

Catatan: Harapan saya dalam jawaban ini adalah memberikan sisi intuitif pada jawaban keras yang diberikan oleh How to Write a Proof Lamport yang dirujuk dalam jawaban M. Alaggan.


4
Saya mengatakan ini sepanjang waktu kepada murid-murid saya, dan mereka pikir saya gila. Tentu saja saya benar-benar mengklaim saya bisa mencium bau bug, yang mungkin menjadi bagian dari masalah;)
Suresh Venkat

7
@ Suresh: Siswa ini berpikir kamu gila karena alasan yang berbeda. ;-)
John Moeller

4
Pada catatan bau kode, hal-hal yang selalu saya coba teliti dalam bukti orang lain termasuk rantai ketimpangan. Seringkali kesalahan mendasar benar-benar memiliki kebiasaan merayap di antara derivasi yang lebih sulit.
John Moeller

23

Ada makalah yang sangat bagus oleh Leslie Lamport ( Cara menulis bukti ). Ini sebenarnya adalah proposal olehnya tentang gaya penulisan bukti terperinci sedemikian rupa sehingga:

(1) Memungkinkan mendeteksi kesalahan secara langsung

(2) Jelaskan asumsi dan teorema mana yang digunakan di bagian mana, yang membuatnya cukup mudah untuk melihat apa yang terjadi jika Anda ingin (misalnya) menggunakan asumsi yang lebih lemah

Ada juga beberapa pengalaman komunitas dan komentar yang menginspirasi tentang teknik ini pada MO yang menunjukkan pengalaman positif secara umum (dan beberapa sumber daya lainnya juga).

Pembaruan: ada versi baru Cara menulis bukti abad ke-21 .


5
Bukti-bukti ini sangat mirip dengan apa yang akan ditulis dalam makalah penelitian PL. Rantai logika sangat eksplisit. Setelah mempelajari cara membaca dan menghargai bukti gaya PL, saya merasa sulit untuk memahami bukti matematika "normal". Bukti semacam itu sering mengharuskan pembaca untuk berpikir dengan cara yang sama seperti yang dilakukan penulis, dan ketika Anda terbiasa dengan gaya pembuktian yang berbeda, ini sama sekali bukan kasusnya (bagi saya, setidaknya!)
Christopher Monsanto

2
@Christopher Monsanto: PL singkatan dari Bahasa Pemrograman? Saya akan sangat menghargai jika Anda dapat menyebutkan contoh seperti itu (satu kertas seperti itu) untuk memeriksa :)
M. Alaggan

5
Saya selalu merasa bahwa apa yang disarankan Lamport tidak sesuai dengan "A Mathematician's Lament" karya Paul Lockhart ( maa.org/devlin/LockhartsLament.pdf ).
Marcos Villagra


14

Sepertinya saya ingat pernah membaca akun populer dulu tentang bagaimana fisikawan menangani masalah analog. Siapa yang tahu seberapa akurat versi berikut ini; koreksi dipersilahkan. Tetapi saya menemukan strategi yang mendasarinya cukup luar biasa.

Mereka menjelaskan bagaimana mereka bisa percaya pada lubang hitam. Lubang hitam pada awalnya murni konstruksi matematika, seperti benda aneh lainnya dalam fisika seperti lubang cacing. Strategi mereka sangat mengejutkan: mereka secara matematis akan melemparkan benda lain ke objek yang akan diuji. Lubang cacing gagal tes mereka karena mereka menemukan bahwa lubang cacing akan runtuh bahkan di hadapan benda fisik yang normal, mungkin asteroid. Tapi lubang hitam lulus tes ini: lubang hitam akan bertahan dengan dilemparkannya asteroid ke dalamnya. Jadi mereka mencoba melemparkan bintang padanya. Hasil yang sama Akhirnya, mereka melemparkan lubang hitam lain ke lubang hitam itu dan selamat. Sebagai hasil dari ini, mereka tumbuh cukup percaya diri dalam keberadaan lubang hitam untuk benar-benar mulai mencari mereka di alam semesta yang sebenarnya.

Jadi relevansi dan penerapan strategi di atas adalah untuk mulai melempar barang pada bukti Anda. Apakah itu lolos dari pemeriksaan kewarasan ? Jika Anda menghapus asumsi yang diperlukan, apakah itu runtuh seperti seharusnya? Apakah itu runtuh seperti seharusnya ketika diterapkan pada kasus di luar ruang lingkupnya? Apakah itu tahan generalisasi dan spesialisasi yang masuk akal? Lihat daftar heuristik di Polya's How to Solve It . Coba mutasikan bukti Anda dengan heuristik ini dan lihat apakah itu berdiri dan jatuh sebagaimana mestinya.


Sebagian besar jawaban Anda berfokus pada memeriksa bukti dengan memverifikasi bahwa mereka menjadi salah dalam situasi di mana mereka seharusnya salah. Itu tidak berhasil karena tidak memeriksa bahwa teorema itu benar di tempat yang seharusnya benar! Misalnya, anggap saya telah "membuktikan" bahwa setiap angka ganjil dapat dibagi tiga. Saya memeriksa bahwa bukti saya gagal jika saya memperpanjang ke angka genap juga: itu benar, karena empat tidak habis dibagi tiga. Hore, bukti saya harus benar!
David Richerby

12

Saya pikir salah satu pendekatan teraman adalah dengan menghadirkan banyak bukti independen. Maka Anda dapat yakin bahwa hasil utama Anda benar, bahkan jika Anda memiliki kesalahan dalam beberapa detail bukti.


9

Salah satu teknik yang menurut saya bermanfaat adalah memikirkan hasil apa lagi yang bisa dibuktikan oleh strategi pembuktian. Jika saya dapat dengan mudah mengadaptasi strategi bukti untuk membuktikan masalah terbuka besar atau bahkan masalah yang tidak terbuka tetapi memiliki solusi yang terlalu rumit dibandingkan dengan kompleksitas strategi bukti, maka itu adalah alasan besar untuk ragu bukti.


5
PNP

6

Saya selalu memeriksa ulang bukti saya dengan pemeriksa bukti seperti COQ atau ISABELLE . Jika Anda dapat membuktikan bukti dalam bahasa pemrograman ini, Anda dapat memastikan bukti Anda benar. Sesederhana istilah lambda;).


Saya tidak pernah menggunakan Coq, tetapi saya harus mencoba. Sebenarnya, saya mencoba untuk membuktikan batas bawah dengan Mathematica, tetapi saya belum menemukan cara yang benar. Mungkin saya memerlukan beberapa paket khusus atau sesuatu.
Marcos Villagra

1
Mungkin ini adalah sebuah kesalahan besar, tetapi jika Anda ingin membuktikan batas bawah dengan real, Anda dapat memeriksa perpustakaan ini: coqtail.sourceforge.net/?home/en
Gopi

Setuju, tetapi bahasa pemrograman apa pun berfungsi. Paling sering saya melakukan ini secara terbalik. Merumuskan domain masalah dalam bahasa pemrograman (biasanya Ruby), lalu gunakan ini sebagai templat untuk bukti saya.
Chad Brewbaker
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.