Mengapa menuliskan bukti matematis lebih banyak bukti kesalahan daripada menulis kode komputer?


190

Saya telah memperhatikan bahwa saya merasa jauh lebih mudah untuk menuliskan bukti matematika tanpa membuat kesalahan, daripada menuliskan program komputer tanpa bug.

Sepertinya ini adalah sesuatu yang lebih luas dari sekedar pengalaman saya. Kebanyakan orang membuat bug perangkat lunak setiap saat dalam pemrograman mereka, dan mereka memiliki kompiler untuk memberi tahu mereka apa kesalahannya sepanjang waktu. Saya belum pernah mendengar seseorang yang menulis program komputer besar tanpa kesalahan dalam sekali jalan, dan memiliki keyakinan penuh bahwa itu akan menjadi bugless. (Sebenarnya, hampir tidak ada program yang bugless, bahkan banyak yang sangat debugged).

Namun orang dapat menulis seluruh makalah atau buku bukti matematika tanpa penyusun apa pun pernah memberi mereka umpan balik bahwa mereka membuat kesalahan, dan kadang-kadang bahkan tanpa mendapatkan umpan balik dari orang lain.

Biarkan saya jelas. ini bukan untuk mengatakan bahwa orang tidak membuat kesalahan dalam bukti matematika, tetapi untuk matematikawan yang bahkan berpengalaman, kesalahan biasanya tidak terlalu bermasalah, dan dapat diselesaikan tanpa bantuan "ramalan eksternal" seperti kompiler yang menunjuk pada Anda kesalahan.

Bahkan, jika ini tidak terjadi, maka matematika akan hampir tidak mungkin bagi saya.

Jadi ini mengarahkan saya untuk mengajukan pertanyaan: Apa yang begitu berbeda tentang penulisan bukti matematis tanpa cacat dan penulisan kode komputer tanpa cacat yang membuatnya sehingga yang pertama jauh lebih mudah ditelusuri daripada yang terakhir?

Orang bisa mengatakan bahwa itu hanyalah fakta bahwa orang memiliki "ramalan eksternal" dari kompiler yang menunjukkan kesalahan mereka yang membuat programmer malas, mencegah mereka dari melakukan apa yang diperlukan untuk menulis kode dengan keras. Pandangan ini akan berarti bahwa jika mereka tidak memiliki kompiler, mereka akan dapat sama sempurnanya dengan ahli matematika.

Anda mungkin menemukan ini persuasif, tetapi berdasarkan pengalaman saya pemrograman dan menulis bukti matematika, tampaknya secara intuitif bagi saya bahwa ini benar-benar bukan penjelasan. Tampaknya ada sesuatu yang secara fundamental berbeda dari kedua upaya tersebut.

Pikiran awal saya adalah, bahwa apa yang mungkin menjadi perbedaan, adalah bahwa untuk seorang ahli matematika, bukti yang benar hanya membutuhkan setiap langkah logis untuk menjadi benar. Jika setiap langkah benar, seluruh bukti benar. Di sisi lain, agar suatu program menjadi bugless, tidak hanya setiap baris kode harus benar, tetapi hubungannya dengan setiap baris kode lain dalam program harus bekerja juga.

Dengan kata lain, jika langkah di bukti benar, maka membuat kesalahan pada langkah tidak akan mengacaukan langkah pernah. Tetapi jika satu baris kode dituliskan dengan benar, maka membuat kesalahan pada baris akan mempengaruhi kerja baris , sehingga setiap kali kita menulis baris kita harus memperhitungkan hubungannya dengan semua baris lainnya. Kita dapat menggunakan enkapsulasi dan semua itu untuk membatasi hal ini, tetapi tidak dapat dihapus sepenuhnya.Y X X Y X XXYXXYXX

Ini berarti bahwa prosedur untuk memeriksa kesalahan dalam bukti matematika pada dasarnya adalah linier dalam jumlah langkah-bukti, tetapi prosedur untuk memeriksa kesalahan dalam kode komputer pada dasarnya eksponensial dalam jumlah baris kode.

Bagaimana menurut anda?

Catatan: Pertanyaan ini memiliki sejumlah besar jawaban yang mengeksplorasi berbagai macam fakta dan sudut pandang. Sebelum Anda menjawab, harap baca semuanya dan jawab hanya jika Anda memiliki sesuatu yang baru untuk ditambahkan. Jawaban yang berlebihan, atau jawaban yang tidak mendukung pendapat dengan fakta, dapat dihapus.


3
Apakah Anda menyadari bukti kebenaran untuk program, baik di atas kertas dan mekanik di pembalik teorema? Keduanya ada dan bertentangan dengan pembaruan Anda. benar bahwa pemrograman seperti yang diajarkan pada umumnya tidak ada hubungannya dengan pemrograman dengan bukti kebenaran.
Blaisorblade

76
Mengingatkan saya pada kutipan Knuth, saya pikir "Waspadalah terhadap kode di atas! Saya hanya membuktikannya benar, saya tidak pernah mengujinya"
Hagen von Eitzen

Komentar bukan untuk diskusi panjang; percakapan ini telah dipindahkan ke obrolan .
Gilles

7
Temukan saya bukti matematika tulisan tangan yang panjangnya 100 juta baris dan tidak memiliki "bug", dan saya akan memberikan semua yang saya miliki.
Davor

Program fungsional bisa jauh lebih mudah untuk menulis daripada bukti, namun begitu negara masuk ... kesulitannya meledak ...
aoeu256

Jawaban:


226

Izinkan saya menawarkan satu alasan dan satu kesalahpahaman sebagai jawaban atas pertanyaan Anda.

The Alasan utama bahwa lebih mudah untuk menulis (tampaknya) bukti matematika yang benar adalah bahwa mereka ditulis pada tingkat yang sangat tinggi. Misalkan Anda dapat menulis program seperti ini:

function MaximumWindow(A, n, w):
    using a sliding window, calculate (in O(n)) the sums of all length-w windows
    return the maximum sum (be smart and use only O(1) memory)

Akan jauh lebih sulit untuk salah ketika memprogram seperti ini, karena spesifikasi program jauh lebih ringkas daripada implementasinya . Memang, setiap programmer yang mencoba mengubah kode pseudocode ke kode, terutama untuk kode yang efisien, menemukan jurang besar antara ide algoritma dan rincian implementasinya . Bukti matematika lebih berkonsentrasi pada ide dan kurang pada detail.

Mitra nyata dari kode untuk bukti matematika adalah bukti yang dibantu komputer . Ini jauh lebih sulit untuk dikembangkan daripada bukti tekstual biasa, dan orang sering menemukan berbagai sudut tersembunyi yang "jelas" bagi pembaca (yang biasanya bahkan tidak memperhatikannya), tetapi tidak begitu jelas bagi komputer. Juga, karena komputer hanya dapat mengisi celah yang relatif kecil saat ini, buktinya harus dijabarkan sedemikian rupa sehingga manusia yang membacanya akan kehilangan hutan untuk pepohonan.

Kesalahpahaman yang penting adalah bahwa bukti matematika seringkali benar. Bahkan, ini mungkin agak optimis. Sangat sulit untuk menulis bukti rumit tanpa kesalahan, dan kertas sering mengandung kesalahan. Mungkin kasus terbaru yang paling terkenal adalah upaya pertama Wiles di (kasus khusus) teorema modularitas (yang menyiratkan teorema terakhir Fermat), dan berbagai kesenjangan dalam klasifikasi kelompok sederhana hingga, termasuk sekitar 1.000 halaman tentang kelompok quasithin yang ditulis 20 tahun setelah klasifikasi seharusnya selesai.

Sebuah kesalahan dalam kertas Voevodsky membuatnya diragukan ditulis bukti sehingga ia mulai mengembangkan teori tipe homotopy , kerangka logis berguna untuk mengembangkan teori homotopy secara resmi, dan selanjutnya menggunakan komputer untuk memverifikasi semua kerja berikutnya (setidaknya menurut sendiri penerimaan). Walaupun ini adalah posisi yang ekstrem (dan saat ini, tidak praktis), tetap saja ketika menggunakan hasil, seseorang harus memeriksa buktinya dan memeriksa apakah itu benar. Di daerah saya ada beberapa makalah yang diketahui salah tetapi tidak pernah ditarik kembali, yang statusnya disampaikan dari mulut ke telinga di antara para ahli.


Komentar bukan untuk diskusi panjang; percakapan ini telah dipindahkan ke obrolan .
DW

1
Mungkinkah di masa depan, asisten bukti akan digunakan untuk memeriksa kode dan bukti Anda? Mungkin ini saatnya untuk Belajar Agda ? (maaf ...)
Alex Vong

3
@AlexVong Satu masalah dengan itu adalah bahwa menulis spesifikasi formal untuk kode non-sepele (sehingga Anda dapat memverifikasi bahwa kode tersebut benar-benar memenuhi spesifikasi) hampir tidak mungkin. Misalnya, dapatkah Anda bayangkan betapa rumitnya spesifikasi formal untuk peramban (termasuk semua interaksi pengguna, semua format dan protokol file yang didukung, dll.)?
svick

2
@vick Anda benar, untuk interaksi pengguna, kadang-kadang bahkan tidak jelas perilaku apa yang seharusnya. Jadi, kita harus memfokuskan diri pada sesuatu dengan spesifikasi formal yang tepat (misalnya bukti, kompiler).
Alex Vong

1
Memang. Itu mungkin juga merupakan penjelasan mengapa banyak orang akan menemukan bahwa pengkodean dalam bahasa tingkat rendah lebih membosankan dan kurang menyenangkan daripada pengkodean dalam bahasa abstrak tingkat tinggi. Meskipun itu mungkin juga berbeda menurut orang, tentu saja (Beberapa bahkan mungkin menikmati membangun sirkuit perangkat keras / elektronik tingkat sangat rendah lebih dari menulis perangkat lunak yang berjalan pada mereka? Juga, kode tingkat lebih rendah masih dapat tergantikan dalam banyak kasus dan menulisnya dengan baik bisa menjadi keterampilan langka / prestasi yang layak dipuji sendiri).
xji

77

(Saya mungkin mengambil risiko beberapa downvotes di sini, karena saya tidak punya waktu / minat untuk membuat ini jawaban yang tepat, tetapi saya menemukan teks yang dikutip (dan sisa artikel yang dikutip) di bawah ini cukup mendalam, juga mengingat mereka ditulis oleh ahli matematika terkenal. Mungkin saya bisa meningkatkan jawabannya nanti.)

Idenya, yang saya kira tidak terlalu berbeda dari jawaban yang ada, adalah bahwa "bukti" atau argumen berkomunikasi dengan komunitas matematika, di mana tujuannya adalah untuk meyakinkan mereka bahwa rincian (membosankan) dapat diisi, pada prinsipnya, untuk mendapatkan bukti formal yang sepenuhnya ditentukan - tanpa sering melakukannya sama sekali. Salah satu contoh penting dari ini adalah bahwa Anda dapat menggunakan teorema yang ada hanya dengan menyatakannya, tetapi penggunaan kembali kode jauh lebih menantang secara umum. Juga pertimbangkan minor "bug", yang mungkin benar-benar membuat sepotong kode tidak berguna (misalnya, SEGFAULTs) tetapi mungkin meninggalkan argumen matematis sebagian besar utuh (yaitu, jika kesalahan dapat dikandung tanpa argumen runtuh).

