ฉันสังเกตว่าฉันพบว่ามันง่ายกว่ามากในการเขียนหลักฐานทางคณิตศาสตร์โดยไม่ทำผิดพลาดไปกว่าเขียนโปรแกรมคอมพิวเตอร์ที่ไม่มีข้อบกพร่อง

ดูเหมือนว่านี่เป็นสิ่งที่แพร่หลายมากกว่าเพียงแค่ประสบการณ์ของฉัน คนส่วนใหญ่ทำข้อบกพร่องซอฟต์แวร์ตลอดเวลาในการเขียนโปรแกรมและพวกเขามีคอมไพเลอร์เพื่อบอกพวกเขาว่าสิ่งที่ผิดพลาดอยู่ตลอดเวลา ฉันไม่เคยได้ยินใครบางคนที่เขียนโปรแกรมคอมพิวเตอร์ขนาดใหญ่โดยไม่มีข้อผิดพลาดในครั้งเดียวและมีความมั่นใจเต็มที่ว่าจะไม่มีข้อผิดพลาด (อันที่จริงโปรแกรมแทบจะไม่มีข้อบกพร่องแม้แต่โปรแกรมที่ดีบั๊กมาก ๆ )

แต่ผู้คนสามารถเขียนบทความหรือหนังสือทั้งหมดที่มีข้อพิสูจน์ทางคณิตศาสตร์โดยไม่ต้องมีคอมไพเลอร์ใด ๆ ให้คำติชมว่าพวกเขาทำผิดพลาด

ให้ฉันมีความชัดเจน นี่ไม่ใช่การบอกว่าคนไม่ทำผิดพลาดในการพิสูจน์ทางคณิตศาสตร์ แต่สำหรับนักคณิตศาสตร์ที่มีประสบการณ์เพียงเล็กน้อยความผิดพลาดมักจะไม่ใช่ปัญหานั้นและสามารถแก้ไขได้โดยไม่ต้องใช้ "oracle ภายนอก" เช่นคอมไพเลอร์ชี้ไปที่ ผิดพลาด

อันที่จริงถ้าไม่ใช่อย่างนั้นคณิตศาสตร์ก็แทบจะเป็นไปได้

ดังนั้นสิ่งนี้ทำให้ฉันถามคำถาม: อะไรคือความแตกต่างเกี่ยวกับการเขียนหลักฐานทางคณิตศาสตร์ที่ไม่ผิดพลาดและการเขียนรหัสคอมพิวเตอร์ที่ผิดพลาดที่ทำให้มันเป็นแบบนั้นเพื่อให้อดีตเป็นเวไนยมากขึ้นกว่าหลัง?

อาจกล่าวได้ว่ามันเป็นความจริงที่ว่าผู้คนมี "oracle ภายนอก" ของคอมไพเลอร์ชี้ให้พวกเขาเห็นความผิดพลาดที่ทำให้โปรแกรมเมอร์ขี้เกียจป้องกันไม่ให้พวกเขาทำสิ่งที่จำเป็นในการเขียนโค้ดอย่างจริงจัง มุมมองนี้จะหมายความว่าหากพวกเขาไม่มีคอมไพเลอร์พวกเขาจะสามารถเป็นนักคณิตศาสตร์ได้อย่างไร้ข้อผิดพลาด

คุณอาจพบว่าการโน้มน้าวใจนี้ แต่จากประสบการณ์การเขียนโปรแกรมและการเขียนหลักฐานทางคณิตศาสตร์ดูเหมือนว่าโดยสัญชาตญาณสำหรับฉันว่านี่ไม่ใช่คำอธิบาย ดูเหมือนว่ามีบางสิ่งที่แตกต่างกันโดยพื้นฐานเกี่ยวกับความพยายามทั้งสอง

ความคิดเริ่มต้นของฉันคือสิ่งที่อาจเป็นความแตกต่างคือสำหรับนักคณิตศาสตร์การพิสูจน์ที่ถูกต้องจะต้องใช้ทุกขั้นตอนตรรกะในการแก้ไขเท่านั้น หากทุกขั้นตอนถูกต้องหลักฐานทั้งหมดจะถูกต้อง ในทางตรงกันข้ามสำหรับโปรแกรมที่จะไม่มีข้อบกพร่องไม่เพียง แต่ทุกบรรทัดของรหัสจะต้องถูกต้อง แต่มันเกี่ยวข้องกับทุกบรรทัดของรหัสในโปรแกรมจะต้องทำงานเช่นกัน

ในคำอื่น ๆ ถ้าขั้นตอนในหลักฐานถูกต้องจากนั้นทำผิดพลาดในขั้นตอนจะไม่เลอะขั้นตอนเคย แต่ถ้าบรรทัดของโค้ดถูกเขียนลงอย่างถูกต้องแล้วการทำผิดในบรรทัดจะมีผลต่อการทำงานของบรรทัดดังนั้นเมื่อใดก็ตามที่เราเขียน lineเราต้องคำนึงถึงความสัมพันธ์กับบรรทัดอื่นทั้งหมด เราสามารถใช้การห่อหุ้มและสิ่งเหล่านั้นเพื่อ จำกัด สิ่งนี้ แต่มันไม่สามารถลบออกได้อย่างสมบูรณ์Y X X Y X $X$$Y$$X$$X$$Y$$X$$X$

ซึ่งหมายความว่ากระบวนการสำหรับการตรวจสอบข้อผิดพลาดในการพิสูจน์ทางคณิตศาสตร์นั้นเป็นเชิงเส้นในจำนวนขั้นตอนการพิสูจน์ แต่กระบวนการสำหรับการตรวจสอบข้อผิดพลาดในรหัสคอมพิวเตอร์นั้นเป็นเลขชี้กำลังเชิงเส้นในจำนวนบรรทัดของรหัส

คุณคิดอย่างไร?

หมายเหตุ: คำถามนี้มีคำตอบจำนวนมากที่สำรวจข้อเท็จจริงและมุมมองที่หลากหลาย ก่อนที่คุณจะตอบโปรดอ่านทั้งหมดและตอบเฉพาะเมื่อคุณมีสิ่งใหม่ที่จะเพิ่ม คำตอบที่ซ้ำซ้อนหรือคำตอบที่ไม่ได้สำรองความคิดเห็นด้วยข้อเท็จจริงอาจถูกลบ

ฉันขอเสนอเหตุผลหนึ่งข้อและความเข้าใจผิดอย่างหนึ่งเพื่อตอบคำถามของคุณ

เหตุผลหลักที่ว่ามันเป็นเรื่องง่ายที่จะเขียน (ที่ดูเหมือน) พิสูจน์ทางคณิตศาสตร์ที่ถูกต้องคือการที่พวกเขาจะเขียนในระดับที่สูงมาก สมมติว่าคุณสามารถเขียนโปรแกรมเช่นนี้:

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)

มันจะยากกว่าที่จะผิดพลาดเมื่อทำการเขียนโปรแกรมด้วยวิธีนี้เนื่องจากข้อกำหนดของโปรแกรมนั้นสั้นกว่าการใช้งานมาก แท้จริงโปรแกรมเมอร์ที่พยายามที่จะแปลง pseudocode รหัสโดยเฉพาะอย่างยิ่งในรหัสที่มีประสิทธิภาพทุกพบนี้ช่องว่างขนาดใหญ่ระหว่างความคิดของอัลกอริทึมและรายละเอียดการดำเนินงาน หลักฐานทางคณิตศาสตร์เน้นที่ความคิดและรายละเอียดน้อยลง

คู่ที่แท้จริงของสำหรับการพิสูจน์ทางคณิตศาสตร์เป็นคอมพิวเตอร์ช่วยพิสูจน์ สิ่งเหล่านี้พัฒนาได้ยากกว่าการพิสูจน์แบบข้อความปกติและเรามักจะค้นพบมุมที่ซ่อนอยู่หลากหลายซึ่งเป็น "ชัดเจน" ต่อผู้อ่าน นอกจากนี้เนื่องจากคอมพิวเตอร์สามารถเติมเต็มช่องว่างที่ค่อนข้างเล็กในปัจจุบันหลักฐานต้องได้รับการอธิบายอย่างละเอียดถึงระดับที่มนุษย์อ่านพวกเขาจะพลาดป่าสำหรับต้นไม้

ความเข้าใจผิดที่สำคัญคือการพิสูจน์ทางคณิตศาสตร์มักจะถูกต้อง ในความเป็นจริงนี่อาจเป็นแง่ดี มันยากมากที่จะเขียนบทพิสูจน์ที่ซับซ้อนโดยไม่มีข้อผิดพลาดและเอกสารมักจะมีข้อผิดพลาด บางทีอาจจะเป็นกรณีล่าสุดที่มีชื่อเสียงโด่งดังมากที่สุดคือความพยายามไต๋ครั้งแรกที่ (เป็นกรณีพิเศษของ) ทฤษฎีบทต้นแบบ (ซึ่งหมายถึงทฤษฎีบทสุดท้ายของแฟร์มาต์) และช่องว่างต่าง ๆ ในการจำแนกกลุ่มง่ายๆแน่นอนรวมทั้งบาง 1000 + หน้าเว็บในกลุ่ม quasithinซึ่งเป็น เขียน 20 ปีหลังจากการจำแนกเสร็จสิ้นแล้ว

ผิดพลาดในกระดาษ Voevodskyทำให้เขาไม่ต้องสงสัยพิสูจน์มากที่เขาเริ่มพัฒนาเขียนประเภททฤษฎี homotopyกรอบตรรกะที่มีประโยชน์สำหรับการพัฒนาทฤษฎี homotopy อย่างเป็นทางการและต่อจากนี้ไปใช้คอมพิวเตอร์ในการตรวจสอบทุกการทำงานต่อมา (อย่างน้อยตามที่ตัวเขาเอง ค่าเข้าชม) แม้ว่านี่จะเป็นตำแหน่งที่รุนแรง (และในปัจจุบันไม่สามารถใช้งานได้) แต่ก็ยังเป็นกรณีที่เมื่อใช้ผลลัพธ์เราควรจะไปพิสูจน์และตรวจสอบว่ามันถูกต้องหรือไม่ ในพื้นที่ของฉันมีเอกสารสองสามฉบับที่ทราบกันว่าผิด แต่ไม่เคยหดกลับคืนซึ่งสถานะถูกถ่ายทอดจากปากหนึ่งถึงหูท่ามกลางผู้เชี่ยวชาญ

(ฉันอาจเสี่ยง downvotes ไม่กี่ที่นี่เนื่องจากฉันไม่มีเวลา / สนใจที่จะทำให้คำตอบที่ถูกต้อง แต่ฉันพบข้อความที่ยกมา (และส่วนที่เหลือของบทความที่อ้างถึง) ด้านล่างจะค่อนข้างฉลาดและพิจารณาพวกเขาเขียน โดยนักคณิตศาสตร์ที่มีชื่อเสียงบางทีฉันอาจปรับปรุงคำตอบได้ในภายหลัง)

ความคิดที่ฉันคิดว่าไม่แตกต่างจากคำตอบที่มีอยู่โดยเฉพาะคือ "การพิสูจน์" หรือการโต้เถียงสื่อสารกับชุมชนทางคณิตศาสตร์โดยมีจุดประสงค์เพื่อโน้มน้าวพวกเขาว่ารายละเอียด (น่าเบื่อ) สามารถเติมเต็มในหลักการ เพื่อให้ได้การพิสูจน์อย่างเป็นทางการที่ระบุอย่างสมบูรณ์ - โดยไม่ต้องทำเช่นนั้นเลย อินสแตนซ์ที่สำคัญอย่างหนึ่งของเรื่องนี้คือคุณสามารถใช้ทฤษฎีบทที่มีอยู่โดยระบุพวกเขา แต่การใช้โค้ดซ้ำนั้นมีความท้าทายโดยทั่วไป พิจารณา "บั๊ก" เล็กน้อยซึ่งอาจทำให้โค้ดไม่มีประโยชน์ (เช่น SEGFAULTs) แต่อาจปล่อยให้อาร์กิวเมนต์ทางคณิตศาสตร์ส่วนใหญ่ไม่บุบสลาย (นั่นคือถ้าข้อผิดพลาดสามารถอยู่ได้โดยไม่มีการยุบอาร์กิวเมนต์)