Standar ketelitian dan kelengkapan yang diperlukan untuk membuat program komputer bekerja sama sekali adalah beberapa urutan besarnya lebih tinggi dari standar bukti valid komunitas matematika. Meskipun demikian, program komputer besar, bahkan ketika mereka telah ditulis dengan sangat hati-hati dan sangat hati-hati diuji, selalu tampaknya memiliki bug. [...] Matematika seperti yang kita praktikkan jauh lebih lengkap dan tepat secara formal daripada sains lain, tetapi secara formal kurang lengkap dan tepat untuk isinya daripada program komputer. Perbedaannya tidak hanya dengan jumlah usaha: jenis usaha berbeda secara kualitatif. Dalam program komputer besar, sebagian besar upaya harus dihabiskan untuk berbagai masalah kompatibilitas: memastikan bahwa semua definisi konsisten, mengembangkan "baik" struktur data yang memiliki generalisasi yang berguna tetapi tidak rumit, memutuskan generalisasi "benar" untuk fungsi, dll. Proporsi energi yang dihabiskan pada bagian kerja dari program besar, yang dibedakan dari bagian pembukuan, sangat kecil. Karena masalah kompatibilitas yang hampir tidak terelakkan meningkat karena definisi "benar" berubah ketika generalitas dan fungsionalitas ditambahkan, program komputer biasanya perlu sering ditulis ulang, sering dari awal.

TENTANG BUKTI DAN KEMAJUAN DALAM MATEMATIKA (hlm. 9-10), oleh WILLIAM P. THURSTON https://arxiv.org/pdf/math/9404236.pdf


3
Poin tentang "penggunaan kembali kode" cukup tepat. Menerjemahkan bukti panjang dari bahasa Rusia ke bahasa Inggris membutuhkan cukup banyak pengetikan ; tetapi menerjemahkan program komputer besar dari, katakanlah, C ++ ke dalam Java, membutuhkan banyak pemikiran . Juga, membangkitkan bukti berusia 3000 tahun dalam Bahasa Yunani Kuno hampir sama mudahnya; menghidupkan kembali program 30 tahun di PL / 1 hampir sama sulitnya, atau lebih sulit.
Quuxplusone

2
Contoh Yunani Kuno juga membuat saya sadar: Pemrogram komputer menggunakan banyak bahasa gaul lokal dan bahasa sehari-hari, seperti (void*)1dan open('/dev/null'), yang bahkan mungkin tidak dapat dibawa-bawa antara subkultur yang berbeda, apalagi diterjemahkan ke dalam bahasa tujuan. (Pembaca hanya agak harus grok perkiraan semantik mereka dengan pengalaman panjang.) Saya pikir bukti matematis mengandung kurang dari "gaul." Jika suatu bukti menggunakan sebuah kata, makna universalnya yang sebenarnya seharusnya dapat direduksi oleh pembaca. Program komputer bahkan tidak memiliki makna universal!
Quuxplusone

1
00

@Tidak bisakah kamu menguraikan? Saya tidak mengerti.
Gregory Magarshak


55

Izinkan saya memulai dengan mengutip EW Dijkstra:

"Pemrograman adalah salah satu cabang matematika terapan yang paling sulit; matematikawan yang lebih miskin lebih baik tetap menjadi ahli matematika murni." (dari EWD498)

Meskipun apa yang dimaksud oleh Dijkstra dengan `pemrograman 'sedikit berbeda dari penggunaan saat ini, masih ada beberapa kelebihan dalam kutipan ini. Jawaban lain telah menyebutkan bahwa tingkat abstraksi dalam matematika diperbolehkan jauh lebih tinggi daripada dalam pemrograman, artinya kita dapat mengabaikan beberapa bagian yang rumit jika kita ingin melakukannya.

Namun, saya percaya bahwa ini hanyalah konsekuensi dari perbedaan yang lebih mendasar antara pembuktian dan program komputer, yang merupakan tujuan mereka .

Tujuan utama dari bukti matematika adalah, antara lain, untuk meyakinkan diri sendiri bahwa klaim matematika itu benar dan, bahkan mungkin lebih penting, untuk mencapai pemahaman . Oleh karena itu, Anda dapat memilih untuk hanya bekerja di dunia matematika, di mana segala sesuatu dibuat sedemikian rupa sehingga pemahaman dapat dicapai dengan desain (meskipun beberapa siswa memohon berbeda ...) Inilah yang dimaksudkan Dijkstra dengan "ahli matematika murni", mereka yang (Hampir) hanya memusatkan perhatian pada fakta-fakta matematika dan memahami sifat-sifatnya.

Jadi, Anda tidak perlu terkejut menghasilkan bukti yang benar relatif tahan terhadap kesalahan: itu adalah inti dari seluruh "latihan". (Tetap saja, ini tidak berarti kesalahan tidak atau hampir tidak ada, untuk berbuat kesalahan hanya manusia, kata mereka)

Sekarang, jika kita mempertimbangkan pemrograman, apa tujuan kita? Kami tidak benar-benar mencari pengertian, kami menginginkan sesuatu yang berhasil . Tetapi kapan sesuatu "bekerja"? Sesuatu berfungsi ketika kita berhasil membuat sesuatu yang memungkinkan beberapa mesin aneh untuk menyelesaikan tugas yang kita inginkan dan lebih disukai juga cukup cepat.

Saya percaya, ini adalah perbedaan mendasar, karena itu berarti bahwa tujuan kami tidak dapat dengan mudah dinyatakan sebagai beberapa teorema yang "dibuktikan" oleh program kami, kami menginginkan sesuatu di dunia nyata (apa pun itu), bukan beberapa artefak matematika. Ini berarti bahwa kita tidak dapat secara murni mencapai tujuan kita (walaupun Dijkstra ingin Anda mencobanya tanpa mempedulikan) karena kita harus menenangkan mesin, berharap bahwa kita benar-benar tahu tugas mana yang ingin kita lakukan dan juga menyadari hal-hal yang tidak dipertimbangkan, belum terjadi entah bagaimana.

Jadi, pada akhirnya, tidak ada jalan lain selain hanya mencobanya dan mungkin gagal, perbaiki, gagal dan coba lagi sampai kita agak puas dengan hasilnya.


Perhatikan bahwa hipotesis Anda menulis bukti kesalahan-kurang lebih sederhana daripada program kesalahan-kurang (yang sebenarnya pernyataan berbeda seperti yang ditunjukkan @ririel ) mungkin sebenarnya salah, karena bukti seringkali dibangun melalui coba-coba pada tingkat tertentu. Namun, saya berharap bahwa ini memberi titik terang pada pertanyaan yang tersirat: "Apa sebenarnya perbedaan antara membuktikan beberapa teorema dan menulis sebuah program?" (Untuk yang pengamat ceroboh koresponden Curry-Howard mungkin mengatakan: "Tidak ada sama sekali!")


Seperti @wvxvw disebutkan dalam komentar, paragraf berikut dari 'catatan tentang Pemrograman Terstruktur' (EWD249, halaman 21) sangat relevan:

(...) Program tidak pernah merupakan tujuan itu sendiri; tujuan suatu program adalah untuk membangkitkan perhitungan dan tujuan perhitungan adalah untuk membangun efek yang diinginkan. Meskipun program adalah produk akhir yang dibuat oleh programmer, perhitungan yang mungkin ditimbulkan olehnya - "pembuatan" yang diserahkan kepada mesin! - Adalah subjek sebenarnya dari perdagangannya. Misalnya, setiap kali seorang programmer menyatakan bahwa programnya benar, ia benar-benar membuat pernyataan tentang perhitungan yang mungkin ditimbulkannya.

(...) Dalam arti pembuatan program karena itu lebih sulit daripada pembuatan teori matematika: baik program dan teori terstruktur, objek abadi. Tetapi sementara teori matematika masuk akal seperti apa adanya, program hanya masuk akal melalui pelaksanaannya.


2
Saya hanya orang awam; apa yang benar-benar dirujuk oleh Dijkstra oleh "pemrograman"?
Ovi

2
@ Ovi Saya tidak begitu yakin, tetapi perbedaan utama adalah bahwa ia berbicara tentang penyelesaian masalah algoritme (non-sepele) lebih dari tugas pemrograman 'umum', yaitu ia tentu saja tidak berbicara tentang beberapa program CRUD yang perlu menghubungkan beberapa arsitektur yang ada atau komponen lain dll. Lebih lanjut tentang pendapat Dijkstra tentang pemrograman dapat dilihat dalam jawaban ini
Kadal diskrit

3
Suara positif untuk mengutip Dijkstra, tetapi Anda memilih tempat yang salah! Dia telah menulis banyak tentang masalah ini di paragraf pertama Pemrograman Terstruktur. Saya tidak ingin mengubah jawaban Anda dengan mengirimkan penawaran yang berbeda, tetapi saya berharap Anda akan melihat untuk menambahkan lebih banyak dari kertas itu ke jawaban Anda!
wvxvw

@Ovi tebakan saya pada pertanyaan Anda adalah bahwa pemrograman pada masa Dijkstra lebih sering berarti menulis kode perakitan vs era modern bahasa tingkat tinggi. Demikian pula, saya sedang membaca Mythical Man-Month edisi 1974, konsep-konsepnya masih berlaku tetapi rujukan teknisnya adalah assembler tingkat sistem atau PL / I, jauh berbeda dari apa yang kebanyakan orang pikirkan sebagai pemrograman hari ini
JimLohse

46

Lamport memberikan beberapa dasar untuk ketidaksepakatan tentang prevalensi kesalahan dalam bukti dalam Cara menulis bukti (halaman 8-9) :

Sekitar dua puluh tahun yang lalu, saya memutuskan untuk menulis bukti teorema Schroeder-Bernstein untuk kelas matematika pengantar. Bukti paling sederhana yang bisa saya temukan adalah dalam teks topologi umum klasik Kelley. Karena Kelley menulis untuk audiens yang lebih canggih, saya harus menambahkan banyak penjelasan pada bukti setengah halamannya. Saya telah menulis lima halaman ketika saya menyadari bahwa bukti Kelley salah. Baru-baru ini, saya ingin mengilustrasikan ceramah tentang gaya pembuktian saya dengan bukti salah yang meyakinkan, jadi saya menoleh ke Kelley. Saya tidak dapat menemukan apa pun yang salah dengan buktinya; tampaknya benar! Membaca dan membaca ulang bukti meyakinkan saya bahwa ingatan saya telah gagal, atau saya sangat bodoh dua puluh tahun yang lalu. Namun, bukti Kelley pendek dan akan menjadi contoh yang bagus, jadi saya mulai menulis ulang sebagai bukti terstruktur.

... Gaya ini pertama kali diterapkan pada bukti teorema biasa dalam makalah yang saya tulis bersama Martin Abadi. Dia sudah menulis bukti konvensional — bukti yang cukup baik untuk meyakinkan kami dan, mungkin, wasit. Menulis ulang bukti dalam gaya terstruktur, kami menemukan bahwa hampir setiap orang memiliki kesalahan serius, meskipun teorema itu benar. Setiap harapan bahwa bukti yang salah mungkin tidak mengarah pada teorema yang salah dihancurkan dalam kolaborasi kami berikutnya. Berkali-kali, kami akan membuat dugaan dan menulis sketsa bukti di papan tulis — sketsa yang bisa dengan mudah diubah menjadi bukti konvensional yang meyakinkan — hanya untuk menemukan, dengan mencoba menulis bukti terstruktur, bahwa dugaan itu salah. Sejak itu, saya tidak pernah percaya hasil tanpa bukti, terstruktur bukti.


6
Makalah yang sama: "Bukti anekdotal menunjukkan bahwa sebanyak sepertiga dari semua makalah yang diterbitkan dalam jurnal matematika mengandung kesalahan - bukan hanya kesalahan kecil, tetapi teorema dan bukti yang salah". Ya, itu di tahun 90-an, tetapi apakah hari ini berbeda? Mungkin makalah-makalah yang ada saat itu, masih ada dan semuanya menumpuk ... Jadi, saya tidak sepenuhnya yakin bahwa bukti matematika yang disediakan dalam makalah mengandung lebih sedikit kesalahan.
MarkokraM

Anekdot yang menarik, tapi saya tidak melihatnya langsung menjawab atau terlibat dengan pertanyaan. Apakah Anda ingin mengedit jawaban Anda untuk lebih langsung menanggapi pertanyaan yang diajukan? Apakah Anda berpendapat bahwa bukti matematika sama salahnya dengan menulis kode komputer? Apakah Anda memiliki bukti lebih lanjut untuk itu yang dapat Anda berikan? Satu atau dua anekdot tidak benar-benar menunjukkan itu, bukan?
DW

@DW Saya mengirim pesan email ke Leslie jika, ia dapat memberikan bukti lebih lanjut untuk klaim tersebut.
MarkokraM

3
@DW Leslie mengatakan dalam jawaban yang tulus bahwa rekannya melakukan penyelidikan dengan 51 bukti yang diterbitkan di Math Reviews pada saat itu. Menurutnya itu lebih dari sekadar anekdot tetapi tidak cocok untuk bukti kuat karena beberapa fakta. Kasus lebih rumit karena beberapa kesalahan pada bukti terjadi karena mereka menggunakan bukti salah prom makalah yang diterbitkan sebelumnya dll. Akan menjadi topik penelitian yang hebat tetapi membutuhkan banyak kerja. Cara memverifikasi bukti matematika secara terprogram masih merupakan pertanyaan besar. Aplikasi yang dibuat untuk bantuan bukti interaktif masih dalam tahap sangat awal. Setidaknya antarmuka mereka.
MarkokraM

@ DW Satu atau dua anekdot menunjukkan bagaimana bukti matematis dapat tampak "benar" tetapi sebenarnya tidak sehat. Bagi siapa saja yang telah menulis algoritma komputer yang kompleks dan melakukan pembuktian matematis, dan mencoba untuk menulis algoritma komputer seperti pembuktian matematis dan kemudian menemukan bagaimana "algoritma" tingkat tinggi dikhianati oleh banyak, banyak bug dalam rinciannya, hasilnya sama sekali tidak mengherankan.
Yakk

39

Satu perbedaan besar adalah bahwa program biasanya ditulis untuk beroperasi pada input, sedangkan bukti matematis umumnya dimulai dari serangkaian aksioma dan teorema yang diketahui sebelumnya. Kadang-kadang Anda harus membahas beberapa kasus sudut untuk mendapatkan bukti yang cukup umum, tetapi kasus dan resolusi mereka secara eksplisit disebutkan dan cakupan hasilnya secara implisit dibatasi pada kasus-kasus yang dicakup.

Bandingkan ini dengan program komputer, yang harus menyediakan output 'benar' untuk berbagai input yang mungkin. Jarang mungkin untuk menyebutkan semua input dan mencoba semuanya. Lebih buruk lagi, seandainya program berinteraksi dengan manusia dan memungkinkan input mereka untuk memodifikasi fungsi? Manusia terkenal tidak dapat diprediksi dan jumlah input yang mungkin untuk program yang cukup besar dengan interaksi manusia tumbuh pada tingkat yang luar biasa. Anda perlu mencoba untuk meramalkan semua cara yang berbeda suatu program dapat digunakan dan mencoba untuk membuat semua kasus penggunaan itu berfungsi atau setidaknya gagal dengan cara yang masuk akal, ketika kegagalan adalah satu-satunya pilihan. Dan itu dengan asumsi Anda bahkan tahu bagaimana itu seharusnya bekerja dalam semua kasus sudut yang tidak jelas.

Akhirnya, sebuah program besar tidak dapat benar-benar dibandingkan dengan satu bukti, bahkan yang kompleks. Sebuah program besar mungkin lebih mirip dengan mengumpulkan dan meninjau perpustakaan literatur kecil, beberapa di antaranya mungkin memiliki kesalahan yang perlu Anda selesaikan. Untuk program yang lebih pada skala bukti tunggal, yang mungkin merupakan implementasi algoritma kecil, katakanlah, insinyur perangkat lunak yang berpengalaman dapat / menyelesaikannya tanpa membuat kesalahan, terutama ketika menggunakan alat modern yang mencegah / menyelesaikan kesalahan sepele yang umum (seperti kesalahan ejaan ) yang setara dengan masalah awal yang akan Anda selesaikan dalam proofreading.


14
+1 untuk paragraf terakhir Anda. Sementara bukti matematika pada prinsipnya dibangun di atas satu sama lain, biasanya dasar-dasarnya dipahami dengan baik, analog perpustakaan komputer (meskipun mereka juga memiliki bug ...), dan bukti sebenarnya tidak terlalu lama. Sebaliknya, perangkat lunak konsumen panjang dan rumit, sehingga banyak peluang gagal.
Yuval Filmus

6
Dalam praktiknya, masalah lain dengan perangkat lunak konsumen adalah bahwa perilaku yang 'benar' sering buruk di muka sehingga apa yang dulu benar nantinya menjadi salah. Ini seperti mencoba menulis bukti hanya untuk mengetahui bahwa orang telah memutuskan untuk mengubah aksioma. Anda dapat memperbaikinya dalam notasi, bukan?
Dan Bryant

2
@DanBryant Situasi itu memang terjadi dalam matematika. Secara khusus definisi istilah bergeser dari waktu ke waktu dan sering kali ambigu bahkan tepat seperti yang mereka gunakan. "Bukti dan Sanggahan" Imre Lakatos menggambarkan ini dengan istilah "poligon". Hal serupa terjadi dengan "fungsi" dan pada tingkat yang lebih rendah "integral". Bahkan hari ini, "kategori" tidak ambigu dan bukti dan teorema dapat gagal tergantung pada apa yang Anda maksud.
Derek Elkins

25

Mereka mengatakan masalah dengan komputer adalah mereka melakukan persis seperti yang Anda katakan.

Saya pikir ini mungkin salah satu dari banyak alasan.

Perhatikan bahwa, dengan program komputer, penulis (Anda) cerdas tetapi pembaca (CPU) bodoh.
Tetapi dengan bukti matematis, penulis (Anda) pintar dan pembaca (peninjau) juga pintar.

Ini berarti Anda tidak akan pernah mampu masuk ke situasi "baik, Anda tahu apa yang saya maksud " dengan komputer. Itu melakukan persis apa yang Anda katakan, tanpa mengetahui niat Anda.

Sebagai contoh, katakanlah ini adalah langkah dalam beberapa bukti:

x2+4x+3x+3=(x+1)(x+3)x+3=x+1

x2+4x+3x+3x=3


3
Jawaban bagus! kecuali bahwa sebagai komputer, saya keberatan Anda menggunakan kata "sia-sia". ;) [Misalkan ini hanya satu langkah dalam bukti yang lebih besar yang bertujuan untuk membuktikan bahwa -xitu komposit. Fakta bahwa langkah ini salah ketika -x = 3sangat relevan dengan kebenaran dari bukti yang telah dilengkapi!]
Quuxplusone

@Quuxplusone: = P
Mehrdad

Komputer dapat menggunakan matematika simbolis dan aturan penulisan ulang yang tidak deterministik juga, hanya saja bahasa yang kita gunakan seperti C ++ semuanya sangat sangat rendah dan berdasarkan pada teknologi kuno (C memiliki fitur lebih sedikit daripada Algol 60, misalnya). Satu-satunya pengecualian adalah bahasa pembuktian / pengecekan seperti Idris / Agda, Lisp dengan pemecah simbolis dan Mathematica. ja.wolframalpha.com/input/…
aoeu256

23

Satu masalah yang saya pikir tidak dibahas dalam jawaban Yuval, adalah sepertinya Anda membandingkan hewan yang berbeda.

nn!

Memverifikasi sifat semantik program tidak dapat diputuskan (teorema Rice), dan secara analog, memeriksa apakah pernyataan dalam logika predikat urutan pertama benar juga tidak dapat diputuskan. Intinya adalah bahwa tidak ada perbedaan nyata dalam kekerasan dari cara Anda melihat masalah. Di sisi lain, kita dapat beralasan tentang sifat sintaksis program (kompiler), dan ini analog dengan fakta bahwa kita dapat memverifikasi bukti. Bug (kode tidak melakukan apa yang saya inginkan) semantik, jadi Anda harus membandingkannya dengan rekanan yang benar.

Saya akan memperkuat Yuval dan mengatakan bahwa seluruh bidang tumbuh dengan motivasi penulisan bukti matematis yang dapat ditulis dan diverifikasi dalam beberapa sistem formal, sehingga bahkan proses verifikasi sama sekali tidak sepele.


18

Apa yang begitu berbeda tentang penulisan bukti matematis tanpa cacat dan penulisan kode komputer tanpa cacat yang membuatnya sedemikian rupa sehingga yang pertama jauh lebih mudah ditelusuri daripada yang terakhir?

Saya percaya bahwa alasan utama adalah idempotensi (memberikan hasil yang sama untuk input yang sama) dan kekekalan (tidak berubah).

Bagaimana jika bukti matematis dapat memberikan hasil yang berbeda jika dibaca pada hari Selasa atau ketika tahun naik menjadi 2000 dari tahun 1999? Bagaimana jika bagian dari bukti matematika adalah untuk kembali beberapa halaman, menulis ulang beberapa baris, dan kemudian mulai lagi dari titik itu?

Saya yakin bahwa bukti seperti itu akan hampir sama rentan terhadap bug seperti segmen normal kode komputer.

Saya melihat faktor sekunder lainnya juga:

  1. Matematikawan biasanya jauh lebih berpendidikan sebelum mencoba menulis bukti yang signifikan / dapat diterbitkan. 1/4 pengembang profesional self-titled mulai mengkode kurang dari 6 tahun yang lalu (lihat survei SO 2017 ), tetapi saya berasumsi sebagian besar matematikawan memiliki lebih dari satu dekade pendidikan matematika formal.
  2. Bukti matematis jarang dimiliki pada tingkat pengawasan yang sama dengan kode komputer. Satu kesalahan ketik dapat / akan merusak program, tetapi lusinan kesalahan ketik mungkin tidak cukup untuk menghancurkan nilai bukti (hanya keterbacaannya).
  3. Iblis ada di dalam perincian, dan kode komputer tidak dapat melewatkan perincian. Bukti bebas untuk melewati langkah-langkah yang dianggap sederhana / rutin. Ada beberapa gula sintaksis yang bagus tersedia dalam bahasa modern, tetapi ini adalah hard-coded dan perbandingannya sangat terbatas.
  4. Matematika lebih tua dan memiliki fondasi / inti yang lebih solid. Tentu saja ada banyak subbidang baru dan mengkilap dalam matematika, tetapi sebagian besar prinsip inti telah digunakan selama beberapa dekade. Ini mengarah pada stabilitas. Di sisi lain, programmer masih tidak setuju pada metodologi pengkodean dasar (hanya bertanya tentang pengembangan Agile dan tingkat adopsi).

Mungkin perlu disebutkan bahwa pemrograman yang setara dengan 'indempotency' adalah kemurnian fungsional , yang diakui dan didukung dalam beberapa bahasa seperti Haskell.
Pharap

12

Saya setuju dengan apa yang ditulis Yuval. Tetapi juga memiliki jawaban yang jauh lebih sederhana: Dalam praktiknya, perangkat lunak insinyur biasanya bahkan tidak mencoba memeriksa kebenaran program mereka, mereka tidak, mereka biasanya bahkan tidak menuliskan kondisi yang menentukan kapan program itu benar.

Ada berbagai alasan untuk itu. Salah satunya adalah bahwa sebagian besar insinyur perangkat lunak tidak memiliki keterampilan untuk merumuskan masalah dengan jelas secara matematis atau mereka tidak tahu bagaimana menulis bukti kebenaran.

Yang lain adalah bahwa mendefinisikan kondisi kebenaran untuk sistem perangkat lunak yang kompleks (khususnya yang didistribusikan) adalah tugas yang sangat sulit dan memakan waktu. Mereka diharapkan memiliki sesuatu yang tampaknya berfungsi dalam hitungan minggu.

Alasan lain adalah bahwa kebenaran suatu program tergantung pada banyak sistem lain yang ditulis oleh orang lain yang lagi-lagi tidak memiliki semantik yang jelas. Ada hukum Hyrum yang pada dasarnya mengatakan jika perpustakaan / layanan Anda memiliki perilaku yang dapat diamati (bukan bagian dari kontraknya) seseorang pada akhirnya akan bergantung padanya. Itu pada dasarnya berarti gagasan mengembangkan perangkat lunak dalam bentuk modular dengan kontrak yang jelas seperti lemmas dalam matematika tidak berfungsi dalam praktiknya. Semakin buruk dalam bahasa di mana refleksi digunakan. Bahkan jika suatu program benar hari ini, ia mungkin rusak besok ketika seseorang melakukan beberapa refactoring sepele di salah satu dependensinya.

Dalam praktiknya apa yang biasanya terjadi adalah mereka menjalani tes. Tes bertindak seperti apa yang diharapkan dari program. Setiap kali bug baru ditemukan, mereka menambahkan tes untuk menangkapnya. Ia bekerja sampai batas tertentu, tetapi itu bukan bukti kebenaran.

Ketika orang tidak memiliki keterampilan untuk mendefinisikan kebenaran atau menulis program yang benar atau diharapkan untuk melakukannya dan itu agak sulit, tidak mengherankan bahwa perangkat lunak tidak benar.

Tetapi perhatikan juga bahwa pada akhirnya di tempat yang lebih baik, rekayasa perangkat lunak dilakukan dengan tinjauan kode. Itu adalah penulis suatu program harus meyakinkan setidaknya satu orang lain bahwa program tersebut bekerja dengan benar. Itulah poin beberapa argumen informal tingkat tinggi dibuat. Tetapi sekali lagi biasanya tidak ada yang dekat dengan definisi yang benar tentang kebenaran atau bukti kebenaran yang terjadi.

Dalam matematika orang berfokus pada kebenaran. Dalam pengembangan perangkat lunak ada banyak hal yang perlu diperhatikan oleh seorang programmer dan ada trade-off di antara mereka. Memiliki perangkat lunak bebas bug atau bahkan definisi yang benar tentang kebenaran (dengan persyaratan berubah dari waktu ke waktu) adalah ideal, tetapi itu harus ditukar dengan faktor-faktor lain dan salah satu yang paling penting di antara mereka adalah waktu yang dihabiskan untuk mengembangkannya dengan yang sudah ada pengembang. Jadi dalam praktiknya di tempat yang lebih baik tujuan dan proses mengurangi risiko bug sebanyak mungkin daripada membuat perangkat lunak bebas bug.


Saya sebenarnya tidak yakin siapa yang lebih buruk antara programmer dan matematikawan secara formal (yaitu dengan cara yang diperiksa mesin) merumuskan spesifikasi kebenaran dan membuktikan kode yang benar untuk, katakanlah, 10KLOC atau program yang lebih besar. Di satu sisi, Anda sepenuhnya benar bahwa sebagian besar programmer tidak memiliki keterampilan membuktikan teorema yang berkembang dengan baik. Di sisi lain, bukti formal besar seperti program besar dan pada dasarnya memerlukan keterampilan rekayasa perangkat lunak untuk mengelola. Saya benar-benar yakin bukti informal tentang kebenaran untuk program semacam itu tidak akan memiliki harapan untuk menjadi benar.
Derek Elkins

Mungkin. Dalam kasus apa pun dan hanya untuk mengklarifikasi, saya tidak mengambil tentang bukti formal dalam jawaban saya, hanya bukti informal di tingkat yang kita lihat katakan dalam makalah algoritma.
Kaveh

11

Sudah ada banyak jawaban bagus tetapi masih ada banyak alasan mengapa matematika dan pemrograman tidak sama.

1 Bukti matematika cenderung jauh lebih sederhana daripada program komputer. Pertimbangkan langkah-langkah pertama dari bukti hipotetis:

Biarkan a menjadi bilangan bulat

Biarkan b menjadi bilangan bulat

Misalkan c = a + b

Sejauh ini buktinya baik-baik saja. Mari kita ubah itu menjadi langkah pertama dari program serupa:

Biarkan a = input ();

Biarkan b = input ();

Misalkan c = a + b;

Kami sudah memiliki segudang masalah. Dengan asumsi bahwa pengguna benar-benar memasukkan bilangan bulat, kita harus memeriksa batasannya. Adalah suatu yang lebih besar dari -32.768 (atau apa pun min int pada sistem Anda)? Adalah sebuah kurang dari 32.767? Sekarang kita harus memeriksa hal yang sama untuk b . Dan karena kami telah menambahkan a dan b programnya tidak benar kecuali a + blebih besar dari -32768 dan kurang dari 32767. Itu 5 kondisi terpisah yang harus dikhawatirkan oleh seorang programmer yang bisa diabaikan oleh seorang ahli matematika. Tidak hanya programmer harus khawatir tentang mereka, dia harus mencari tahu apa yang harus dilakukan ketika salah satu dari kondisi tersebut tidak terpenuhi dan menulis kode untuk dilakukan kapan pun dia telah memutuskan adalah cara untuk menangani kondisi tersebut. Matematika itu sederhana. Pemrogramannya sulit.

2 Penanya tidak mengatakan apakah dia merujuk pada kesalahan waktu kompilasi atau kesalahan waktu berjalan, tetapi para programmer umumnya tidak peduli dengan kesalahan waktu kompilasi. Compiler menemukannya dan mudah diperbaiki. Mereka seperti kesalahan ketik. Seberapa sering orang mengetik beberapa paragraf tanpa kesalahan pertama kali?

3 Pelatihan.Sejak usia sangat muda kita diajarkan untuk berhitung, dan kita menghadapi konsekuensi kesalahan kecil berulang-ulang. Seorang ahli matematika yang terlatih harus mulai memecahkan masalah aljabar multi-langkah biasanya di sekolah menengah dan harus melakukan lusinan (atau lebih) masalah seperti itu setiap minggu selama satu tahun. Satu tanda negatif yang hilang menyebabkan seluruh masalah salah. Setelah aljabar masalah menjadi lebih lama dan lebih sulit. Programmer, di sisi lain, biasanya memiliki pelatihan yang jauh lebih formal. Banyak yang belajar sendiri (setidaknya pada awalnya) dan tidak mendapatkan pelatihan formal sampai universitas. Bahkan di tingkat universitas, para programmer harus mengambil beberapa kelas matematika sementara para matematikawan mungkin mengambil satu atau dua kelas pemrograman.


10

Saya suka jawaban Yuval, tapi saya ingin mengatasinya sebentar. Salah satu alasan Anda mungkin menemukan lebih mudah untuk menulis bukti Matematika mungkin bermuara pada bagaimana ontologi Matematika platonis. Untuk melihat apa yang saya maksud, pertimbangkan hal berikut:

  • Fungsi dalam Matematika murni (seluruh hasil pemanggilan fungsi benar-benar dienkapsulasi dalam nilai pengembalian, yang bersifat deterministik dan dihitung sepenuhnya dari nilai input).
  • Matematika tidak memiliki mutasi atau penugasan kembali (ketika Anda perlu memodelkan hal-hal seperti itu, fungsi dan urutan digunakan).
  • Matematika secara referensial transparan (misalnya tidak ada pointer, tidak ada gagasan tentang panggilan dengan nama vs panggilan dengan nilai) dan objek matematika memiliki semantik kesetaraan ekstensional (jika "dua" benda itu sama dalam setiap cara yang dapat diamati, maka mereka sebenarnya hal yang sama).

Meskipun dapat diperdebatkan apakah pembatasan di atas membuat penulisan suatu program lebih mudah, saya pikir ada kesepakatan luas bahwa pembatasan di atas membuat penalaran tentang suatu program lebih mudah. Hal utama yang Anda lakukan ketika menulis bukti Matematika adalah alasan tentang bukti yang Anda tulis saat ini (karena, tidak seperti dalam pemrograman, Anda tidak perlu menduplikasi upaya dalam Matematika karena abstraksi gratis), jadi umumnya layak untuk bersikeras pada pembatasan di atas.


7

Bukti matematika mendasar tidak sama dengan aplikasi dunia nyata, yang dirancang untuk memenuhi kebutuhan manusia hidup.

Manusia akan mengubah keinginan, kebutuhan, dan persyaratan mereka pada apa yang mungkin menjadi basis harian dalam bidang program komputer.

Apa yang begitu berbeda tentang penulisan bukti matematis tanpa cacat dan penulisan kode komputer tanpa cacat yang membuatnya sedemikian rupa sehingga yang pertama jauh lebih mudah ditelusuri daripada yang terakhir?

Dengan persyaratan sejelas masalah matematika, program yang sempurna dapat ditulis. Membuktikan bahwa algoritma Dijkstra dapat menemukan jalur terpendek antara dua titik pada grafik tidak sama dengan mengimplementasikan program yang menerima input sewenang-wenang dan menemukan titik terpendek antara dua titik di dalamnya.

Ada masalah memori, kinerja, dan perangkat keras yang harus dikelola. Saya berharap kita tidak dapat berpikir tentang itu ketika menulis algoritma, bahwa kita dapat menggunakan konstruksi murni dan fungsional untuk mengelola ini, tetapi program komputer hidup di dunia "nyata" perangkat keras sedangkan bukti matematis berada di ... "teori".


Atau, untuk lebih ringkas :

masukkan deskripsi gambar di sini


4

Melihatnya dari sudut lain, dalam lingkungan non-akademis sering kali menjadi masalah uang.

Seperti yang dinyatakan oleh tulisan lain dengan baik, Matematika adalah spesifikasi abstrak tunggal, oleh karena itu bukti perlu bekerja secara konsisten hanya dalam spesifikasi yang harus dibuktikan. Sebuah program komputer dapat beroperasi pada banyak implementasi spesifikasi abstrak matematika - yaitu cara satu bahasa, atau produsen perangkat keras menerapkan matematika floating point mungkin sedikit berbeda dari yang lain yang dapat menyebabkan sedikit fluktuasi hasil.

Dengan demikian, 'membuktikan' program komputer sebelum menulis itu akan melibatkan pembuktian logika pada tingkat perangkat keras, tingkat sistem operasi, tingkat driver, bahasa pemrograman, kompiler, mungkin juru bahasa dan sebagainya, untuk setiap kemungkinan kombinasi perangkat keras yang dimiliki program tersebut. bisa dijalankan dan mungkin data apa pun yang diminumnya. Anda mungkin akan menemukan tingkat persiapan dan pemahaman ini tentang misi ruang angkasa, sistem senjata atau sistem kontrol tenaga nuklir, di mana kegagalan berarti puluhan miliar dolar yang hilang dan berpotensi banyak nyawa yang hilang, tetapi tidak banyak yang lain.

Untuk programmer dan / atau bisnis 'sehari-hari' Anda, jauh, jauh lebih hemat biaya untuk menerima tingkat akurasi tertentu dalam sebagian besar kode yang benar dan menjual produk yang dapat digunakan, dan pengembang dapat memperbaiki bug secara retroaktif saat mereka ditemukan selama prosesnya. pemakaian.


3
Anda tampaknya memiliki pandangan sempit tentang apa matematika itu dan pandangan yang terlalu luas tentang apa yang "membuktikan" memerlukan program komputer. Anda tidak perlu membuktikan keseluruhan sistem dengan benar untuk membuktikan suatu program benar, Anda hanya perlu membuktikan bahwa itu benar dengan asumsi komponen lain memenuhi spesifikasinya. Jika tidak, itu bukan kesalahan program Anda. Di sisi lain, jika program Anda rusak karena tergantung pada detail yang bukan bagian dari spesifikasi komponen-komponen itu, misalnya variasi implementasi IEEE754, maka itu adalah kesalahan Anda.
Derek Elkins

Komentar yang adil. Saya cenderung menyalahgunakan beberapa terminologi karena ini bukan latar belakang akademis saya. Walaupun saya merasa bahwa mengasumsikan bahwa komponen-komponen lain itu sempurna bukan hal yang bijaksana untuk dilakukan, karena komentar saya sebelumnya.
navigator_

4

Saya pikir alasan Anda valid, tetapi input Anda tidak. Bukti matematika sama sekali tidak lebih toleran terhadap kesalahan daripada program, jika keduanya ditulis oleh manusia. Dijkstra sudah dikutip di sini, tetapi saya akan menawarkan penawaran tambahan.

Namun kita harus mengatur perhitungan sedemikian rupa sehingga kekuatan kita yang terbatas cukup untuk menjamin bahwa perhitungan akan menghasilkan efek yang diinginkan. Pengorganisasian ini mencakup komposisi program dan di sana kita dihadapkan dengan masalah ukuran berikutnya, yaitu. panjang teks program, dan kita harus memberikan masalah ini juga pengakuan eksplisit. Kita harus tetap menyadari fakta bahwa sejauh mana kita dapat membaca atau menulis teks sangat tergantung pada ukurannya. [...]

Dalam suasana yang sama saya ingin menarik perhatian pembaca pada fakta bahwa "kejelasan" telah menyatakan aspek-aspek kuantitatif, fakta yang oleh banyak matematikawan, cukup aneh, tampaknya tidak menyadarinya. Teorema yang menyatakan validitas kesimpulan ketika sepuluh halaman penuh dengan kondisi terpenuhi bukanlah alat yang mudah, karena semua kondisi harus diverifikasi setiap kali teorema tersebut diajukan. Dalam geometri Euclidean, Teorema Pythagoras berlaku untuk setiap tiga titik A, B dan C sedemikian sehingga melalui A dan C garis lurus dapat ditarik ortogonal ke garis lurus melalui B dan C. Berapa banyak matematikawan yang menghargai bahwa teorema tetap berlaku ketika beberapa atau semua poin A, B, dan C bertepatan? namun ini tampaknya sebagian besar bertanggung jawab atas kenyamanan yang dengannya Teorema Pythagoras dapat digunakan.

Meringkas: sebagai manusia yang berakal, saya memiliki kepala yang sangat kecil dan saya lebih baik belajar untuk hidup dengannya dan untuk menghormati keterbatasan saya dan memberi mereka kredit penuh, daripada mencoba untuk mengabaikannya, karena upaya sia-sia yang terakhir akan menjadi dihukum karena kegagalan.

Ini sedikit diedit tiga paragraf terakhir dari bab pertama Pemrograman Terstruktur Dijkstra.

Untuk mungkin mengulangi ini, untuk menerapkan lebih baik untuk pertanyaan Anda: kebenaran sebagian besar adalah fungsi ukuran bukti Anda. Ketepatan bukti matematis yang panjang sangat sulit untuk dibangun (banyak "bukti" yang diterbitkan hidup dalam ketidakpastian karena tidak ada yang benar-benar memverifikasi mereka). Tetapi, jika Anda membandingkan kebenaran program sepele dengan bukti sepele, kemungkinan tidak ada perbedaan nyata. Namun, asisten bukti otomatis (dalam arti yang lebih luas, kompiler Java Anda juga merupakan asisten bukti), biarkan program menang dengan mengotomatiskan banyak pekerjaan dasar.


Apa yang Anda maksud dengan "bukti matematis panjang"? Buktikan teorema minor minor ini cukup panjang, tetapi tidak terlalu diperdebatkan oleh siapa pun. Teorema Feit-Thompson memiliki bukti yang cukup panjang, tetapi tidak pernah benar-benar limbo. Bagaimana Anda membandingkan panjang bukti dan program? Jumlah kata? Apakah benar-benar tidak ada perbedaan nyata antara bukti dan program ketika Anda membandingkan bukti dan program dengan kompleksitas yang sama (panjang)?
Yuval Filmus

@YuvalFilmus seperti dalam kutipan: sepuluh halaman pernyataan panjang bagi manusia. Bagaimana saya menilai tentang panjang program? Nah, Dikstra menawarkan metrik: panjang teksnya. Saya pikir itu mungkin terlalu sederhana, tetapi itu adalah heuristik yang baik. Ada metrik lain yang lebih menarik, seperti, misalnya, kompleksitas siklomatik
wvxvw

3

Seperti jawaban lain telah menyentuh dalam jawaban mereka (saya ingin menguraikan), tetapi sebagian besar masalah adalah penggunaan perpustakaan. Bahkan dengan dokumentasi yang sempurna (seperti kode bugless), tidak mungkin untuk mentransfer pengetahuan lengkap perpustakaan ke setiap pemrogram yang menggunakan perpustakaan. Jika pemrogram tidak sepenuhnya memahami perpustakaan mereka, mereka dapat membuat kesalahan saat menggunakannya. Kadang-kadang ini dapat mengakibatkan bug kritis yang ditemukan ketika kode tidak berfungsi. Tetapi untuk bug minor, ini mungkin tidak diperhatikan.

Situasi serupa akan terjadi jika ahli matematika menggunakan bukti dan lemma yang ada tanpa sepenuhnya memahaminya; bukti mereka sendiri kemungkinan besar akan cacat. Meskipun ini mungkin menyarankan solusi adalah dengan sempurna mempelajari setiap perpustakaan yang digunakan; ini praktis sangat memakan waktu dan mungkin membutuhkan pengetahuan domain yang tidak dimiliki oleh programmer. (Saya tahu sedikit tentang sekuensing DNA / sintesis protein; namun dapat bekerja dengan konsep-konsep ini menggunakan perpustakaan).

Secara lebih ringkas, rekayasa perangkat lunak (rekayasa secara umum benar-benar) didasarkan pada merangkum berbagai tingkat abstraksi untuk memungkinkan orang untuk fokus pada area yang lebih kecil dari masalah yang menjadi spesialisasi mereka. Hal ini memungkinkan orang untuk mengembangkan keahlian di bidang mereka, tetapi juga membutuhkan komunikasi yang sangat baik antara setiap lapisan. Ketika komunikasi itu tidak sempurna, itu menyebabkan masalah.


3
Tunggu, apa yang membuat Anda berpikir ahli matematika "memahami sepenuhnya" bukti dan lemma yang mereka gunakan? Saya tidak yakin apa perbedaan antara matematikawan dan programmer yang coba Anda tunjukkan di sini.
Derek Elkins

3

Saya akan mencoba menjadi orisinil setelah semua jawaban bagus itu.

Program adalah bukti

The Curry-Howard isomorphism memberitahu kita, jenis dalam program Anda adalah teorema dan kode aktual adalah bukti mereka.

Memang, ini adalah pandangan yang sangat abstrak dan tingkat tinggi. Masalah yang Anda, mungkin, maksudkan, adalah bahwa menulis kode khusus lebih sulit karena terlalu rendah. Dalam kebanyakan kasus, Anda "perlu memberi tahu mesin apa yang harus dilakukan". Atau, untuk melihat ini dari sudut lain: matematikawan sangat pandai abstraksi.

Sebagai catatan: "Musik aliran" adalah salah satu jembatan terindah di antara keduanya. Pada dasarnya set up hal yang bisa mengatakan "Saya ingin ini di bahwa cara" dan mesin ajaib melakukan ini persis seperti yang diinginkan.


Saya tidak sepenuhnya melihat apakah ini menjawab pertanyaan. OP tidak membuat indikasi bahwa mereka berbicara tentang bahasa pemrograman dengan sistem tipe yang kuat, dan saya pikir itu berarti sistem tipe yang lebih umum. Jadi Curry-Howard agak sepele dalam kasus ini.
6005

Saya tahu itu agak dibuat-buat untuk C atau hal-hal serupa. Tapi poin saya adalah: matematika lebih dekat daripada yang mungkin dipikirkan oleh seorang pemula CS biasa!
Oleg Lobachev

1
Tampaknya Anda adalah 'pengamat yang ceroboh' dari isomorfisme Curry-Howards, yang saya sebutkan dalam jawaban saya. Bahkan jika kita memiliki isomorfisme antara program dan bukti, itu tidak berarti bahwa tindakan menulis program dan menulis bukti sama sekali. Bahkan, mungkin bahkan kasus bahwa semua program 'menarik' atau 'khas' tidak sesuai dengan bukti khas dan sebaliknya.
Kadal diskrit

@ Discretelizard Jelas bukan itu kasus bahwa program "menarik" tidak sesuai dengan "bukti khas". Berikut adalah contoh di mana saya mengambil "bukti khas" seseorang dan menghasilkan (sketsa) program yang tidak dapat disangkal menarik (sesuatu yang terkait erat dengan eliminasi Gaussian). Dilengkapi dengan jenis yang tepat, saya pikir sebagian besar program "menarik" akan menjadi lemma atau teorema yang berguna, tetapi banyak bukti (konstruktif) tidak memiliki signifikansi komputasi yang nyata - mereka hanya memverifikasi kondisi sisi - meskipun sangat banyak yang melakukannya.
Derek Elkins

3

Tidak satu pun dari banyak jawaban lain yang menunjukkan hal berikut. Bukti matematika beroperasi pada sistem komputasi imajiner yang memiliki memori tak terbatas dan daya komputasi tak terbatas. Oleh karena itu mereka dapat menyimpan angka yang besar secara arbitrer hingga presisi tak terbatas, dan tidak kehilangan presisi dalam perhitungan apa pun.

π


2
"Bukti matematika beroperasi pada sistem komputasi imajiner yang memiliki memori tak terbatas dan daya komputasi tak terbatas." Sebagian besar bukti matematis 'beroperasi' pada sistem aljabar formal, misalnya bilangan real (di mana kita memiliki 'ketepatan tanpa batas'). Ini juga dapat dilakukan dalam program: ada yang disebut sistem aljabar komputer (CAS) yang melakukan ini! Selain itu, seluruh bidang matematika berkaitan dengan fakta bahwa kita tidak dapat mewakili semua bilangan real persis seperti angka floating point yang terbatas. Saya pikir Anda membuat perbedaan antara matematika dan pemrograman di mana tidak ada.
Kadal diskrit

1
@ Discretelizard, ya, ada paket khusus dengan presisi yang berubah-ubah, tetapi meskipun demikian, memori yang tersedia akan membatasi presisi yang sebenarnya dapat dicapai. Mereka juga paket khusus . Hanya sebagian kecil pemrograman yang dilakukan dengan paket-paket seperti itu, dan sebagian besar dalam lingkungan akademik.
crobar

π

@ Discretelizard, saya pikir poin saya masih berlaku, sebagian besar programmer tidak menggunakan sistem CAS seperti itu. Mereka terlalu lambat untuk pemrograman dunia nyata. Sebagian besar pemrograman pada dasarnya melibatkan operasi pada angka presisi terbatas. Bahasa teratas adalah C, C ++, Python, Java, dll. Tidak ada yang menggunakan representasi gaya CAS secara default (walaupun paket untuk melakukan ini mungkin dibuat di dalamnya). Contoh tanggapan Anda adalah subset kecil dari bahasa / sistem komputer.
crobar

2
@crobar Masalah dengan jawaban Anda adalah bahwa sebagian besar bug yang terdeteksi bukan karena kesalahan floating point atau bilangan bulat bilangan bulat (meskipun hal itu berkontribusi jumlah yang layak, dan aspek-aspek tersebut pasti membuat kebenaran penuh dari suatu program jauh lebih tidak mungkin). Anda bisa, bagaimanapun, membuat klaim yang lebih umum bahwa matematikawan kekurangan banyak perhatian programmer seperti kinerja, waktu-ke-pasar, pemeliharaan, dan kemampuan terbatas untuk mengubah persyaratan jika terbukti terlalu menantang.
Derek Elkins

3

Ini bukan. Bukti matematika pada dasarnya sama persis seperti kereta, hanya saja pembaca mereka lebih permisif daripada seorang penyusun. Demikian pula, para pembaca program komputer mudah tertipu untuk percaya itu benar, setidaknya sampai mereka mencoba menjalankannya.

Misalnya, jika kami mencoba menerjemahkan bukti matematika ke dalam bahasa formal seperti ZFC, itu juga akan mengandung bug. Itu karena bukti-bukti ini bisa sangat lama sehingga kami terpaksa menulis sebuah program untuk menghasilkan bukti. Hanya sedikit orang yang menghadapi masalah, dalam bahaya, meskipun ada penelitian aktif dalam memformalkan bukti-bukti dasar.

Dan memang, matematika bisa mendapatkan BSOD! Ini bukan pertama kalinya!

masukkan deskripsi gambar di sini

Gagasan ortodoks ini bahwa semua bukti matematika yang telah cukup diverifikasi pada dasarnya benar atau dapat dibuat benar adalah yang sama memotivasi proyek perangkat lunak Anda di tempat kerja: selama kita tetap pada roadmap, kita akan mengeluarkan semua bug dan fitur lengkap - ini merupakan proses berulang yang mengarah ke produk akhir yang pasti.

Inilah sisi sebaliknya. Lihat, kami sudah mendapatkan dana, memvalidasi konsep bisnis, semua dokumen ada di sini untuk Anda baca. Kami hanya ingin Anda mengeksekusi dan itu pasti!

Jangan merasa kasihan pada Hilbert juga, dia tahu apa yang sedang dia hadapi. Itu hanya bisnis.

Jika Anda ingin benar-benar yakin, ambil semuanya berdasarkan kasus per kasus dan buat kesimpulan Anda sendiri!


3

Saya melihat dua alasan penting mengapa program lebih rentan kesalahan daripada bukti matematika:

1: Program berisi variabel atau objek dinamis yang berubah seiring waktu, sedangkan objek matematika dalam pembuktian biasanya statis. Dengan demikian, notasi dalam matematika dapat digunakan sebagai dukungan langsung dari penalaran, (dan jika a = b, ini tetap terjadi) di mana ini tidak berfungsi dalam program. Juga, masalah ini menjadi jauh lebih buruk di mana program paralel atau memiliki banyak utas.

2: Matematika sering mengasumsikan objek yang didefinisikan dengan relatif rapi (grafik, manifold, cincin, grup, dll.) Sedangkan pemrograman berkaitan dengan objek yang sangat berantakan dan agak tidak beraturan: aritmatika presisi terbatas, tumpukan terbatas, konversi bilangan bulat karakter, pointer, sampah yang memerlukan pengumpulan , dll. Oleh karena itu, kumpulan kondisi yang relevan dengan kebenaran sangat sulit untuk diingat.


3

Anda harus membedakan dua "kategori" yang berbeda:

  • pseudo-proofs (atau pseudo-code) - itulah yang Anda lihat di buku. Itu ditulis dalam bahasa alami (misalnya dalam bahasa Inggris). Itulah yang harus Anda gunakan untuk belajar Matematika (atau Algoritma).
  • bukti formal (atau kode formal) - Anda menulisnya saat Anda membutuhkan bukti (atau kode) Anda untuk diverifikasi secara mekanis (atau dapat dieksekusi). Representasi semacam itu tidak memerlukan "kecerdasan manusia". Itu dapat diverifikasi (atau dieksekusi) secara mekanis, dengan mengikuti beberapa langkah yang telah ditentukan (biasanya dilakukan oleh komputer saat ini).

Kami telah menggunakan pseudo-code selama ribuan tahun (misalnya algoritma Euclids). Menulis kode formal (dalam bahasa formal seperti C atau Java) menjadi sangat populer dan berguna setelah ditemukannya komputer. Tetapi, sayangnya, bukti formal (dalam bahasa formal seperti Principia Mathematica atau Metamath) tidak terlalu populer. Dan karena semua orang menulis bukti palsu hari ini, orang sering berdebat tentang bukti baru. Kesalahan di dalamnya dapat ditemukan bertahun-tahun, dekade atau bahkan berabad-abad setelah "pembuktian" yang sebenarnya.


3

Saya tidak dapat menemukan referensi, tetapi saya pikir Tony Hoare pernah mengatakan sesuatu di sepanjang baris berikut: Perbedaan antara memeriksa program dan memeriksa bukti adalah bahwa bukti dapat diperiksa dua baris sekaligus.

Dalam satu kata: lokalitas.

Bukti ditulis sehingga mereka dapat dengan mudah diperiksa. Program ditulis sehingga mereka dapat dieksekusi. Untuk alasan ini, pemrogram biasanya meninggalkan informasi yang akan berguna bagi seseorang yang memeriksa program.

Pertimbangkan program ini, di mana x hanya-baca

    assume x >= 0
    p := 0 ;
    var pp := 0 ;
    while( x >= pp + 2*p + 1 ) 
    {
        var q := 1 ;
        var qq := q ;
        var pq := p ;
        while(  pp + 4*pq + 4*qq <= x )
        {
            q, pq, qq := 2*q, 2*pq, 4*qq ;
        }
        p, pp := p + q, pp + 2*pq + qq ;
    }
    assert  p*p <= x < (p+1)*(p+1)

Mudah dieksekusi, tetapi sulit untuk diperiksa.

Tetapi jika saya menambahkan kembali dalam pernyataan yang hilang, Anda dapat memeriksa program secara lokal dengan hanya memeriksa bahwa setiap urutan penugasan sudah benar dengan memperhatikan pra-dan postkondisinya dan bahwa, untuk setiap loop, postkondisi dari loop diimplikasikan oleh invarian dan negasi dari guard loop.

    assume x >= 0
    p := 0 ;
    var pp := 0 ; 
    while( x >= pp + 2*p + 1 ) 
        invariant p*p <= x 
        invariant pp == p*p
        decreases x-p*p 
    {
        var q := 1 ;
        var qq := q ; 
        var pq := p ; 
        while(  pp + 4*pq + 4*qq <= x )
            invariant (p+q)*(p+q) <= x
            invariant q > 0 
            invariant qq == q*q 
            invariant pq == p*q 
            decreases x-(p+q)*(p+q)
        {
            q, pq, qq := 2*q, 2*pq, 4*qq ;
        }
        assert (p+q)*(p+q) <= x and pp==p*p and pq==p*q and qq==q*q and q>0
        p, pp := p + q, pp + 2*pq + qq ;
    }
    assert  p*p <= x < (p+1)*(p+1)

Kembali ke pertanyaan awal: Mengapa menuliskan bukti matematis lebih membuktikan kesalahan daripada menulis kode komputer? Karena bukti dirancang agar mudah diperiksa oleh pembaca mereka, mereka mudah diperiksa oleh penulisnya dan karenanya penulis yang waspada cenderung tidak membuat (atau setidaknya menyimpan) kesalahan logis dalam bukti mereka. Ketika kita memprogram, kita sering gagal menuliskan alasan bahwa kode kita benar; akibatnya adalah sulit bagi pembaca dan pembuat program untuk memeriksa kode; hasilnya adalah penulis membuat (dan kemudian menyimpan) kesalahan.

Tapi ada harapan. Jika, ketika kita menulis suatu program, kita juga menuliskan alasan kita menganggap program itu benar, kita kemudian dapat memeriksa kodenya ketika kita menuliskannya dan dengan demikian menulis lebih sedikit kode buggy. Ini juga bermanfaat bagi orang lain untuk membaca kode kami dan memeriksanya sendiri.


2

Kita dapat bertanya apakah lebih sulit dalam praktiknya , atau pada prinsipnya , untuk menulis bukti atau menulis kode.

Dalam praktiknya, membuktikan jauh lebih sulit daripada pengkodean. Sangat sedikit orang yang telah mengambil dua tahun matematika tingkat perguruan tinggi dapat menulis bukti, bahkan yang sepele. Di antara orang-orang yang telah mengambil dua tahun CS tingkat perguruan tinggi, mungkin setidaknya 30% dapat menyelesaikan FizzBuzz .

Namun pada prinsipnya , ada alasan mendasar mengapa sebaliknya. Bukti dapat, setidaknya secara prinsip, diperiksa kebenarannya melalui proses yang tidak memerlukan penilaian atau pemahaman apa pun. Program tidak bisa - kita bahkan tidak bisa mengatakan, melalui proses yang ditentukan, apakah suatu program akan berhenti.


3
Dua tahun kuliah tingkat matematika tidak berarti dua tahun terfokus pada penulisan bukti (atau menghabiskan setiap waktu menulis bukti). Yang mengatakan, kesan saya adalah bahwa umum untuk kelas geometri sekolah menengah / awal untuk menyertakan bukti, jadi tampaknya kita dapat mengharapkan bahkan anak usia 13 tahun untuk dapat menulis bukti sederhana dengan kurang dari satu tahun sekolah pendidikan pada tema. Perhitungan aljabar langkah demi langkah juga pada dasarnya adalah bukti. Saya pikir Anda meletakkan bar untuk "sepele" untuk pemrograman terlalu rendah dan untuk membuktikan terlalu tinggi.
Derek Elkins

3
Kita bisa menulis program dengan cara yang sama. Anda bisa membayangkan persyaratan bahwa setiap fungsi / prosedur yang Anda tulis harus memberikan spesifikasi formal dan bukti (dalam Coq, katakanlah) bahwa itu memenuhi spesifikasi. Kemudian ada cara untuk memeriksa bukti itu dengan benar dengan cara yang tidak memerlukan penilaian atau pemahaman apa pun.
DW

@ DW: Anda mengasumsikan bahwa (1) perilaku yang diinginkan dapat ditentukan secara penuh dalam semua kasus, (2) bukti yang diperlukan ada (yaitu, masalahnya tidak dapat diputus-putus), dan (3) jika buktinya ada, maka kami dapat menemukannya. Saya pikir ketiga asumsi ini salah dalam setidaknya beberapa kasus (mungkin hampir semua kasus). Re 3, perhatikan bahwa meskipun beberapa bukti mungkin mudah, banyak bukti sangat sulit ditemukan.
Ben Crowell

@DerekElkins: Klaim saya bahwa sangat sedikit mahasiswa yang dapat menulis bahkan bukti sepele didasarkan pada pengalaman saya sendiri dengan siswa saya. Ini di community college, jadi YMMV. Fakta bahwa beberapa kelas geometri sekolah menengah memasukkan dosis penulisan bukti yang banyak tidak berarti fakta bahwa semua mahasiswa dapat menulis bukti. Mereka juga seharusnya tahu bagaimana melakukan aljabar dasar, tetapi di sekolah saya kira-kira setengah dari siswa baru tidak bisa - yang membantu menjelaskan mengapa begitu banyak yang gagal.
Ben Crowell

Itu akan menjadi penjelasan yang baik untuk ditambahkan ke jawaban, untuk menjelaskan mengapa Anda tidak dapat mengambil pendekatan yang sama untuk memeriksa kebenaran program. Secara umum (2) dan (3) jarang menjadi masalah, baik dalam praktik atau secara prinsip (jika Anda tidak dapat membuktikan programnya benar, tulis dengan cara yang berbeda sampai Anda dapat membuktikannya dengan benar). Namun (1) Anda adalah poin penting, dan saya pikir itu akan memperkuat jawaban untuk menjelaskan mengapa hal itu membuat sulit untuk melakukan hal yang sama untuk program seperti yang kita lakukan untuk pembuktian.
DW

2

Hanya sebagian kecil dari pernyataan matematika yang benar yang dapat dibuktikan secara praktis. Lebih penting lagi, tidak mungkin untuk membangun set aksioma matematis non-sepele (*) yang akan memungkinkan semua pernyataan benar untuk dibuktikan. Jika seseorang hanya perlu menulis program untuk melakukan sebagian kecil dari hal-hal yang dapat dilakukan dengan komputer, akan mungkin untuk menulis perangkat lunak yang benar-benar terbukti, tetapi komputer sering diminta untuk melakukan hal-hal di luar jangkauan apa yang terbukti benar benar perangkat lunak dapat mencapai.

(*) Adalah mungkin untuk mendefinisikan seperangkat aksioma yang akan memungkinkan semua pernyataan benar untuk disebutkan, dan dengan demikian terbukti, tetapi itu umumnya tidak terlalu menarik. Meskipun dimungkinkan untuk secara resmi mengkategorikan serangkaian aksioma ke dalam aksioma yang atau tidak, secara relatif, non-sepele, poin kuncinya adalah bahwa keberadaan pernyataan yang dapat dibuktikan yang benar tetapi tidak dapat dibuktikan bukanlah cacat dalam suatu set. aksioma. Menambahkan aksioma untuk membuat pernyataan yang benar tetapi tidak dapat dibuktikan yang dapat dibuktikan akan menyebabkan pernyataan lain menjadi benar tetapi tanpa dapat dibuktikan.


1
"Hanya sebagian kecil dari pernyataan matematika yang benar yang dapat dibuktikan secara praktis." - Bagaimana Anda mengukur "porsi"? Apakah ini di bawah beberapa distribusi probabilitas? Apakah Anda memiliki bukti untuk mendukung pernyataan ini?
DW

"Komputer sering diminta untuk melakukan hal-hal di luar jangkauan yang dapat dicapai oleh perangkat lunak yang benar-benar terbukti." - Apakah Anda punya bukti untuk ini? Apakah kamu punya contoh? Apakah Anda mengklaim "melampaui apa yang secara prinsip dapat dibuktikan benar" atau "melampaui apa yang dapat kita bayangkan terbukti dalam praktiknya"?
DW

@DW: Jika X dan Y adalah pernyataan ortogonal yang benar tetapi tidak dapat dibuktikan, maka untuk setiap pernyataan P yang dapat dibuktikan, akan ada setidaknya dua pernyataan ortogonal (P dan X), dan (P dan Y) yang benar tetapi tidak -dapat terbukti. Ketika berhadapan dengan himpunan tak terbatas, logika seperti itu tidak serta merta membuktikan apa pun, karena seseorang dapat menggunakan logika serupa untuk menunjukkan bahwa ada bilangan bulat genap dua kali lebih banyak daripada bilangan bulat ganjil, karena untuk setiap bilangan bulat ganjil satu dapat mengidentifikasi dua bilangan bulat genap (4x) dan (4x + 2) yang tidak terkait dengan bilangan bulat ganjil lainnya, tetapi tentu saja bilangan bulat genap dan ganjil memiliki kardinalitas yang sama.
supercat

@DW: Ungkapan "sebagian kecil" dengan demikian hanya benar-benar masuk akal dalam menggambarkan fraksi pernyataan benar yang dapat dibuktikan secara praktis, tetapi saya pikir itu berguna untuk memahami bahwa ketidakmampuan untuk membuktikan semua pernyataan yang benar bukanlah "cacat". Sedangkan untuk komputer, banyak bidang secara rutin menggunakan algoritme yang memiliki probabilitas kegagalan yang sangat kecil, tetapi tidak nol, dan kemudian menyetelnya sehingga kemungkinannya rendah (mis. Di bawah peralatan yang terkena meteor). Dalam banyak kasus, berbagai mode kegagalan tidak independen, jadi mungkin pada dasarnya tidak mungkin ...
supercat

... untuk menentukan probabilitas berbagai kombinasi kegagalan. Jika seseorang memperkirakan probabilitas kegagalan selama periode satu menit sewenang-wenang menjadi satu dari 10 ^ -500, seseorang dapat dimatikan oleh ratusan pesanan besar dan masih memiliki sistem yang dapat diandalkan, tetapi jika seseorang tidak aktif dengan 494 pesanan besarnya sistem akan gagal sekitar sekali setiap beberapa tahun.
supercat

2
  1. Program komputer diuji di dunia nyata. Kesalahan teknis yang rumit dalam bukti matematis yang panjang, yang hanya dapat dipahami oleh sejumlah kecil orang, memiliki peluang bagus untuk tetap tidak terdeteksi. Jenis kesalahan yang sama dalam produk perangkat lunak cenderung menghasilkan perilaku aneh yang diperhatikan pengguna biasa. Jadi premisnya mungkin tidak benar.

  2. Program komputer melakukan fungsi dunia nyata yang bermanfaat. Mereka tidak harus 100% benar untuk melakukan ini, dan standar kebenaran yang tinggi cukup mahal. Bukti hanya berguna jika mereka benar-benar membuktikan sesuatu, sehingga melewatkan bagian '100% benar' bukanlah pilihan bagi matematikawan.

  3. Bukti matematika didefinisikan dengan jelas. Jika bukti cacat, penulis telah melakukan kesalahan. Banyak bug dalam program komputer terjadi karena persyaratan tidak dikomunikasikan dengan benar, atau ada masalah kompatibilitas dengan sesuatu yang belum pernah didengar oleh programmer.

  4. Banyak program komputer tidak dapat dibuktikan benar. Mereka mungkin memecahkan masalah yang didefinisikan secara informal seperti mengenali wajah. Atau mereka mungkin seperti perangkat lunak prediksi pasar saham dan memiliki tujuan yang ditentukan secara formal tetapi melibatkan terlalu banyak variabel dunia nyata.


2

Sebagian besar matematika sebagai aktivitas manusia adalah pengembangan bahasa khusus domain di mana verifikasi bukti mudah dilakukan manusia.

Kualitas bukti berbanding terbalik dengan panjang dan kompleksitasnya. Panjang dan kompleksitasnya sering dikurangi dengan mengembangkan notasi yang baik untuk menggambarkan situasi yang sedang kita buat tentang pernyataan, bersama dengan konsep tambahan yang berinteraksi dalam bukti khusus yang sedang dipertimbangkan.

Ini bukan proses yang mudah, dan sebagian besar bukti yang disaksikan oleh orang-orang yang dihapus dari garis depan penelitian kebetulan berada di bidang matematika (seperti aljabar dan analisis) yang telah memiliki ratusan, jika tidak ribuan, tahun di mana notasi bidang itu telah telah disempurnakan ke titik di mana tindakan benar-benar menuliskan bukti terasa seperti angin.

Namun, di garis depan penelitian, terutama jika Anda bekerja pada masalah yang tidak di bidang dengan notasi yang mapan atau berkembang dengan baik, saya akan bertaruh kesulitan bahkan menulis bukti yang benar mendekati kesulitan menulis program yang benar. Ini karena Anda juga harus menulis analog dari desain bahasa pemrograman, melatih jaringan saraf Anda untuk mengompilasinya dengan benar, coba tulis buktinya, kehabisan memori, coba optimalkan bahasa, iterate otak Anda belajar bahasa, menulis buktinya lagi, dll.

Untuk mengulangi, saya pikir bahwa menulis bukti yang benar dapat mendekati kesulitan menulis program yang benar di bidang matematika tertentu, tetapi bidang-bidang itu masih muda dan kurang berkembang karena gagasan kemajuan dalam matematika terkait erat dengan kemudahan pembuktian verifikasi.

Cara lain untuk mengutarakan poin yang ingin saya sampaikan adalah bahwa baik bahasa pemrograman dan matematika pada akhirnya dirancang sedemikian rupa sehingga masing-masing program komputer dan bukti dimungkinkan untuk dikompilasi. Hanya saja menyusun program komputer dilakukan di komputer dan memastikan kebenaran sintaksis yang biasanya tidak ada hubungannya dengan kebenaran program itu sendiri, sementara "menyusun" bukti dilakukan oleh manusia dan memastikan kebenaran sintaksis yang merupakan hal yang sama dengan kebenaran buktinya.


1

Anda jujur ​​membandingkan apel dan jeruk di sini. Anti-kesalahan dan bebas bug bukanlah hal yang sama.

Jika sebuah program membandingkan angka 2dan 3dan mengatakan itu 2 is greater than 3, maka itu bisa jadi karena implementasi kereta:

# Buggy implementation
function is_a_greater_than_b(a,b):
  return b > a

Program ini masih bebas dari kesalahan. Saat membandingkan dua angka adan b, itu akan selalu dapat memberi tahu Anda jika blebih besar dari a. Hanya saja bukan yang seharusnya Anda (programmer) minta komputer lakukan.


2
Apa definisi Anda tentang "kesalahan" dalam suatu program?
user56834

0

a) Karena program komputer lebih besar dari bukti matematika

a.1) Saya percaya bahwa ada lebih banyak orang yang digunakan selama menulis program komputer yang kompleks daripada saat menulis bukti matematika. Artinya margin kesalahan lebih tinggi.

b) Karena CEO / Pemegang Saham lebih peduli tentang uang daripada memperbaiki bug kecil , sementara itu Anda (sebagai pengembang) harus melakukan tugas Anda untuk memenuhi beberapa persyaratan / tenggat waktu / demo

c) Karena Anda bisa menjadi programmer tanpa pengetahuan "mendalam" dalam comp sci, sementara itu akan sulit dilakukan dalam matematika (saya percaya)

Selain itu:

NASA:

Perangkat lunak ini bebas bug. Itu sempurna, sesempurna yang telah dicapai manusia. Pertimbangkan statistik ini: tiga versi terakhir dari program - masing-masing sepanjang 420.000 baris - masing-masing hanya memiliki satu kesalahan. 11 versi terakhir dari perangkat lunak ini memiliki total 17 kesalahan.

Ambil pemutakhiran perangkat lunak untuk mengizinkan antar-jemput bernavigasi dengan Global Positioning Satellites, perubahan yang hanya melibatkan 1,5% dari program, atau 6.366 baris kode. Spesifikasi untuk satu perubahan itu berjalan 2.500 halaman, volume lebih tebal dari buku telepon. Spesifikasi untuk program saat ini mengisi 30 volume dan menjalankan 40.000 halaman.

https://www.fastcompany.com/28121/they-write-right-stuff


"Program komputer lebih besar dari bukti matematika" Itu tergantung pada program dan buktinya. Dan banyak dari ini tampaknya sangat spekulatif.
David Richerby

@ DavidvidRicherby baik saya ada dalam pikiran hal-hal seperti teorema Terakhir fermat dan NASA Apollo github.com/chrislgarry/Apollo-11 math.wisc.edu/~boston/869.pdf - dan kita bahkan tidak berbicara tentang sistem operasi dan sebagainya.
Exeus

0

Tingkat Dasar:

Mari kita lihat hal-hal di tingkat paling sederhana, dan paling dasar.

Untuk matematika, kami memiliki:
2 + 3 = 5

Saya belajar tentang itu ketika saya masih sangat muda. Saya dapat melihat elemen yang paling mendasar: dua objek, dan tiga objek. Bagus.

Untuk pemrograman komputer, kebanyakan orang cenderung menggunakan bahasa tingkat tinggi. Beberapa bahasa tingkat tinggi bahkan dapat "mengkompilasi" menjadi salah satu bahasa tingkat tinggi yang lebih rendah, seperti C. C kemudian dapat diterjemahkan ke dalam bahasa Assembly. Bahasa assembly kemudian dikonversi menjadi kode mesin. Banyak orang berpikir kompleksitas berakhir di sana, tetapi tidak: CPU modern mengambil kode mesin sebagai instruksi, tetapi kemudian jalankan "kode mikro" untuk benar-benar menjalankan instruksi tersebut.

Ini berarti bahwa, pada tingkat paling dasar (berurusan dengan struktur yang paling sederhana), kita sekarang berurusan dengan kode-mikro, yang tertanam dalam perangkat keras dan yang kebanyakan programmer bahkan tidak menggunakan secara langsung, atau memperbarui. Faktanya, tidak hanya sebagian besar programmer tidak menyentuh kode mikro (0 level lebih tinggi dari kode mikro), kebanyakan programmer tidak menyentuh kode mesin (1 level lebih tinggi dari kode mikro), atau bahkan Majelis (2 level lebih tinggi dari kode mikro) ( kecuali, mungkin, untuk sedikit pelatihan formal selama kuliah). Sebagian besar programmer akan menghabiskan waktu hanya 3 level atau lebih tinggi.

Lebih jauh, jika kita melihat Majelis (yang serendah orang biasanya dapatkan), setiap langkah individu biasanya dapat dimengerti oleh orang-orang yang telah dilatih dan memiliki sumber daya untuk menafsirkan langkah itu. Dalam hal ini, Assembly jauh lebih sederhana daripada bahasa tingkat yang lebih tinggi. Namun, Majelis sangat sederhana sehingga melakukan tugas-tugas kompleks, atau bahkan tugas-tugas biasa-biasa saja, sangat membosankan. Bahasa tingkat atas membebaskan kita dari hal itu.

Dalam undang-undang tentang "rekayasa terbalik", hakim menyatakan bahwa meskipun kode secara teoritis dapat ditangani satu byte pada satu waktu, program modern melibatkan jutaan byte, sehingga beberapa jenis catatan (seperti salinan kode) harus dibuat hanya untuk upaya untuk menjadi layak. (Oleh karena itu pengembangan internal tidak dianggap sebagai pelanggaran terhadap aturan umum tentang hukum hak cipta "tidak ada salinan).) (Saya mungkin berpikir untuk membuat kartrid Sega Genesis yang tidak sah, tetapi mungkin memikirkan sesuatu yang dikatakan selama kasus Game Genie. )

Modernisasi:

Apakah Anda menjalankan kode yang dimaksudkan untuk 286s? Atau apakah Anda menjalankan kode 64-bit?

Matematika menggunakan dasar-dasar yang membentang selama ribuan tahun. Dengan komputer, orang biasanya menganggap investasi pada sesuatu yang berusia dua dekade sebagai pemborosan sumber daya yang sia-sia. Itu berarti Matematika dapat diuji jauh lebih menyeluruh.

Standar Alat Bekas:

Saya diajari (oleh seorang teman yang memiliki lebih banyak pelatihan pemrograman komputer formal daripada saya sendiri) bahwa tidak ada yang namanya kompiler C bebas bug yang memenuhi spesifikasi C. Ini karena bahasa C pada dasarnya mengasumsikan kemungkinan menggunakan memori tak terbatas untuk tujuan stack. Jelas, persyaratan yang tidak mungkin seperti itu harus disimpang dari ketika orang mencoba untuk membuat kompiler yang dapat digunakan yang bekerja dengan mesin yang sebenarnya yang sedikit lebih terbatas di alam.

Dalam prakteknya, saya telah menemukan bahwa dengan JScript di Windows Script Host, saya sudah dapat mencapai banyak objek menggunakan baik. (Saya suka lingkungan karena set alat yang diperlukan untuk mencoba kode baru dibangun ke dalam versi modern dari Microsoft Windows.) Ketika menggunakan lingkungan ini, saya menemukan bahwa kadang-kadang tidak ada dokumentasi yang mudah ditemukan tentang bagaimana objek bekerja. Namun, menggunakan objek itu sangat bermanfaat, toh saya tetap melakukannya. Jadi yang akan saya lakukan adalah menulis kode, yang mungkin buggy sebagai sarang lebah, dan melakukannya di lingkungan berpasir yang bagus di mana saya bisa melihat efeknya, dan belajar tentang perilaku objek saat berinteraksi dengannya.

Dalam kasus lain, kadang-kadang hanya setelah saya mengetahui bagaimana suatu objek berperilaku, saya telah menemukan bahwa objek (yang dibundel dengan sistem operasi) adalah buggy, dan itu adalah masalah yang diketahui yang sengaja diputuskan oleh Microsoft tidak akan diperbaiki .

Dalam skenario seperti itu, apakah saya mengandalkan OpenBSD, yang dibuat oleh programmer ahli yang membuat rilis baru sesuai jadwal, secara teratur (dua kali setahun), dengan catatan keamanan terkenal "hanya dua lubang jarak jauh" dalam 10+ tahun? (Bahkan mereka memiliki patch errata untuk masalah yang kurang parah.) Tidak, tidak berarti. Saya tidak bergantung pada produk seperti itu dengan kualitas yang lebih tinggi, karena saya bekerja untuk bisnis yang mendukung bisnis yang memasok orang dengan mesin yang menggunakan Microsoft Windows, jadi itulah yang perlu dikerjakan oleh kode saya.

Kepraktisan / kegunaan mengharuskan saya bekerja pada platform yang bermanfaat bagi orang, dan itu adalah platform yang terkenal buruk untuk keamanan (meskipun perbaikan luar biasa telah dilakukan sejak awal milenium di mana produk perusahaan yang sama jauh lebih buruk) .

Ringkasan

Ada banyak alasan mengapa pemrograman komputer lebih rentan kesalahan, dan itu diterima oleh komunitas pengguna komputer. Bahkan, sebagian besar kode ditulis dalam lingkungan yang tidak akan mentolerir upaya bebas kesalahan. (Beberapa pengecualian, seperti mengembangkan protokol keamanan, mungkin menerima upaya sedikit lebih dalam hal ini.) Selain pemikiran umum tentang alasan bisnis tidak ingin menginvestasikan lebih banyak uang, dan kehilangan tenggat waktu buatan untuk membuat pelanggan bahagia, ada dampak dari pawai teknologi yang hanya menyatakan bahwa jika Anda menghabiskan terlalu banyak waktu, Anda akan bekerja pada platform yang usang karena banyak hal berubah secara signifikan dalam satu dekade.

Begitu saja, saya ingat betapa terkejutnya betapa singkatnya beberapa fungsi yang sangat berguna dan populer, ketika saya melihat beberapa kode sumber untuk strlen dan strcpy. Sebagai contoh, strlen mungkin sesuatu seperti "int strlen (char * x) {char y = x; while ( (y ++)); return (yx) -1;}"

Namun, program komputer pada umumnya jauh lebih panjang dari itu. Juga, banyak pemrograman modern akan menggunakan kode lain yang mungkin kurang diuji secara menyeluruh, atau bahkan diketahui buggy. Sistem saat ini jauh lebih rumit daripada apa yang dapat dengan mudah dipikirkan, kecuali dengan tangan melambaikan banyak hal kecil sebagai "perincian yang ditangani oleh tingkat yang lebih rendah".

Kompleksitas wajib ini, dan kepastian bekerja dengan sistem yang kompleks dan bahkan salah, membuat pemrograman komputer banyak perangkat keras untuk diverifikasi daripada banyak matematika di mana hal-hal cenderung mendidih ke tingkat yang jauh lebih sederhana.

Ketika Anda memecah hal-hal dalam matematika, Anda mendapatkan potongan-potongan individual yang anak-anak dapat mengerti. Kebanyakan orang mempercayai matematika; setidaknya aritmatika dasar (atau, setidaknya, penghitungan).

Ketika Anda benar-benar memecah pemrograman komputer untuk melihat apa yang terjadi di bawah tenda, Anda berakhir dengan implementasi yang rusak dari standar dan kode yang rusak yang pada akhirnya dieksekusi secara elektronik, dan bahwa implementasi fisik hanya satu langkah di bawah mikrokode yang kebanyakan ilmuwan komputer yang dilatih universitas tidak tidak berani menyentuh (jika mereka menyadarinya).

Saya sudah bicara dengan beberapa programmer yang masih kuliah atau lulusan baru yang langsung keberatan dengan anggapan bahwa kode bebas bug dapat ditulis. Mereka telah menghapus kemungkinan itu, dan meskipun mereka mengakui bahwa beberapa contoh yang mengesankan (yang saya dapat tunjukkan) adalah beberapa argumen yang meyakinkan, mereka menganggap sampel seperti itu sebagai cacing langka yang tidak representatif, dan masih menolak kemungkinan untuk dapat menghitung memiliki standar yang lebih tinggi. (Sikap yang jauh, jauh berbeda dari fondasi yang jauh lebih dapat dipercaya yang kita lihat dalam matematika.)


1
Sementara Anda membuat kasus yang bagus untuk kompleksitas pemrograman, Anda hampir tidak mempertimbangkan matematika sama sekali! Bahkan, Anda tampaknya meremehkan kompleksitas yang terlibat dalam matematika formal: "Ketika Anda memecah hal-hal dalam matematika, Anda mendapatkan potongan-potongan individual yang anak-anak dapat mengerti", benarkah ? Selain itu, hal yang sama dapat dikatakan tentang pemrograman 'tingkat tinggi' yang memadai (mis. Scratch dirancang untuk anak-anak). Juga perhatikan bahwa Meskipun C-spec lengkap tidak dapat diterapkan, kompiler yang mendukung subset penting telah ditunjukkan secara formal benar menggunakan bukti yang dibantu komputer.
Kadal diskrit

2+3=5

Meta note: jika Anda ahli dalam satu hal dan pemula yang ahli (atau lebih rendah) dalam hal lain, Anda berada dalam posisi terburuk untuk membandingkan keduanya.
Raphael

Kadal diskrit - ini adalah Ilmu Komputer SE. Selain itu, setelah benar-benar membaca jawaban lain sebelum saya memposting, saya merasa mereka menyentuh lebih dari matematika daripada komputer. Saya merasa jawaban saya lebih baik dengan tidak membuatnya lebih lama hanya dengan menambahkan kata-kata yang sebagian besar akan berlebihan dengan apa yang ditulis di tempat lain. /// Adapun Scratch, level tinggi lebih kompleks, tidak lebih sederhana (ketika melihat perspektif sepenuhnya memahami semua bagian yang bergerak). Dengan perspektif ini, dari mana saya menulis, Assembly lebih sederhana daripada Scratch di atas lapisan lain (dengan gerbang NAND elektronik lebih sederhana lagi)
TOOGAM

0

Bukti matematika menggambarkan "apa" pengetahuan dan program menggambarkan "bagaimana" pengetahuan ".

Menulis program lebih kompleks karena programmer harus mempertimbangkan semua keadaan berbeda yang dapat muncul, dan bagaimana perilaku program berubah sebagai hasilnya. Bukti menggunakan penalaran formulaik atau kategoris untuk membuktikan hal-hal tentang definisi lain.

Sebagian besar bug disebabkan oleh proses masuk ke negara-negara yang tidak diantisipasi oleh programmer. Dalam sebuah program Anda biasanya memiliki ribuan atau, dalam sistem besar, jutaan variabel yang mungkin bukan data statis, tetapi sebenarnya mengubah cara program dijalankan. Semua interaksi ini menciptakan perilaku yang tidak mungkin diantisipasi, terutama di komputer modern di mana ada lapisan abstraksi yang berubah di bawah Anda.

Dalam buktinya, tidak ada perubahan kondisi. Definisi dan objek diskusi telah diperbaiki. Membuktikan memang membutuhkan pemikiran tentang masalah secara umum dan mempertimbangkan banyak kasus, tetapi kasus-kasus itu diperbaiki oleh definisi.


2
Saya akan mengatakan bahwa bukti matematis sepenuhnya mampu menggambarkan pengetahuan 'apa': ambil misalnya bukti apa pun yang membangun contoh untuk membuktikan keberadaan atau metode untuk menghitung nilai. Namun, saya setuju bahwa negara adalah sesuatu yang tidak ada dalam bukti, dalam arti tidak ada keadaan selain yang secara eksplisit dijelaskan oleh penulis (atau pembaca!). Keadaan inilah yang memungkinkan suatu program melakukan sesuatu yang tidak disadari oleh pembaca / penulis, sementara hal ini mustahil dilakukan sebagai bukti. (tentu saja, bukti dapat memiliki fitur atau hasil yang tidak diinginkan, tetapi masih ada beberapa pemikiran aktif yang diperlukan untuk mendapatkannya)
Kadal diskrit

@Discretelizard Ini adalah komentar yang membantu. Saya pikir garis antara "apa" dan "bagaimana" jelas kabur. Membuktikan suatu algoritma melakukan apa yang Anda pikirkan, benar-benar tidak menggambarkan "bagaimana" dalam pikiran saya, itu hanya menjamin sifat-sifat tertentu berlaku. Dari sudut pandang filosofis, saya pikir "bagaimana caranya" pengetahuan membutuhkan korespondensi dengan dunia. Program selalu melakukan apa yang Anda katakan. Ketika Anda memiliki bug, apa yang Anda suruh tidak sesuai dengan dunia (apa yang Anda modelkan). Matematika, terlepas dari suatu aplikasi (seperti masalah fisika) tampaknya semuanya tergantung pada koherensi.
Justin Meiners
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.