มาตรฐานความถูกต้องและครบถ้วนที่จำเป็นในการทำให้โปรแกรมคอมพิวเตอร์ทำงานได้ทั้งหมดนั้นเป็นคำสั่งที่มีขนาดสูงกว่ามาตรฐานการพิสูจน์ที่ถูกต้องของชุมชนคณิตศาสตร์ อย่างไรก็ตามโปรแกรมคอมพิวเตอร์ขนาดใหญ่แม้ว่าพวกเขาจะได้รับการเขียนอย่างระมัดระวังและผ่านการทดสอบอย่างระมัดระวังดูเหมือนว่าจะมีข้อบกพร่องอยู่เสมอ [... ] คณิตศาสตร์ในขณะที่เราฝึกมันมีความสมบูรณ์และแม่นยำมากกว่าวิทยาศาสตร์อื่น ๆ อย่างเป็นทางการ แต่มันมีความสมบูรณ์และแม่นยำน้อยกว่าสำหรับโปรแกรมเนื้อหามากกว่าโปรแกรมคอมพิวเตอร์ ความแตกต่างไม่เพียงแค่มีจำนวนของความพยายาม: ชนิดของความพยายามที่แตกต่างกันในเชิงคุณภาพ ในโปรแกรมคอมพิวเตอร์ขนาดใหญ่ต้องใช้ความพยายามอย่างมากในการแก้ปัญหาความเข้ากันได้มากมาย: ตรวจสอบให้แน่ใจว่าคำจำกัดความทั้งหมดสอดคล้องกันพัฒนา "ดี" โครงสร้างข้อมูลที่มีประโยชน์ แต่ไม่ยุ่งยากทั่วไปการตัดสินใจเลือก "ถูกต้อง" สำหรับฟังก์ชั่น ฯลฯ สัดส่วนของพลังงานที่ใช้ในส่วนการทำงานของโปรแกรมขนาดใหญ่ซึ่งแตกต่างจากส่วนทำบัญชีมีขนาดเล็กอย่างน่าประหลาดใจ เนื่องจากปัญหาความเข้ากันได้ที่แทบจะเพิ่มขึ้นอย่างหลีกเลี่ยงไม่ได้เนื่องจากคำจำกัดความ "ถูกต้อง" เปลี่ยนไปตามความนิยมและการใช้งานที่เพิ่มเข้ามาโปรแกรมคอมพิวเตอร์จึงจำเป็นต้องเขียนใหม่บ่อยครั้งตั้งแต่เริ่มต้น

เรื่องการพิสูจน์และความก้าวหน้าในวิชาคณิตศาสตร์ (หน้า 9-10) โดย WILLIAM P. THURSTON https://arxiv.org/pdf/math/9404236.pdf

ให้ฉันเริ่มด้วยการอ้างถึง EW Dijkstra:

"การเขียนโปรแกรมเป็นหนึ่งในสาขาคณิตศาสตร์ประยุกต์ที่ยากที่สุด แต่นักคณิตศาสตร์ที่ด้อยกว่าก็ยังคงเป็นนักคณิตศาสตร์ที่บริสุทธิ์ได้ดีกว่า" (จาก EWD498)

แม้ว่าสิ่งที่ Dijkstra มีความหมายกับ `การเขียนโปรแกรม 'นั้นแตกต่างกันเล็กน้อยจากการใช้งานในปัจจุบัน แต่ก็ยังมีข้อดีอยู่บ้างในเครื่องหมายคำพูดนี้ คำตอบอื่น ๆ ได้กล่าวแล้วว่าระดับของนามธรรมในคณิตศาสตร์ได้รับอนุญาตให้สูงกว่ามากในการเขียนโปรแกรมซึ่งหมายความว่าเราสามารถละเว้นส่วนที่ยุ่งยากหากเราต้องการทำเช่นนั้น

แต่ผมเชื่อว่านี่เป็นเพียงเป็นผลมาจากความแตกต่างพื้นฐานระหว่างหลักฐานและโปรแกรมคอมพิวเตอร์ของพวกเขาซึ่งเป็นวัตถุประสงค์

วัตถุประสงค์หลักของการพิสูจน์ทางคณิตศาสตร์เป็นหมู่คนที่จะโน้มน้าวตัวเองว่าการเรียกร้องทางคณิตศาสตร์ที่ถูกต้องและอาจจะยิ่งมีความสำคัญมากขึ้นเพื่อให้บรรลุความเข้าใจ ดังนั้นคุณอาจเลือกที่จะทำงานเฉพาะในโลกคณิตศาสตร์ที่ทุกอย่างถูกสร้างขึ้นเช่นความเข้าใจที่สามารถเข้าถึงได้โดยการออกแบบ (แม้ว่านักเรียนบางคนขอแตกต่าง ... ) นี่คือสิ่งที่ Dijkstra มีความหมายกับ "นักคณิตศาสตร์บริสุทธิ์" ผู้ที่ (เกือบ) เกี่ยวข้องกับข้อเท็จจริงทางคณิตศาสตร์และเข้าใจคุณสมบัติของตนเองเท่านั้น

ดังนั้นคุณไม่ควรแปลกใจที่การสร้างหลักฐานที่ถูกต้องนั้นค่อนข้างจะเป็นการพิสูจน์ข้อผิดพลาด: มันเป็นประเด็นของ "การออกกำลังกาย" ทั้งหมด (ถึงกระนั้นก็ไม่ได้หมายความว่าความผิดพลาดจะไม่มีหรือมีอยู่จริงที่จะทำผิดก็แค่มนุษย์เท่านั้นที่พวกเขาพูด)

ตอนนี้ถ้าเราพิจารณาการเขียนโปรแกรมวัตถุประสงค์ของเราคืออะไร? เราไม่ได้แสวงหาความเข้าใจจริง ๆ เราต้องการบางสิ่งที่ใช้งานได้ แต่เมื่อไหร่ที่ "ทำงาน" บางสิ่งบางอย่างทำงานได้เมื่อเราสร้างบางสิ่งบางอย่างที่ทำให้เครื่องแปลก ๆ ทำงานให้เสร็จตามที่เราต้องการและรวดเร็วกว่าเช่นกัน

นี่คือฉันเชื่อว่าความแตกต่างขั้นพื้นฐานซึ่งหมายความว่าเป้าหมายของเราไม่สามารถกล่าวได้อย่างง่ายๆว่าทฤษฎีบทบางอย่างที่โปรแกรมของเรา "พิสูจน์" เราต้องการสิ่งที่อยู่ในโลกแห่งความจริง (ไม่ว่าจะเป็นอะไร) ไม่ใช่สิ่งประดิษฐ์ทางคณิตศาสตร์ ซึ่งหมายความว่าเราไม่สามารถบรรลุเป้าหมายตามหลักทฤษฏีได้อย่างแท้จริง (แม้ว่า Dijkstra จะให้คุณลองโดยไม่คำนึงถึงเรื่อง) ในขณะที่เราต้องเอาใจช่วยเครื่องหวังว่าเราจะรู้ว่างานที่เราต้องการทำและตระหนักถึงสิ่งที่ไม่ได้พิจารณา อย่างใด

ดังนั้นในที่สุดไม่มีทางอื่นนอกจากจะลองและอาจล้มเหลวแก้ไขล้มเหลวและลองอีกครั้งจนกว่าเราจะพอใจกับผลลัพธ์

โปรดสังเกตว่าสมมุติฐานของคุณที่เขียนข้อพิสูจน์ความผิดน้อยกว่านั้นง่ายกว่าโปรแกรมที่ไม่มีข้อผิดพลาด (ซึ่งอันที่จริงแล้วข้อความที่แตกต่างกันตามที่@Arielชี้ให้เห็น) อาจเป็นความจริงผิด ถึงกระนั้นฉันหวังว่าสิ่งนี้จะให้ความกระจ่างแก่คำถามที่บอกเป็นนัย: "อะไรคือความแตกต่างระหว่างการพิสูจน์ทฤษฎีบทและการเขียนโปรแกรม" (ซึ่งผู้สังเกตการณ์อย่างประมาทของจดหมายโต้ตอบแกง - โฮเวิร์ดอาจพูดว่า: "ไม่มีอะไรเลย!")

ดังที่ @wvxvw พูดถึงในความคิดเห็นย่อหน้าต่อไปนี้จาก 'หมายเหตุในการเขียนโปรแกรมเชิงโครงสร้าง' (EWD249, หน้า 21) มีความเกี่ยวข้องมาก:

(... ) โปรแกรมไม่เคยมีเป้าหมายในตัวเอง จุดประสงค์ของโปรแกรมคือการทำให้เกิดการคำนวณและจุดประสงค์ของการคำนวณก็เพื่อสร้างผลที่ต้องการ แม้ว่าโปรแกรมจะเป็นผลิตภัณฑ์ขั้นสุดท้ายที่ทำโดยโปรแกรมเมอร์ แต่การคำนวณที่เป็นไปได้ก็ปรากฏขึ้นโดย "ทำ" ซึ่งเหลืออยู่ที่เครื่อง! - เป็นเรื่องจริงของการค้าขายของเขา ตัวอย่างเช่นเมื่อใดก็ตามที่ผู้เขียนโปรแกรมระบุว่าโปรแกรมของเขาถูกต้องจริง ๆ แล้วเขายืนยันกับการคำนวณที่อาจทำให้เกิดขึ้นจริง ๆ

(... ) ในแง่หนึ่งการสร้างโปรแกรมจึงยากกว่าการสร้างทฤษฎีทางคณิตศาสตร์: ทั้งโปรแกรมและทฤษฎีมีโครงสร้างวัตถุที่ไม่มีเวลา แต่ในขณะที่ทฤษฎีทางคณิตศาสตร์มีเหตุผลตามที่ได้ตั้งไว้โปรแกรมก็ใช้ความรู้สึกเท่านั้นผ่านการดำเนินการ

แลมพอร์ตจัดเตรียมพื้นฐานสำหรับการไม่เห็นด้วยกับความชุกของข้อผิดพลาดในการพิสูจน์ในวิธีการเขียนหลักฐาน (หน้า 8-9) :

เมื่อยี่สิบปีที่แล้วฉันตัดสินใจที่จะเขียนบทพิสูจน์ทฤษฎีบทชโรเดอร์เบิร์นสไตน์สำหรับชั้นเรียนคณิตศาสตร์เบื้องต้น หลักฐานที่ง่ายที่สุดที่ฉันสามารถหาได้คือในข้อความโทโพโลยีทั่วไปของคลาสสิก ตั้งแต่ตวัดเขียนให้กับผู้ชมที่มีความซับซ้อนมากขึ้นฉันจึงต้องเพิ่มคำอธิบายลงในหลักฐานครึ่งหน้าของเขา ฉันเขียนห้าหน้าเมื่อฉันรู้ว่าหลักฐานของเคลลี่นั้นผิด เมื่อเร็ว ๆ นี้ฉันต้องการแสดงให้เห็นถึงการบรรยายเกี่ยวกับรูปแบบการพิสูจน์ของฉันด้วยการพิสูจน์ที่ไม่ถูกต้องที่น่าเชื่อถือดังนั้นฉันจึงหันไปหาเคลลี่ ฉันไม่พบสิ่งผิดปกติกับหลักฐานของเขา; เห็นได้ชัดว่ามันถูกต้อง! การอ่านและอ่านหลักฐานใหม่ทำให้ฉันเชื่อว่าความทรงจำของฉันไม่สำเร็จหรืออย่างอื่นฉันก็โง่มากเมื่อยี่สิบปีก่อน ถึงกระนั้นการพิสูจน์ของตวัดสั้นและจะเป็นตัวอย่างที่ดีดังนั้นฉันจึงเริ่มเขียนใหม่เป็นหลักฐานที่มีโครงสร้าง

... รูปแบบถูกนำไปใช้ครั้งแรกกับบทพิสูจน์ของทฤษฎีบทสามัญในกระดาษที่ฉันเขียนกับ Martin Abadi เขาได้เขียนบทพิสูจน์ตามธรรมเนียมมาแล้ว - บทพิสูจน์ที่ดีพอที่จะโน้มน้าวใจเราและผู้ตัดสิน การพิสูจน์หลักฐานในรูปแบบที่มีโครงสร้างเราค้นพบว่าเกือบทุกคนมีข้อผิดพลาดร้ายแรงแม้ว่าทฤษฎีบทจะถูกต้อง ความหวังใด ๆ ที่พิสูจน์ไม่ถูกต้องอาจไม่นำไปสู่ทฤษฎีบทที่ไม่ถูกต้องถูกทำลายในความร่วมมือครั้งต่อไปของเรา ครั้งแล้วครั้งเล่าเราจะทำการคาดเดาและเขียนภาพร่างหลักฐานบนกระดานดำ - ร่างที่สามารถกลายเป็นหลักฐานทั่วไปที่น่าเชื่อถือได้ง่ายเพียงค้นพบโดยพยายามเขียนหลักฐานที่มีโครงสร้างว่าการคาดเดานั้นเป็นเท็จ ตั้งแต่นั้นมาฉันไม่เคยเชื่อผลลัพธ์โดยปราศจากข้อพิสูจน์ที่มีโครงสร้างและระมัดระวัง

ความแตกต่างที่สำคัญอย่างหนึ่งคือโดยทั่วไปโปรแกรมจะถูกเขียนขึ้นเพื่อใช้งานกับอินพุตในขณะที่การพิสูจน์ทางคณิตศาสตร์โดยทั่วไปเริ่มจากชุดของสัจพจน์และทฤษฎีบทที่รู้จักกันมาก่อน บางครั้งคุณต้องครอบคลุมหลายมุมของเคสเพื่อให้ได้การพิสูจน์ทั่วไปอย่างเพียงพอ แต่เคสและการแก้ปัญหาของพวกเขาถูกระบุอย่างชัดเจนและขอบเขตของผลลัพธ์นั้นถูก จำกัด โดยปริยายกับเคสที่ครอบคลุม

เปรียบเทียบสิ่งนี้กับโปรแกรมคอมพิวเตอร์ซึ่งจะต้องให้เอาต์พุต 'ถูกต้อง' สำหรับช่วงของอินพุตที่เป็นไปได้ เป็นไปไม่ได้ที่จะระบุอินพุตทั้งหมดและลองใช้ทั้งหมด ที่แย่ไปกว่านั้นสมมติว่าโปรแกรมมีปฏิสัมพันธ์กับมนุษย์และอนุญาตให้อินพุตของพวกเขาแก้ไขการทำงานได้หรือไม่ มนุษย์เป็นสิ่งที่ไม่อาจคาดเดาได้และมีจำนวนข้อมูลที่เป็นไปได้สำหรับโครงการขนาดใหญ่พอสมควรที่มีปฏิสัมพันธ์ระหว่างมนุษย์เพิ่มขึ้นในอัตราที่มหาศาล คุณต้องพยายามคาดการณ์ถึงวิธีการต่าง ๆ ทั้งหมดที่โปรแกรมอาจถูกใช้งานและพยายามทำให้กรณีการใช้งานทั้งหมดนั้นทำงานหรือล้มเหลวอย่างน้อยในวิธีที่สมเหตุสมผลเมื่อความล้มเหลวเป็นเพียงตัวเลือกเดียว และนั่นคือสมมุติว่าคุณรู้ด้วยซ้ำว่ามันควรจะทำงานอย่างไรในกรณีมุมที่คลุมเครือ

ในที่สุดโปรแกรมขนาดใหญ่นั้นไม่สามารถเปรียบเทียบได้กับการพิสูจน์เพียงอย่างเดียวแม้แต่แบบซับซ้อน โปรแกรมขนาดใหญ่อาจคล้ายกับการรวบรวมและตรวจสอบห้องสมุดวรรณกรรมขนาดเล็กซึ่งบางโปรแกรมอาจมีข้อผิดพลาดซึ่งคุณต้องแก้ไข สำหรับโปรแกรมเพิ่มเติมในระดับของการพิสูจน์เพียงครั้งเดียวซึ่งอาจเป็นการใช้งานอัลกอริธึมขนาดเล็กสมมติว่าวิศวกรซอฟต์แวร์ที่มีประสบการณ์สามารถ / ดำเนินการให้เสร็จโดยไม่ทำผิดพลาดโดยเฉพาะอย่างยิ่งเมื่อใช้เครื่องมือสมัยใหม่ที่ป้องกัน / แก้ไขข้อผิดพลาดทั่วไป ) ซึ่งเทียบเท่ากับปัญหาเริ่มแรกที่คุณต้องแก้ไขในการพิสูจน์อักษร

พวกเขากล่าวว่าปัญหาที่เกิดขึ้นกับคอมพิวเตอร์คือพวกเขาไม่ว่าสิ่งที่คุณบอกพวกเขา

ฉันคิดว่านี่อาจเป็นหนึ่งในหลาย ๆ เหตุผล

ขอให้สังเกตว่าด้วยโปรแกรมคอมพิวเตอร์ตัวเขียน (คุณ) นั้นฉลาด แต่ตัวอ่าน (CPU) นั้นเป็นใบ้
แต่ด้วยหลักฐานทางคณิตศาสตร์ผู้เขียน (คุณ) นั้นฉลาดและผู้อ่าน (ผู้ตรวจสอบ) ก็ฉลาดเช่นกัน

ซึ่งหมายความว่าคุณไม่สามารถที่จะเข้าสู่สถานการณ์ "ดีคุณรู้ว่าฉันหมายถึงอะไร " สถานการณ์ด้วยคอมพิวเตอร์ มันทำสิ่งที่คุณบอกโดยไม่ทราบเจตนาของคุณ

ตัวอย่างเช่นสมมติว่านี่เป็นขั้นตอนในการพิสูจน์บางอย่าง:

$x^2+4x+3$$x+3$$x = -3$

ประเด็นหนึ่งที่ฉันคิดว่าไม่ได้กล่าวถึงในคำตอบของ Yuval คือดูเหมือนว่าคุณกำลังเปรียบเทียบสัตว์ที่แตกต่างกัน

$n$$n!$

การตรวจสอบคุณสมบัติเชิงความหมายของโปรแกรมนั้นไม่สามารถระบุได้ (ทฤษฎีของข้าว) และแบบอะนาล็อกการตรวจสอบว่าคำสั่งตามลอจิกอันดับแรกนั้นเป็นจริงหรือไม่เช่นกัน ประเด็นก็คือไม่มีความแข็งแตกต่างอย่างแท้จริงจากวิธีที่คุณดูปัญหา ในทางกลับกันเราสามารถให้เหตุผลเกี่ยวกับคุณสมบัติทางวากยสัมพันธ์ของโปรแกรม (คอมไพเลอร์) และนี่ก็คล้ายคลึงกับความจริงที่ว่าเราสามารถตรวจสอบหลักฐานได้ Bugs (โค้ดไม่ได้ทำในสิ่งที่ฉันต้องการ) มีความหมายดังนั้นคุณควรเปรียบเทียบมันกับคู่ที่ถูกต้อง

ฉันจะทำให้ยูวาลเข้มแข็งขึ้นและกล่าวว่าสาขาทั้งหมดเติบโตขึ้นด้วยแรงจูงใจในการเขียนหลักฐานทางคณิตศาสตร์ที่สามารถเขียนและตรวจสอบในระบบที่เป็นทางการดังนั้นแม้กระบวนการตรวจสอบจะไม่สำคัญเลย

อะไรคือความแตกต่างเกี่ยวกับการเขียนหลักฐานทางคณิตศาสตร์ที่ไม่ผิดพลาดและการเขียนรหัสคอมพิวเตอร์ที่ไม่ผิดพลาดที่ทำให้มันเป็นแบบนั้นเพื่อให้อดีตเป็นเวกัสที่ดีกว่าสมัยก่อน?

ผมเชื่อว่าเหตุผลหลักที่มีIdempotency (ให้ผลเช่นเดียวกันสำหรับปัจจัยการผลิตเดียวกัน) และเปลี่ยนไม่ได้ (ไม่เปลี่ยนแปลง)

จะเกิดอะไรขึ้นถ้าการพิสูจน์ทางคณิตศาสตร์สามารถให้ผลลัพธ์ที่แตกต่างกันถ้าอ่านในวันอังคารหรือเมื่อปีที่สูงถึง 2000 จากปี 1999 ถ้าส่วนหนึ่งของการพิสูจน์ทางคณิตศาสตร์คือย้อนกลับไปสองสามหน้าเขียนใหม่สองสามบรรทัดแล้วเริ่มใหม่อีกครั้งจากจุดนั้น

ฉันแน่ใจว่าการพิสูจน์ดังกล่าวน่าจะเป็นข้อบกพร่องเกือบเป็นส่วนปกติของรหัสคอมพิวเตอร์

ฉันเห็นปัจจัยรองอื่น ๆ เช่นกัน:

1. นักคณิตศาสตร์มักจะได้รับการศึกษามากขึ้นก่อนที่จะพยายามเขียนหลักฐานที่สำคัญ / เผยแพร่ 1/4 ของนักพัฒนามืออาชีพที่ชื่อตัวเองเริ่มเขียนโค้ดน้อยกว่า 6 ปีที่แล้ว (ดูSO survey 2017 ) แต่ฉันคิดว่านักคณิตศาสตร์ส่วนใหญ่มีการศึกษาคณิตศาสตร์มากกว่าทศวรรษอย่างเป็นทางการ
2. การพิสูจน์ทางคณิตศาสตร์นั้นแทบจะไม่ได้รับการตรวจสอบในระดับเดียวกับรหัสคอมพิวเตอร์ การพิมพ์ผิดเดียวสามารถ / จะทำลายโปรแกรม แต่การพิมพ์ผิดหลายครั้งอาจไม่เพียงพอที่จะทำลายคุณค่าของการพิสูจน์ (เพียงแค่การอ่าน)
3. รายละเอียดของมารและรหัสคอมพิวเตอร์ไม่สามารถข้ามรายละเอียดได้ พิสูจน์ได้ฟรีเพื่อข้ามขั้นตอนซึ่งถือว่าง่าย / ประจำ มีน้ำตาลซินแทกติกดี ๆ ที่มีให้บริการในภาษาสมัยใหม่ แต่มีการเข้ารหัสยากและมีข้อ จำกัด ในการเปรียบเทียบค่อนข้างมาก
4. คณิตศาสตร์มีอายุมากขึ้นและมีรากฐาน / แกนที่มั่นคงยิ่งขึ้น แน่นอนว่ามีสาขาย่อยใหม่และเป็นประกายในวิชาคณิตศาสตร์มากมาย แต่หลักการสำคัญส่วนใหญ่มีการใช้งานมานานหลายทศวรรษ สิ่งนี้นำไปสู่ความมั่นคง ในอีกด้านหนึ่งโปรแกรมเมอร์ยังไม่เห็นด้วยกับวิธีการเข้ารหัสพื้นฐาน (ถามเกี่ยวกับการพัฒนาแบบ Agile และอัตราการยอมรับ)

ฉันเห็นด้วยกับสิ่งที่ Yuval เขียน แต่ก็มีคำตอบที่ง่ายกว่านี้: ในทางปฏิบัติแล้ววิศวกรซอฟต์แวร์มักจะไม่ลองตรวจสอบความถูกต้องของโปรแกรมพวกเขาก็ทำไม่ได้พวกเขามักจะไม่เขียนเงื่อนไขที่กำหนดเมื่อโปรแกรมนั้นถูกต้อง

มีหลายสาเหตุด้วยกัน หนึ่งคือวิศวกรซอฟต์แวร์ส่วนใหญ่ไม่มีทักษะในการกำหนดปัญหาทางคณิตศาสตร์อย่างชัดเจนและพวกเขาไม่รู้วิธีการเขียนหลักฐานความถูกต้อง

อีกประการหนึ่งคือการกำหนดเงื่อนไขความถูกต้องสำหรับระบบซอฟต์แวร์ที่ซับซ้อน (โดยเฉพาะการแจกจ่าย) เป็นงานที่ยากมากและใช้เวลานาน พวกเขาคาดว่าจะมีสิ่งที่ดูเหมือนว่าจะทำงานในเวลาไม่กี่สัปดาห์

อีกเหตุผลหนึ่งก็คือความถูกต้องของโปรแกรมขึ้นอยู่กับระบบอื่น ๆ ที่เขียนโดยคนอื่นซึ่งไม่มีความหมายที่ชัดเจน มีกฎหมายของไฮรัมที่บอกว่าถ้าห้องสมุด / บริการของคุณมีพฤติกรรมที่สังเกตได้ (ไม่ใช่ส่วนหนึ่งของสัญญา) ในที่สุดบางคนก็ต้องพึ่งพามัน นั่นหมายถึงความคิดในการพัฒนาซอฟต์แวร์ในรูปแบบโมดูลาร์ที่มีสัญญาที่ชัดเจนเช่นศัพท์ในคณิตศาสตร์ไม่สามารถใช้งานได้จริง มันแย่ลงในภาษาที่ใช้การสะท้อน แม้ว่าโปรแกรมที่ถูกต้องในวันนี้มันอาจจะพังในวันพรุ่งนี้เมื่อมีคนทำการปรับโครงสร้างเล็กน้อยในการอ้างอิงอย่างใดอย่างหนึ่ง

ในทางปฏิบัติสิ่งที่มักจะเกิดขึ้นก็คือพวกเขามีการทดสอบ การทดสอบทำหน้าที่เป็นสิ่งที่คาดหวังจากโปรแกรม ทุกครั้งที่พบข้อผิดพลาดใหม่จะเพิ่มการทดสอบเพื่อตรวจจับ มันทำงานเพื่อขยายบางส่วน แต่ไม่ได้พิสูจน์ความถูกต้อง

เมื่อคนไม่มีทักษะในการกำหนดความถูกต้องหรือเขียนโปรแกรมที่ถูกต้องหรือคาดว่าจะทำเช่นนั้นและค่อนข้างยากไม่แปลกใจเลยที่ซอฟต์แวร์ไม่ถูกต้อง

แต่โปรดทราบด้วยว่าท้ายที่สุดในสถานที่ที่ดีกว่าวิศวกรรมซอฟต์แวร์จะทำโดยการตรวจสอบรหัส นั่นคือผู้เขียนโปรแกรมจะต้องโน้มน้าวให้บุคคลอื่นอย่างน้อยหนึ่งโปรแกรมทำงานอย่างถูกต้อง นั่นคือประเด็นที่มีการโต้แย้งระดับสูงอย่างไม่เป็นทางการ แต่โดยทั่วไปแล้วไม่มีอะไรใกล้เคียงกับคำจำกัดความที่ชัดเจนของความถูกต้องหรือการพิสูจน์ความถูกต้องที่ชัดเจน

ในวิชาคณิตศาสตร์ผู้คนให้ความสำคัญกับความถูกต้อง ในการพัฒนาซอฟต์แวร์มีหลายสิ่งที่โปรแกรมเมอร์ต้องการดูแลและมีการแลกเปลี่ยนระหว่างกัน การมีซอฟต์แวร์ที่ปราศจากข้อผิดพลาดหรือแม้กระทั่งคำจำกัดความที่ถูกต้อง (พร้อมกับความต้องการที่เปลี่ยนแปลงตลอดเวลา) เป็นอุดมคติ แต่มันจะต้องมีการแลกเปลี่ยนกับปัจจัยอื่น ๆ และสิ่งที่สำคัญที่สุดในบรรดาพวกเขาก็คือเวลาที่ใช้ในการพัฒนา นักพัฒนา ดังนั้นในทางปฏิบัติในสถานที่ที่ดีกว่าเป้าหมายและกระบวนการต่าง ๆ จะช่วยลดความเสี่ยงของข้อบกพร่องได้มากที่สุดเท่าที่จะทำได้แทนที่จะทำให้ปราศจากข้อบกพร่องของซอฟต์แวร์

มีคำตอบที่ดีอยู่แล้ว แต่ก็ยังมีเหตุผลทางคณิตศาสตร์และการเขียนโปรแกรมที่ไม่เหมือนกัน

1 หลักฐานทางคณิตศาสตร์มีแนวโน้มที่จะง่ายกว่าโปรแกรมคอมพิวเตอร์ พิจารณาขั้นตอนแรกของการพิสูจน์สมมุติฐาน:

ปล่อยให้เป็นจำนวนเต็ม

ให้ b เป็นจำนวนเต็ม

ให้ c = a + b

จนถึงตอนนี้หลักฐานก็ใช้ได้ ลองเปลี่ยนเป็นขั้นตอนแรกของโปรแกรมที่คล้ายกัน:

ให้ a = input ();

ให้ b = อินพุต ();

ให้ c = a + b;

เรามีปัญหามากมายอยู่แล้ว สมมติว่าผู้ใช้ป้อนจำนวนเต็มจริงๆเราต้องตรวจสอบขอบเขต คือมากกว่า -32768 (หรืออะไรก็ตาม int นาทีบนระบบของคุณเป็น)? คือน้อยกว่า 32767? ตอนนี้เรามีการตรวจสอบในสิ่งเดียวกันสำหรับข และเนื่องจากเราได้เพิ่มaและbโปรแกรมจึงไม่ถูกต้องเว้นแต่a + bมากกว่า -32768 และน้อยกว่า 32767 นั่นคือ 5 เงื่อนไขแยกต่างหากที่โปรแกรมเมอร์ต้องกังวลเกี่ยวกับการที่นักคณิตศาสตร์สามารถเพิกเฉยได้ โปรแกรมเมอร์ไม่เพียง แต่ต้องกังวลเกี่ยวกับพวกเขาเท่านั้นเขายังต้องคิดออกว่าจะทำอย่างไรเมื่อเงื่อนไขข้อใดข้อหนึ่งเหล่านั้นไม่ตรงตามเงื่อนไขและเขียนโค้ดเพื่อทำสิ่งใดก็ตามที่เขาตัดสินใจ คณิตศาสตร์เป็นเรื่องง่าย การเขียนโปรแกรมยาก

2 ผู้ถามไม่ได้บอกว่าเขาอ้างถึงข้อผิดพลาดในการคอมไพล์หรือข้อผิดพลาดรันไทม์ แต่โดยทั่วไปโปรแกรมเมอร์ไม่สนใจข้อผิดพลาดในการคอมไพล์ คอมไพเลอร์พบพวกเขาและพวกมันง่ายต่อการแก้ไข พวกมันเหมือนกับการพิมพ์ผิด ผู้คนพิมพ์หลายย่อหน้าโดยไม่มีข้อผิดพลาดบ่อยครั้งเพียงใด

3 การฝึกอบรมตั้งแต่อายุยังน้อยเราถูกสอนให้ทำคณิตศาสตร์และเราเผชิญกับผลที่ตามมาจากความผิดพลาดเล็กน้อยซ้ำแล้วซ้ำอีก นักคณิตศาสตร์ที่ผ่านการฝึกอบรมจะต้องเริ่มแก้ปัญหาพีชคณิตแบบหลายขั้นตอนโดยปกติในโรงเรียนมัธยมและต้องทำปัญหาดังกล่าวหลายสิบ (หรือมากกว่า) ทุกสัปดาห์เป็นเวลาหนึ่งปี เครื่องหมายลบที่หายไปเดียวทำให้เกิดปัญหาทั้งหมดว่าผิด หลังจากพีชคณิตปัญหานั้นยาวนานขึ้นและยากขึ้น ในทางกลับกันโปรแกรมเมอร์มักจะมีการฝึกอบรมที่เป็นทางการน้อยกว่ามาก หลายคนเรียนรู้ด้วยตนเอง (อย่างน้อยในตอนแรก) และไม่ได้รับการฝึกอบรมอย่างเป็นทางการจนกระทั่งมหาวิทยาลัย แม้แต่ในระดับมหาวิทยาลัยโปรแกรมเมอร์ก็ต้องเรียนวิชาคณิตศาสตร์ไม่กี่วิชาในขณะที่นักคณิตศาสตร์อาจเรียนวิชาเขียนโปรแกรมเพียงหนึ่งหรือสองวิชา

ฉันชอบคำตอบของ Yuval แต่ฉันต้องการที่จะ riff ออกไปหน่อย เหตุผลหนึ่งที่คุณอาจพบว่าการเขียนหลักฐานทางคณิตศาสตร์ง่ายขึ้นอาจทำให้เกิดความสงบทางคณิตศาสตร์อย่างสงบ หากต้องการดูสิ่งที่ฉันหมายถึงพิจารณาดังต่อไปนี้:

• ฟังก์ชั่นในทางคณิตศาสตร์ล้วนๆ (ผลลัพธ์ทั้งหมดของการเรียกฟังก์ชั่นนั้นถูกห่อหุ้มอย่างสมบูรณ์ในค่าส่งคืนซึ่งถูกกำหนดและคำนวณอย่างสมบูรณ์จากค่าอินพุต)
• คณิตศาสตร์ไม่มีการกลายพันธุ์หรือการมอบหมายใหม่ (เมื่อคุณต้องการสร้างแบบจำลองฟังก์ชั่นและลำดับดังกล่าว)
• คณิตศาสตร์นั้นมีความโปร่งใสในการอ้างอิง (เช่นไม่มีพอยน์เตอร์, ไม่มีแนวคิดของการโทรหาโดยชื่อเทียบกับการโทรตามตัวอักษร) และวัตถุทางคณิตศาสตร์มีความหมายเชิงมิติ (ถ้าสองสิ่งนั้นเหมือนกันในทุกวิธีที่สังเกตได้) สิ่งเดียวกัน).

แม้ว่าจะพิสูจน์ได้ว่าข้อ จำกัด ข้างต้นนั้นทำให้การเขียนโปรแกรมง่ายขึ้นหรือไม่แต่ฉันคิดว่ามีข้อตกลงกว้าง ๆ ที่ข้อ จำกัด ข้างต้นทำให้การใช้โปรแกรมง่ายขึ้น สิ่งสำคัญที่คุณทำเมื่อเขียนหลักฐานคณิตศาสตร์คือเหตุผลเกี่ยวกับหลักฐานที่คุณเขียนอยู่ในขณะนี้ (เนื่องจากแตกต่างจากในการเขียนโปรแกรมคุณไม่ต้องทำซ้ำในคณิตศาสตร์เนื่องจาก abstractions ไม่มีค่าใช้จ่าย) ดังนั้นโดยทั่วไปแล้ว ข้อ จำกัด ข้างต้น

หลักฐานทางคณิตศาสตร์ขั้นพื้นฐานไม่ได้มีค่าเท่ากับการใช้งานจริงที่ออกแบบมาเพื่อตอบสนองความต้องการของมนุษย์ที่มีชีวิต

มนุษย์จะเปลี่ยนแปลงความต้องการความต้องการและข้อกำหนดเกี่ยวกับสิ่งที่อาจเป็นประจำทุกวันในขอบเขตของโปรแกรมคอมพิวเตอร์

อะไรคือความแตกต่างเกี่ยวกับการเขียนหลักฐานทางคณิตศาสตร์ที่ไม่ผิดพลาดและการเขียนรหัสคอมพิวเตอร์ที่ไม่ผิดพลาดที่ทำให้มันเป็นแบบนั้นเพื่อให้อดีตเป็นเวกัสที่ดีกว่าสมัยก่อน?

ด้วยความต้องการที่ชัดเจนเหมือนกับปัญหาทางคณิตศาสตร์สามารถเขียนโปรแกรมที่ไม่มีข้อผิดพลาดได้ การพิสูจน์ว่าอัลกอริธึมของ Dijkstra สามารถหาเส้นทางที่สั้นที่สุดระหว่างสองจุดบนกราฟนั้นไม่เหมือนกับการใช้โปรแกรมที่รับอินพุตโดยพลการและหาจุดที่สั้นที่สุดระหว่างสองจุดใด ๆ ในนั้น

มีหน่วยความจำประสิทธิภาพและฮาร์ดแวร์ที่เกี่ยวข้องในการจัดการ ฉันหวังว่าเราไม่สามารถคิดถึงสิ่งเหล่านั้นเมื่อเขียนอัลกอริธึมที่เราสามารถใช้โครงสร้างที่บริสุทธิ์และใช้งานได้เพื่อจัดการสิ่งนี้ แต่โปรแกรมคอมพิวเตอร์อาศัยอยู่ในโลกของฮาร์ดแวร์ "ที่แท้จริง" ในขณะที่การพิสูจน์ทางคณิตศาสตร์

หรือจะรวบรัดมากขึ้น :

เมื่อมองจากมุมมองอื่นในสภาพแวดล้อมที่ไม่ใช่เชิงวิชาการมักจะเกิดปัญหากับเงิน

ในขณะที่โพสต์อื่น ๆ ยืนยันดีคณิตศาสตร์เป็นข้อกำหนดนามธรรมเดียวดังนั้นการพิสูจน์ต้องทำงานอย่างต่อเนื่องภายในข้อกำหนดที่จะพิสูจน์ โปรแกรมคอมพิวเตอร์อาจดำเนินการเกี่ยวกับการใช้งานจำนวนมากของข้อกำหนดทางนามธรรมของคณิตศาสตร์ - นั่นคือวิธีที่ภาษาหนึ่งหรือผู้ผลิตฮาร์ดแวร์ใช้คณิตศาสตร์จุดลอยตัวอาจแตกต่างจากที่อื่นเล็กน้อยซึ่งอาจทำให้เกิดความผันผวนเล็กน้อยในผลลัพธ์

เช่น 'การพิสูจน์' โปรแกรมคอมพิวเตอร์ก่อนที่จะเขียนมันจะเกี่ยวข้องกับการพิสูจน์ตรรกะในระดับฮาร์ดแวร์ระดับระบบปฏิบัติการระดับไดรเวอร์ภาษาโปรแกรมคอมไพเลอร์อาจเป็นล่ามและอื่น ๆ สำหรับการรวมกันของฮาร์ดแวร์ที่เป็นไปได้ทุกโปรแกรม สามารถทำงานได้และข้อมูลใด ๆ ที่เป็นไปได้ คุณอาจพบว่าระดับของการเตรียมการและความเข้าใจในภารกิจอวกาศระบบอาวุธหรือระบบควบคุมพลังงานนิวเคลียร์ซึ่งความล้มเหลวหมายถึงเงินหลายหมื่นล้านดอลลาร์ที่สูญเสียไปและอาจมีผู้เสียชีวิตจำนวนมาก แต่ไม่มากนัก

สำหรับโปรแกรมเมอร์และ / หรือธุรกิจในชีวิตประจำวันของคุณมันมีค่าใช้จ่ายมากกว่าที่จะยอมรับความถูกต้องในระดับที่ถูกต้องในรหัสที่ถูกต้องส่วนใหญ่และขายผลิตภัณฑ์ที่ใช้งานได้และนักพัฒนาอาจแก้ไขข้อผิดพลาดย้อนหลัง การใช้

ฉันคิดว่าเหตุผลของคุณถูกต้อง แต่ข้อมูลของคุณไม่ถูกต้อง หลักฐานทางคณิตศาสตร์ไม่ได้มีความผิดพลาดมากกว่าโปรแกรมหากทั้งสองเขียนโดยมนุษย์ Dijkstra ถูกยกมาแล้วที่นี่ แต่ฉันจะเสนอราคาเพิ่มเติม

แต่เราต้องจัดระเบียบการคำนวณในแบบที่อำนาจ จำกัด ของเราเพียงพอที่จะรับประกันได้ว่าการคำนวณจะสร้างผลที่ต้องการ การจัดระเบียบนี้รวมถึงองค์ประกอบของโปรแกรมและเราต้องเผชิญกับปัญหาของขนาดถัดไปคือ ความยาวของข้อความโปรแกรมและเราควรให้ปัญหานี้ยังได้รับการยอมรับอย่างชัดเจน เราควรตระหนักถึงความจริงที่ว่าขอบเขตที่เราสามารถอ่านหรือเขียนข้อความนั้นขึ้นอยู่กับขนาดของมันเป็นอย่างมาก [ ... ]

มันอยู่ในอารมณ์เดียวกับที่ฉันควรจะดึงความสนใจของผู้อ่านต่อความจริงที่ว่า "ความชัดเจน" มีลักษณะเชิงปริมาณเด่นชัดซึ่งเป็นความจริงที่นักคณิตศาสตร์หลายคนสงสัยพอดูเหมือนจะไม่รู้ตัว ทฤษฎีที่ระบุความถูกต้องของข้อสรุปเมื่อสิบหน้าเต็มไปด้วยเงื่อนไขเป็นที่น่าพอใจแทบจะไม่เป็นเครื่องมือที่สะดวกเพราะทุกเงื่อนไขจะต้องตรวจสอบทุกครั้งที่มีการอุทธรณ์ทฤษฎีบท ในเรขาคณิตแบบยุคลิดทฤษฎีบทของพีธากอรัสมีจุดสามจุด A, B และ C เช่นนั้นผ่าน A และ C เป็นเส้นตรงสามารถลาก orthogonal เป็นเส้นตรงผ่าน B และ C นักคณิตศาสตร์จำนวนมากชื่นชมว่าทฤษฎีบทยังคงใช้งานได้เมื่อบางคน หรือทั้งหมดของจุด A, B และ C เกิดขึ้นพร้อมกัน? แต่ดูเหมือนว่าส่วนใหญ่รับผิดชอบความสะดวกสบายที่ทฤษฎีบทพีทาโกรัสสามารถใช้ได้

สรุป: ในฐานะมนุษย์ที่มีไหวพริบช้าฉันมีหัวที่เล็กมากและฉันควรเรียนรู้ที่จะอยู่กับมันและเคารพข้อ จำกัด ของฉันและให้เครดิตพวกเขาอย่างเต็มที่แทนที่จะพยายามเพิกเฉยต่อพวกเขา ลงโทษโดยความล้มเหลว

นี่คือการแก้ไขเล็กน้อยสามย่อหน้าสุดท้ายจากบทแรกของการเขียนโปรแกรมแบบโครงสร้างของ Dijkstra

ในการใช้ถ้อยคำใหม่นี้เพื่อนำไปใช้กับคำถามของคุณได้ดีขึ้น: ความถูกต้องเป็นหน้าที่ของขนาดการพิสูจน์ของคุณ ความถูกต้องของการพิสูจน์ทางคณิตศาสตร์ที่ยาวนานนั้นยากมากที่จะสร้าง (พิสูจน์ "เผยแพร่" จำนวนมากอาศัยอยู่ในบริเวณขอบรกของความไม่แน่นอนเนื่องจากไม่มีใครตรวจสอบแล้ว) แต่ถ้าคุณเปรียบเทียบความถูกต้องของโปรแกรมเล็ก ๆ น้อย ๆ กับหลักฐานอันเล็กน้อยก็ไม่มีความแตกต่างที่สังเกตได้ อย่างไรก็ตามผู้ช่วยพิสูจน์อัตโนมัติ (ในแง่ที่กว้างขึ้น, คอมไพเลอร์ Java ของคุณยังเป็นผู้ช่วยพิสูจน์), ให้โปรแกรมชนะโดยอัตโนมัติจำนวนมากรากฐาน

ตามที่คำตอบอื่น ๆ ได้สัมผัสในคำตอบของพวกเขา (ฉันต้องการที่จะอธิบายอย่างละเอียด) แต่ส่วนใหญ่ของปัญหาคือการใช้ห้องสมุด แม้ว่าจะมีเอกสารที่สมบูรณ์แบบ (เช่นเดียวกับรหัสที่ไม่มีข้อผิดพลาด) แต่ก็เป็นไปไม่ได้ที่จะถ่ายโอนความรู้ที่สมบูรณ์ของไลบรารีไปยังโปรแกรมเมอร์ทุกคนที่ใช้ไลบรารี หากโปรแกรมเมอร์ไม่เข้าใจไลบรารีของพวกเขาอย่างสมบูรณ์พวกเขาอาจทำผิดพลาดเมื่อใช้มัน บางครั้งสิ่งเหล่านี้อาจส่งผลให้เกิดข้อบกพร่องที่สำคัญที่ค้นพบเมื่อรหัสไม่ทำงาน แต่สำหรับข้อผิดพลาดเล็กน้อยสิ่งเหล่านี้อาจไม่มีใครสังเกตเห็น

สถานการณ์ที่คล้ายกันคือถ้านักคณิตศาสตร์ใช้บทพิสูจน์และบทแทรกที่มีอยู่โดยไม่เข้าใจอย่างถ่องแท้ หลักฐานของตัวเองน่าจะมีข้อบกพร่อง ขณะนี้อาจแนะนำวิธีแก้ปัญหาคือการเรียนรู้อย่างสมบูรณ์ทุกไลบรารีที่ใช้ นี่ใช้เวลานานมากและอาจต้องการความรู้เกี่ยวกับโดเมนที่โปรแกรมเมอร์ไม่มี (ฉันรู้ว่ามีการเรียงลำดับดีเอ็นเอ / การสังเคราะห์โปรตีนน้อยมาก แต่สามารถทำงานกับแนวคิดเหล่านี้โดยใช้ห้องสมุด)

วิศวกรรมซอฟต์แวร์ (โดยทั่วไปจริงๆแล้ว) นั้นมีพื้นฐานมาจากการห่อหุ้มสิ่งที่เป็นนามธรรมในระดับที่แตกต่างกันเพื่อให้ผู้คนสามารถมุ่งเน้นไปที่ปัญหาเล็ก ๆ ที่พวกเขาเชี่ยวชาญซึ่งจะช่วยให้ผู้คนพัฒนาความเชี่ยวชาญในพื้นที่ของพวกเขา ระหว่างแต่ละชั้น เมื่อการสื่อสารนั้นไม่สมบูรณ์แบบมันก็ทำให้เกิดปัญหา

ฉันจะพยายามเป็นต้นฉบับหลังจากคำตอบที่ดีทั้งหมด

โปรแกรมเป็นบทพิสูจน์

รูปมอร์ฟิสม์ของแกงกะหรี่ - ฮาวเวิร์ดบอกเราว่าประเภทในโปรแกรมของคุณคือทฤษฎีบทและรหัสที่แท้จริงคือข้อพิสูจน์ของพวกเขา

เป็นที่ยอมรับว่าเป็นมุมมองที่เป็นนามธรรมและสูงมาก ปัญหาที่คุณอาจหมายถึงคือการเขียนรหัสทั่วไปนั้นยากกว่าเพราะมันมีระดับต่ำเกินไป ในกรณีส่วนใหญ่คุณ "ต้องบอกเครื่องว่าต้องทำอะไร" หรือเพื่อดูจากรอบทางอื่น: นักคณิตศาสตร์เก่งในเรื่องนามธรรม

ตามหมายเหตุด้าน: "ดนตรีแห่งสายน้ำ"เป็นหนึ่งในสะพานที่สวยที่สุดระหว่างทั้งสอง มันเป็นพื้นตั้งค่าสิ่งที่จะสามารถที่จะพูดว่า "ฉันต้องการนี้ในที่ทาง" และเครื่องน่าอัศจรรย์ไม่นี้ตรงตามที่ต้องการ

ไม่มีคำตอบอื่นใดอีกมากมายที่ชี้ให้เห็นต่อไปนี้ การพิสูจน์ทางคณิตศาสตร์ทำงานบนระบบการคำนวณแบบจินตภาพซึ่งมีหน่วยความจำไม่สิ้นสุดและกำลังการคำนวณแบบไม่มีที่สิ้นสุด พวกเขาสามารถเก็บจำนวนมากโดยพลการเพื่อความแม่นยำไม่มีที่สิ้นสุดและไม่สูญเสียความแม่นยำในการคำนวณใด ๆ

$\pi$

มันไม่ใช่. การพิสูจน์ทางคณิตศาสตร์มีความสอดคล้องตามธรรมชาติเป็นเพียงแค่ผู้อ่านของพวกเขาได้รับอนุญาตมากกว่าคอมไพเลอร์ ในทำนองเดียวกันผู้อ่านของโปรแกรมคอมพิวเตอร์จะหลงเชื่ออย่างง่ายดายว่ามันถูกต้องอย่างน้อยก็จนกว่าพวกเขาจะพยายามเรียกใช้

ตัวอย่างเช่นหากเราพยายามแปลหลักฐานทางคณิตศาสตร์เป็นภาษาทางการเช่น ZFC มันจะมีข้อบกพร่องด้วย นั่นเป็นเพราะการพิสูจน์เหล่านี้อาจใช้เวลานานมากดังนั้นเราจึงถูกบังคับให้เขียนโปรแกรมเพื่อสร้างการพิสูจน์ มีคนเพียงไม่กี่คนเท่านั้นที่ประสบปัญหาอย่างอันตรายถึงแม้จะมีการวิจัยเชิงรุกในการพิสูจน์หลักฐานพื้นฐาน

และแน่นอนคณิตศาสตร์สามารถรับ BSOD! มันจะไม่เป็นครั้งแรก!

แนวคิดดั้งเดิมนี้ว่าหลักฐานทางคณิตศาสตร์ทั้งหมดที่ได้รับการตรวจสอบอย่างเพียงพอนั้นถูกต้องหรือสามารถแก้ไขได้ก็เป็นสิ่งเดียวที่กระตุ้นให้โครงการซอฟต์แวร์ของคุณทำงาน: ตราบใดที่เรายังอยู่ในแผนงานเราจะกำจัดข้อผิดพลาดทั้งหมดและ คุณสมบัติเสร็จสมบูรณ์ - เป็นกระบวนการวนซ้ำไปสู่ผลิตภัณฑ์ขั้นสุดท้ายที่แน่นอน

นี่คือด้านพลิก ดูสิเราได้รับเงินสนับสนุนแล้วตรวจสอบแนวคิดธุรกิจเอกสารทั้งหมดอยู่ที่นี่เพื่อให้คุณอ่าน เราแค่ต้องการให้คุณประหารชีวิตและแน่นอน!

อย่ารู้สึกเสียใจกับฮิลแบร์ตเช่นกันเขารู้ว่าเขากำลังทำอะไรอยู่ มันเป็นแค่เรื่องธุรกิจ

ถ้าคุณต้องการที่จะแน่ใจจริงๆใช้ทุกอย่างเป็นกรณี ๆ ไปและสรุปข้อสรุปของคุณเอง!

ฉันเห็นสองเหตุผลสำคัญที่ทำให้โปรแกรมมีข้อผิดพลาดมากกว่าข้อพิสูจน์ทางคณิตศาสตร์:

1: โปรแกรมประกอบด้วยตัวแปรหรือวัตถุแบบไดนามิกที่เปลี่ยนแปลงตลอดเวลาในขณะที่วัตถุทางคณิตศาสตร์ในการพิสูจน์มักจะคงที่ ดังนั้นสัญกรณ์ในคณิตศาสตร์สามารถใช้เป็นการสนับสนุนโดยตรงของการให้เหตุผล (และถ้า a = b จะยังคงเป็นกรณีนี้) ซึ่งสิ่งนี้ไม่ทำงานในโปรแกรม นอกจากนี้ปัญหานี้ยิ่งแย่ลงเมื่อโปรแกรมขนานกันหรือมีหลายเธรด

2: คณิตศาสตร์มักจะถือว่าวัตถุที่กำหนดไว้ค่อนข้างเรียบร้อย (กราฟ, แมนิโฟลด์, แหวน, กลุ่ม, ฯลฯ ) ในขณะที่การเขียนโปรแกรมจัดการกับวัตถุที่ยุ่งและค่อนข้างผิดปกติ: คณิตศาสตร์ที่มีความแม่นยำแน่นอน, สแต็ก จำกัด แน่นอน ฯลฯ การรวบรวมเงื่อนไขที่เกี่ยวข้องกับความถูกต้องจึงเป็นเรื่องยากมากที่จะทราบ

คุณควรแยก "หมวดหมู่" ที่แตกต่างกันสองแบบ:

• หลักฐานปลอม (หรือรหัสหลอก) - นั่นคือสิ่งที่คุณเห็นในหนังสือ มันเขียนในภาษาธรรมชาติ (เช่นภาษาอังกฤษ) นั่นคือสิ่งที่คุณควรใช้เพื่อเรียนรู้คณิตศาสตร์ (หรืออัลกอริทึม)
• การพิสูจน์อย่างเป็นทางการ (หรือรหัสที่เป็นทางการ) - คุณเขียนเมื่อคุณต้องการการพิสูจน์ (หรือรหัส) ของคุณที่จะพิสูจน์ได้ทางกลไก (หรือปฏิบัติการ) การเป็นตัวแทนดังกล่าวไม่จำเป็นต้องมี "สติปัญญาของมนุษย์" มันสามารถตรวจสอบได้ (หรือดำเนินการ) กลไกโดยทำตามขั้นตอนที่กำหนดไว้ล่วงหน้าบางส่วน

เราใช้โค้ดหลอกมาหลายพันปี (เช่นอัลกอริทึม Euclids) การเขียนรหัสเป็นทางการ (ในภาษาที่เป็นทางการเช่น C หรือ Java) เป็นที่นิยมอย่างมากและมีประโยชน์หลังจากการประดิษฐ์ของคอมพิวเตอร์ แต่น่าเสียดายที่การพิสูจน์อย่างเป็นทางการ (ในภาษาที่เป็นทางการเช่นปรินชิเปียมาเธมาติกาหรือเมตาแมท) ไม่ได้รับความนิยมมาก และเนื่องจากทุกคนเขียนบทพิสูจน์ปลอมในวันนี้ผู้คนมักจะโต้แย้งเกี่ยวกับบทพิสูจน์ใหม่ ข้อผิดพลาดในพวกเขาสามารถพบปีปีทศวรรษหรือแม้กระทั่งศตวรรษหลังจาก "พิสูจน์" จริง

ฉันไม่พบข้อมูลอ้างอิง แต่ฉันคิดว่า Tony Hoare เคยพูดอะไรบางอย่างตามบรรทัดต่อไปนี้: ความแตกต่างระหว่างการตรวจสอบโปรแกรมและการตรวจสอบหลักฐานคือการตรวจสอบหลักฐานสามารถตรวจสอบได้สองบรรทัดในแต่ละครั้ง

ในคำ: ท้องถิ่น

มีการเขียนหลักฐานเพื่อให้สามารถตรวจสอบได้ง่าย โปรแกรมถูกเขียนขึ้นเพื่อให้สามารถดำเนินการได้ ด้วยเหตุนี้โปรแกรมเมอร์จึงมักทิ้งข้อมูลที่เป็นประโยชน์กับบางคนที่ตรวจสอบโปรแกรม

พิจารณาโปรแกรมนี้โดยที่ x อ่านได้อย่างเดียว

    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)

มันง่ายต่อการดำเนินการ แต่ยากที่จะตรวจสอบ

แต่ถ้าฉันเพิ่มกลับใน assertions ที่ขาดหายไปคุณสามารถตรวจสอบโปรแกรมในเครื่องโดยตรวจสอบว่าแต่ละลำดับของการมอบหมายนั้นถูกต้องโดย repect ไปก่อนและ postconditions และสำหรับแต่ละลูป postcondition ของ 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)

กลับมาที่คำถามเดิม: ทำไมการจดหลักฐานพิสูจน์ทางคณิตศาสตร์จึงพิสูจน์ได้มากกว่าการเขียนรหัสคอมพิวเตอร์? เนื่องจากข้อพิสูจน์ได้รับการออกแบบให้ตรวจสอบได้ง่ายโดยผู้อ่านจึงมีการตรวจสอบอย่างง่ายดายโดยผู้เขียนและทำให้ผู้เขียนเตือนมักจะไม่ทำผิดพลาดทางตรรกะ (หรืออย่างน้อยเก็บไว้) ในหลักฐานของพวกเขา เมื่อเราโปรแกรมเรามักจะล้มเหลวในการเขียนเหตุผลที่รหัสของเราถูกต้อง; ผลก็คือมันเป็นเรื่องยากสำหรับทั้งผู้อ่านและผู้เขียนโปรแกรมในการตรวจสอบรหัส; ผลที่ได้คือผู้เขียนทำข้อผิดพลาด (แล้วเก็บไว้)

แต่มีความหวัง ถ้าเมื่อเราเขียนโปรแกรมเราก็เขียนเหตุผลที่เราคิดว่าโปรแกรมนั้นถูกต้องเราสามารถตรวจสอบรหัสในขณะที่เราเขียนมันและเขียนรหัสรถที่น้อยลง นี่ยังมีประโยชน์ที่ผู้อื่นสามารถอ่านรหัสของเราและตรวจสอบด้วยตนเอง

เราสามารถถามได้ว่าในทางปฏิบัติยากขึ้นหรือในหลักการเขียนข้อพิสูจน์หรือเขียนรหัส

ในทางปฏิบัติการพิสูจน์นั้นยากกว่าการเข้ารหัส มีคนเพียงไม่กี่คนที่เรียนคณิตศาสตร์ในระดับวิทยาลัยมาสองปีแล้วสามารถเขียนบทพิสูจน์ได้ ในกลุ่มคนที่เคยเรียนระดับ CS มาสองปีอาจจะมีอย่างน้อย 30% ที่จะแก้ปัญหาFizzBuzzได้

แต่โดยหลักการแล้วมีเหตุผลเบื้องต้นว่าทำไมมันถึงเป็นอย่างนั้น อย่างน้อยที่สุดก็ในหลักการพิสูจน์สามารถตรวจสอบความถูกต้องผ่านกระบวนการที่ไม่ต้องใช้วิจารณญาณหรือความเข้าใจใด ๆ โปรแกรมไม่สามารถทำได้ - เราไม่สามารถบอกได้แม้ผ่านกระบวนการที่กำหนดไว้ว่าจะหยุดโปรแกรมหรือไม่

เพียงส่วนเล็ก ๆ ของข้อความทางคณิตศาสตร์ที่เป็นจริงสามารถพิสูจน์ได้จริง ที่สำคัญกว่านั้นมันเป็นไปไม่ได้ที่จะสร้างชุดสัจพจน์ทางคณิตศาสตร์ที่ไม่เกี่ยวกับเรื่องไร้สาระซึ่งจะช่วยให้สามารถพิสูจน์ได้ว่าข้อความจริงทั้งหมด หากต้องการเขียนโปรแกรมเพียงเล็กน้อยเพื่อทำสิ่งต่าง ๆ ที่สามารถทำได้กับคอมพิวเตอร์มันจะเป็นไปได้ที่จะเขียนซอฟต์แวร์ที่แก้ไขได้อย่างถูกต้อง แต่คอมพิวเตอร์มักถูกเรียกให้ทำสิ่งต่าง ๆ นอกเหนือจากที่ถูกต้อง ซอฟต์แวร์สามารถบรรลุผล

(*) เป็นไปได้ที่จะกำหนดชุดของสัจพจน์ซึ่งจะอนุญาตให้ระบุข้อความจริงทั้งหมดและได้รับการพิสูจน์แล้ว แต่โดยทั่วไปไม่น่าสนใจมาก ในขณะที่เป็นไปได้ที่จะจัดประเภทสัจพจน์อย่างเป็นทางการในลักษณะที่เป็นหรือไม่พูดค่อนข้างไร้สาระประเด็นสำคัญคือการมีอยู่ของข้อความที่พิสูจน์ได้จริง แต่ไม่สามารถพิสูจน์ได้ว่าไม่ใช่ข้อบกพร่องในชุด ของสัจพจน์ การเพิ่มสัจพจน์เพื่อทำให้ข้อความที่เป็นจริง แต่ไม่สามารถพิสูจน์ได้ที่มีอยู่จะทำให้ข้อความอื่น ๆ กลายเป็นจริง แต่ไม่สามารถพิสูจน์ได้

1. โปรแกรมคอมพิวเตอร์ได้รับการทดสอบในโลกแห่งความเป็นจริง ข้อผิดพลาดทางเทคนิคที่ยุ่งยากในการพิสูจน์ทางคณิตศาสตร์ที่มีผู้คนจำนวน จำกัด สามารถเข้าใจได้มีโอกาสที่จะไม่ถูกตรวจพบ ข้อผิดพลาดประเภทเดียวกันในผลิตภัณฑ์ซอฟต์แวร์มีแนวโน้มที่จะสร้างพฤติกรรมแปลก ๆ ที่ผู้ใช้ทั่วไปสังเกตเห็น ดังนั้นหลักฐานอาจไม่ถูกต้อง

2. โปรแกรมคอมพิวเตอร์ทำหน้าที่เสมือนจริงที่เป็นประโยชน์ พวกเขาไม่จำเป็นต้องทำอย่างถูกต้อง 100% และมาตรฐานความถูกต้องสูงนั้นค่อนข้างแพง การพิสูจน์จะมีประโยชน์ก็ต่อเมื่อพิสูจน์ได้จริงบางอย่างดังนั้นการข้ามส่วน 'ถูกต้อง 100%' จึงไม่ใช่ตัวเลือกสำหรับนักคณิตศาสตร์

3. มีการพิสูจน์หลักฐานทางคณิตศาสตร์อย่างชัดเจน หากหลักฐานมีข้อบกพร่องผู้เขียนได้ทำผิดพลาด ข้อบกพร่องจำนวนมากในโปรแกรมคอมพิวเตอร์เกิดขึ้นเนื่องจากข้อกำหนดไม่ได้สื่อสารอย่างเหมาะสมหรือมีปัญหาความเข้ากันได้กับสิ่งที่โปรแกรมเมอร์ไม่เคยได้ยินมาก่อน

4. โปรแกรมคอมพิวเตอร์จำนวนมากไม่สามารถพิสูจน์ได้ว่าถูกต้อง พวกเขาอาจแก้ปัญหาที่กำหนดอย่างไม่เป็นทางการเช่นจดจำใบหน้า หรืออาจเป็นซอฟต์แวร์ทำนายผลตลาดหุ้นและมีเป้าหมายที่กำหนดไว้อย่างเป็นทางการ แต่เกี่ยวข้องกับตัวแปรในโลกแห่งความจริงมากเกินไป

ส่วนใหญ่ของคณิตศาสตร์เป็นกิจกรรมของมนุษย์ได้มีการพัฒนาภาษาเฉพาะโดเมนซึ่งการพิสูจน์ของหลักฐานเป็นเรื่องง่ายสำหรับมนุษย์ที่จะทำ

คุณภาพของการพิสูจน์นั้นแปรผกผันกับความยาวและความซับซ้อนของมัน ความยาวและความซับซ้อนมักจะลดลงโดยการพัฒนาสัญกรณ์ที่ดีสำหรับการอธิบายสถานการณ์ในมือเกี่ยวกับสิ่งที่เรากำลังทำพร้อมกับแนวคิดเสริมที่มีปฏิสัมพันธ์ในการพิสูจน์โดยเฉพาะอย่างยิ่งภายใต้การพิจารณา

นี่ไม่ใช่กระบวนการที่ง่ายและหลักฐานส่วนใหญ่ที่เห็นโดยผู้คนที่ถูกลบออกจากแถวหน้าของการวิจัยเกิดขึ้นในสาขาคณิตศาสตร์ (เช่นพีชคณิตและการวิเคราะห์) ที่มีหลายร้อยถ้าไม่ใช่พันปีในระหว่างที่สัญกรณ์ของสาขานั้นมี ได้รับการขัดเกลาไปจนถึงจุดที่การกระทำของการเขียนหลักฐานจริงรู้สึกเหมือนสายลม

ในแนวหน้าของการวิจัยแม้ว่าโดยเฉพาะอย่างยิ่งถ้าคุณทำงานกับปัญหาที่ไม่ได้อยู่ในสาขาที่มีสัญลักษณ์ที่ดีขึ้นหรือการพัฒนาที่ดีฉันจะเดิมพันความยากลำบากของการเขียนหลักฐานที่ถูกต้องวิธีการที่ยากลำบากในการเขียนโปรแกรมที่ถูกต้อง นี่อาจเป็นเพราะคุณยังต้องเขียนแบบอะนาล็อกของการออกแบบภาษาโปรแกรมฝึกเครือข่ายประสาทของคุณเพื่อคอมไพล์มันอย่างถูกต้องลองเขียนบทพิสูจน์ในเรื่องนั้นหมดหน่วยความจำหมดพยายามเพิ่มประสิทธิภาพของภาษา ย้ำสมองของคุณเรียนรู้ภาษาเขียนหลักฐานอีกครั้งเป็นต้น

เพื่อเน้นย้ำฉันคิดว่าการเขียนหลักฐานที่ถูกต้องสามารถเข้าถึงความยากลำบากในการเขียนโปรแกรมที่ถูกต้องในบางพื้นที่ของคณิตศาสตร์ แต่พื้นที่เหล่านั้นจำเป็นต้องมีเด็กและอยู่ภายใต้การพัฒนาเนื่องจากความคิดของความคืบหน้ามากในวิชาคณิตศาสตร์นั้น การตรวจสอบ

อีกวิธีในการใช้ถ้อยคำในจุดที่ฉันต้องการคือทั้งภาษาการเขียนโปรแกรมและคณิตศาสตร์ได้รับการออกแบบในตอนท้ายของวันเพื่อให้โปรแกรมคอมพิวเตอร์และการพิสูจน์ตามลำดับสามารถรวบรวมได้ เป็นเพียงการคอมไพล์โปรแกรมคอมพิวเตอร์ที่ทำในคอมพิวเตอร์และรับรองความถูกต้องทางวากยสัมพันธ์ซึ่งมักจะมีส่วนเกี่ยวข้องกับความถูกต้องของโปรแกรมในขณะที่ "รวบรวม" การพิสูจน์จะกระทำโดยมนุษย์และรับรองความถูกต้องทางไวยากรณ์ซึ่งเป็นสิ่งเดียวกัน ความถูกต้องของการพิสูจน์

คุณเปรียบเทียบแอปเปิ้ลกับส้มอย่างตรงไปตรงมา ข้อผิดพลาดและปราศจากข้อผิดพลาดไม่ใช่สิ่งเดียวกัน

หากโปรแกรมเปรียบเทียบตัวเลข2และมี3ข้อความระบุว่านั่น2 is greater than 3อาจเป็นเพราะการใช้งานบั๊กกี้:

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

โปรแกรมยังคงปราศจากข้อผิดพลาด เมื่อเปรียบเทียบตัวเลขสองตัวaและbจะสามารถบอกคุณได้ว่าbใหญ่กว่าaหรือไม่ ไม่ใช่สิ่งที่คุณ (โปรแกรมเมอร์) ควรจะขอให้คอมพิวเตอร์ทำ

a) เนื่องจากโปรแกรมคอมพิวเตอร์มีขนาดใหญ่กว่าการพิสูจน์ทางคณิตศาสตร์

a.1) ฉันเชื่อว่ามีผู้ใช้จำนวนมากในระหว่างการเขียนโปรแกรมคอมพิวเตอร์ที่ซับซ้อนมากกว่าการเขียนข้อพิสูจน์ทางคณิตศาสตร์ หมายความว่าความผิดพลาดนั้นสูงกว่า

b) เนื่องจากผู้บริหาร / ผู้ถือหุ้นให้ความสำคัญกับเรื่องเงินมากกว่าการแก้ไขข้อบกพร่องเล็ก ๆในขณะเดียวกันคุณ (ในฐานะนักพัฒนาซอฟต์แวร์) ต้องทำงานของคุณให้ตรงตามข้อกำหนด / กำหนดเวลา / การสาธิต

c) เนื่องจากคุณสามารถเป็นโปรแกรมเมอร์ที่ไม่มีความรู้ "เชิงลึก" ใน comp sci ในขณะเดียวกันก็ยากที่จะทำคณิตศาสตร์ (ฉันเชื่อ)

นอกจากนี้:

นาซ่า:

ซอฟต์แวร์นี้ไม่มีข้อบกพร่อง มันสมบูรณ์แบบสมบูรณ์แบบตามที่มนุษย์บรรลุ พิจารณาสถิติเหล่านี้: โปรแกรมสามเวอร์ชันสุดท้าย - ยาว 420,000 บรรทัด - มีข้อผิดพลาดเพียงข้อเดียว ซอฟต์แวร์รุ่น 11 ล่าสุดนี้มีข้อผิดพลาดทั้งหมด 17 ข้อ

ใช้การอัปเกรดซอฟต์แวร์เพื่ออนุญาตให้รถรับส่งนำทางด้วย Global Positioning Satellites การเปลี่ยนแปลงที่เกี่ยวข้องกับโปรแกรมเพียง 1.5% หรือรหัส 6,366 บรรทัด ข้อมูลจำเพาะสำหรับการเปลี่ยนแปลงหนึ่งครั้งนั้นมี 2,500 หน้าซึ่งเป็นปริมาณที่หนากว่าสมุดโทรศัพท์ ข้อกำหนดสำหรับโปรแกรมปัจจุบันเติม 30 วอลุ่มและรัน 40,000 หน้า

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

ระดับพื้นฐาน:

สำหรับคณิตศาสตร์เรามี:
2 + 3 = 5

ฉันเรียนรู้เกี่ยวกับสิ่งนั้นเมื่อฉันยังเด็กมาก ฉันสามารถดูองค์ประกอบพื้นฐานที่สุด: วัตถุสองชิ้นและวัตถุสามอย่าง ยิ่งใหญ่

สำหรับการเขียนโปรแกรมคอมพิวเตอร์คนส่วนใหญ่มักจะใช้ภาษาระดับสูง ภาษาระดับสูงบางภาษาสามารถ "คอมไพล์" เป็นภาษาระดับสูงด้านล่างอย่างใดอย่างหนึ่งเช่น C. C สามารถแปลเป็นภาษาแอสเซมบลี ภาษาแอสเซมบลีจะถูกแปลงเป็นรหัสเครื่อง ผู้คนจำนวนมากคิดว่าความซับซ้อนจบลงที่นั่น แต่ไม่ได้: ซีพียูสมัยใหม่ใช้รหัสเครื่องเป็นคำแนะนำ แต่จากนั้นเรียกใช้ "ไมโครโค้ด" เพื่อดำเนินการตามคำแนะนำเหล่านั้น

ซึ่งหมายความว่าในระดับพื้นฐานที่สุด (จัดการกับโครงสร้างที่ง่ายที่สุด) ตอนนี้เรากำลังจัดการกับไมโครโค้ดซึ่งฝังอยู่ในฮาร์ดแวร์และโปรแกรมเมอร์ส่วนใหญ่ไม่ได้ใช้โดยตรงหรืออัปเดต ในความเป็นจริงไม่เพียง แต่โปรแกรมเมอร์ส่วนใหญ่ไม่ได้สัมผัสรหัสไมโคร (0 ระดับสูงกว่าไมโครโค้ด) โปรแกรมเมอร์ส่วนใหญ่ไม่ได้สัมผัสรหัสเครื่อง (1 ระดับสูงกว่ารหัสไมโคร) หรือแม้แต่การประกอบ (2 ระดับสูงกว่ารหัสไมโคร) ยกเว้นบางทีสำหรับการฝึกอบรมอย่างเป็นทางการระหว่างวิทยาลัย) โปรแกรมเมอร์ส่วนใหญ่จะใช้เวลามากกว่า 3 ระดับขึ้นไป

ยิ่งกว่านั้นถ้าเราดูสมัชชา (ซึ่งอยู่ในระดับต่ำที่สุดเท่าที่คนทั่วไปจะได้รับ) แต่ละขั้นตอนจะเข้าใจได้ง่ายโดยผู้ที่ได้รับการฝึกอบรมและมีทรัพยากรในการตีความขั้นตอนนั้น ในแง่นี้การชุมนุมนั้นง่ายกว่าภาษาระดับสูงกว่ามาก อย่างไรก็ตามแอสเซมบลีนั้นง่ายมากที่การทำงานที่ซับซ้อนหรือแม้แต่งานที่ปานกลางนั้นน่าเบื่อมาก ภาษาระดับสูงเป็นอิสระจากเรา

ในกฎหมายเกี่ยวกับ "วิศวกรรมย้อนกลับ" ผู้พิพากษาประกาศว่าแม้ว่ารหัสในทางทฤษฎีสามารถได้รับการจัดการทีละครั้งโปรแกรมที่ทันสมัยเกี่ยวข้องกับหลายล้านไบต์ดังนั้นบางประเภทของระเบียน (เช่นสำเนาของรหัส) จะต้องทำเพียงเพื่อเช่นนี้ ความพยายามที่จะเป็นไปได้ (ดังนั้นการพัฒนาภายในไม่ถือว่าเป็นการละเมิดกฎหมาย "ไม่ทำสำเนา" โดยทั่วไป) (ฉันอาจกำลังคิดที่จะสร้างคาร์ทริดจ์ Sega Genesis ที่ไม่ได้รับอนุญาต แต่อาจจะนึกถึงบางอย่างที่พูดในระหว่างเกม Genie )

ทันสมัย:

คุณเรียกใช้รหัสที่มีความหมายสำหรับ 286s หรือไม่? หรือคุณเรียกใช้รหัส 64 บิต

วิชาคณิตศาสตร์ใช้พื้นฐานที่ยืดเยื้อมานับพันปี ด้วยคอมพิวเตอร์ผู้คนมักจะพิจารณาการลงทุนในสิ่งที่มีอายุสองทศวรรษเพื่อให้สิ้นเปลืองทรัพยากรอย่างไร้ประโยชน์ นั่นหมายความว่าคณิตศาสตร์สามารถทดสอบได้อย่างละเอียดมากขึ้น

มาตรฐานของเครื่องมือที่ใช้แล้ว:

ฉันถูกสอน (โดยเพื่อนที่มีการฝึกอบรมการเขียนโปรแกรมคอมพิวเตอร์เป็นทางการมากกว่าตัวฉันเอง) ว่าไม่มีสิ่งเช่นคอมไพเลอร์ C ที่ไม่มีข้อบกพร่องที่ตรงตามข้อกำหนดของ C นี่เป็นเพราะภาษา C โดยทั่วไปถือว่าความเป็นไปได้ของการใช้หน่วยความจำที่ไม่มีที่สิ้นสุดสำหรับจุดประสงค์ของสแต็ค เห็นได้ชัดว่าความต้องการที่เป็นไปไม่ได้นั้นต้องเบี่ยงเบนไปจากเมื่อผู้คนพยายามทำให้คอมไพเลอร์ที่ใช้งานได้ซึ่งทำงานกับเครื่องจักรจริงที่ค่อนข้าง จำกัด ในธรรมชาติ

ในทางปฏิบัติฉันได้พบว่าเมื่อใช้ JScript ใน Windows Script Host ฉันสามารถใช้วัตถุต่าง ๆ ได้สำเร็จ (ฉันชอบสภาพแวดล้อมเพราะชุดเครื่องมือที่จำเป็นในการลองใช้รหัสใหม่ถูกสร้างขึ้นใน Microsoft Windows รุ่นที่ทันสมัย) เมื่อใช้สภาพแวดล้อมนี้ฉันพบว่าบางครั้งไม่มีเอกสารที่ค้นหาได้ง่ายเกี่ยวกับวิธีการทำงานของวัตถุ อย่างไรก็ตามการใช้วัตถุนั้นมีประโยชน์มาก ดังนั้นสิ่งที่ฉันจะทำคือเขียนรหัสซึ่งอาจเป็นรถม้าชนิดเล็กเป็นรังของแตนและทำในสภาพแวดล้อมที่เป็นทรายที่ฉันสามารถเห็นผลกระทบและเรียนรู้เกี่ยวกับพฤติกรรมของวัตถุในขณะที่โต้ตอบกับมัน

ในบางกรณีบางครั้งหลังจากที่ฉันทราบว่าวัตถุทำงานอย่างไรฉันได้พบว่าวัตถุ (ที่รวมอยู่กับระบบปฏิบัติการ) นั้นเป็นรถและเป็นปัญหาที่ทราบว่า Microsoft ตัดสินใจโดยเจตนาจะไม่ได้รับการแก้ไข .

ในสถานการณ์เช่นนี้ฉันต้องพึ่งพา OpenBSD ซึ่งสร้างโดยโปรแกรมเมอร์ผู้ชำนาญที่สร้างการเผยแพร่ใหม่ตามกำหนดเวลาเป็นประจำ (ปีละสองครั้ง) ด้วยสถิติความปลอดภัยที่โด่งดังของ (แม้ว่าพวกเขาจะมีโปรแกรมแก้ไขข้อผิดพลาดสำหรับปัญหาที่รุนแรงน้อยกว่า) ไม่เลย ฉันไม่พึ่งพาผลิตภัณฑ์ดังกล่าวที่มีคุณภาพสูงกว่านี้เพราะฉันทำงานให้กับธุรกิจที่สนับสนุนธุรกิจที่จัดหาคนที่มีเครื่องที่ใช้ Microsoft Windows ดังนั้นนี่คือสิ่งที่รหัสของฉันต้องใช้ในการทำงาน

การปฏิบัติจริง / การใช้งานต้องการให้ฉันทำงานบนแพลตฟอร์มที่ผู้คนพบว่ามีประโยชน์และเป็นแพลตฟอร์มที่มีชื่อเสียงที่ไม่ดีต่อความปลอดภัย (แม้ว่าจะมีการปรับปรุงอย่างมากตั้งแต่ต้นยุคสหัสวรรษซึ่งผลิตภัณฑ์ของ บริษัท เดียวกันนั้นแย่กว่ามาก) .

สรุป

มีสาเหตุหลายประการที่ทำให้การเขียนโปรแกรมคอมพิวเตอร์เกิดข้อผิดพลาดได้ง่ายขึ้นและเป็นที่ยอมรับของชุมชนผู้ใช้คอมพิวเตอร์ ในความเป็นจริงรหัสส่วนใหญ่จะเขียนในสภาพแวดล้อมที่จะไม่ยอมให้มีความพยายามปราศจากข้อผิดพลาด (ข้อยกเว้นบางประการเช่นการพัฒนาโปรโตคอลความปลอดภัยอาจได้รับความพยายามเพิ่มขึ้นเล็กน้อยในเรื่องนี้) นอกจากความคิดทั่วไปเกี่ยวกับเหตุผลของธุรกิจที่ไม่ต้องการลงทุนเงินมากขึ้นและพลาดกำหนดเวลาประดิษฐ์เพื่อทำให้ลูกค้ามีความสุข มีนาคมของเทคโนโลยีที่ระบุว่าถ้าคุณใช้เวลามากเกินไปคุณจะทำงานบนแพลตฟอร์มที่ล้าสมัยเพราะสิ่งต่าง ๆ มีการเปลี่ยนแปลงอย่างมีนัยสำคัญภายในหนึ่งทศวรรษ

โดยเฉพาะฉันสามารถจำได้ว่ารู้สึกประหลาดใจแค่ไหนที่ฟังก์ชั่นที่มีประโยชน์และได้รับความนิยมนั้นสั้นมากเมื่อฉันเห็นซอร์สโค้ดของ strlen และ strcpy ตัวอย่างเช่น strlen อาจเป็นอะไรบางอย่างเช่น "int strlen (char * x) {char y = x; ในขณะที่ (y ++)); return (yx) -1;}"

อย่างไรก็ตามโปรแกรมคอมพิวเตอร์ทั่วไปนั้นยาวกว่านั้นมาก นอกจากนี้การเขียนโปรแกรมที่ทันสมัยจำนวนมากจะใช้รหัสอื่นซึ่งอาจมีการทดสอบอย่างละเอียดน้อยกว่าหรือรู้จักกันในชื่อ buggy ระบบของวันนี้มีความซับซ้อนมากกว่าสิ่งที่คิดได้อย่างง่ายดายยกเว้นด้วยการโบกมือให้ผู้คนจำนวนมากในขณะที่ "รายละเอียดจัดการโดยระดับที่ต่ำกว่า"

ความซับซ้อนที่จำเป็นนี้และความแน่นอนของการทำงานกับระบบที่ซับซ้อนและไม่ถูกต้องทำให้การเขียนโปรแกรมคอมพิวเตอร์เป็นฮาร์ดแวร์จำนวนมากเพื่อตรวจสอบมากกว่าคณิตศาสตร์จำนวนมากที่สิ่งต่าง ๆ มีแนวโน้มที่จะต้มลงไปในระดับที่ง่ายกว่ามาก

เมื่อคุณทำลายสิ่งต่าง ๆ ในวิชาคณิตศาสตร์คุณจะได้ชิ้นส่วนที่เด็ก ๆ สามารถเข้าใจได้ คนส่วนใหญ่เชื่อถือคณิตศาสตร์ อย่างน้อยเลขคณิตพื้นฐาน (หรืออย่างน้อยก็นับ)

เมื่อคุณสลายการเขียนโปรแกรมคอมพิวเตอร์จริงๆเพื่อดูว่าเกิดอะไรขึ้นภายใต้ประทุนคุณจะจบลงด้วยการใช้งานที่ไม่สมบูรณ์ของมาตรฐานและรหัสที่ใช้งานไม่ได้ซึ่งจะถูกดำเนินการทางอิเล็กทรอนิกส์ในที่สุดและการใช้งานทางกายภาพนั้น ไม่กล้าแตะต้อง (ถ้าพวกเขารู้เรื่องนี้ด้วย)

ฉันได้พูดคุยกับโปรแกรมเมอร์บางคนที่อยู่ในวิทยาลัยหรือผู้สำเร็จการศึกษาเมื่อเร็ว ๆ นี้ซึ่งคัดค้านความคิดที่ว่าโค้ดปราศจากข้อบกพร่องสามารถเขียนได้ พวกเขาได้เขียนถึงความเป็นไปได้และแม้ว่าพวกเขายอมรับว่าตัวอย่างที่น่าประทับใจ (ซึ่งฉันสามารถแสดงได้) เป็นข้อโต้แย้งที่น่าเชื่อพวกเขาถือว่าตัวอย่างเหล่านี้เป็น flukes ที่หายากซึ่งไม่ได้เป็นตัวแทนและยังคงยกเลิกโอกาส ในการมีมาตรฐานที่สูงขึ้นดังกล่าว (ทัศนคติที่แตกต่างกันมากกว่ารากฐานที่ไว้วางใจได้มากที่เราเห็นในคณิตศาสตร์)

หลักฐานทางคณิตศาสตร์อธิบาย "ความรู้" และโปรแกรมอธิบายถึง "ความรู้" ได้อย่างไร

โปรแกรมการเขียนมีความซับซ้อนมากขึ้นเนื่องจากโปรแกรมเมอร์ต้องให้เหตุผลเกี่ยวกับสถานะที่แตกต่างกันทั้งหมดที่สามารถเกิดขึ้นได้และพฤติกรรมของโปรแกรมจะเปลี่ยนแปลงไปอย่างไร การพิสูจน์ใช้การกำหนดเหตุผลเชิงสูตรหรือการจัดหมวดหมู่เพื่อพิสูจน์สิ่งต่าง ๆ เกี่ยวกับคำจำกัดความอื่น ๆ

ข้อบกพร่องส่วนใหญ่เกิดจากกระบวนการที่เข้าสู่สภาวะที่โปรแกรมเมอร์ไม่คาดการณ์ ในโปรแกรมคุณมักจะมีหลายพันหรือในระบบขนาดใหญ่ตัวแปรที่เป็นไปได้หลายล้านตัวซึ่งไม่ใช่ข้อมูลแบบสแตติก แต่จริง ๆ แล้วเปลี่ยนวิธีที่โปรแกรมดำเนินการ การโต้ตอบทั้งหมดนี้เข้าด้วยกันจะสร้างพฤติกรรมที่เป็นไปไม่ได้โดยเฉพาะอย่างยิ่งในคอมพิวเตอร์ยุคใหม่ที่มีการเปลี่ยนแปลงของสิ่งที่เป็นนามธรรมอยู่ใต้คุณ

ในการพิสูจน์ไม่มีสถานะที่เปลี่ยนแปลง คำจำกัดความและวัตถุของการสนทนาได้รับการแก้ไข การพิสูจน์ต้องใช้ความคิดเกี่ยวกับปัญหาโดยทั่วไปและพิจารณาหลายกรณี แต่กรณีเหล่านั้นได้รับการแก้ไขโดยคำจำกัดความ