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


190

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

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

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

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

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

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

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

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

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

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

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

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

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


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

76
เตือนฉันถึงคำพูดของ Knuth ฉันคิดว่า "ระวังรหัสข้างต้น! ฉันพิสูจน์แล้วว่าถูกต้องฉันไม่เคยทดสอบเลย"
Hagen von Eitzen

ความคิดเห็นไม่ได้มีไว้สำหรับการอภิปรายเพิ่มเติม การสนทนานี้ได้รับการย้ายไปแชท
Gilles

7
พบหลักฐานทางคณิตศาสตร์ที่เขียนด้วยมือที่มีความยาว 100 ล้านบรรทัดและไม่มี "บั๊ก" และฉันจะมอบทุกอย่างให้ฉัน
Davor

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

คำตอบ:


226

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

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

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 อย่างเป็นทางการและต่อจากนี้ไปใช้คอมพิวเตอร์ในการตรวจสอบทุกการทำงานต่อมา (อย่างน้อยตามที่ตัวเขาเอง ค่าเข้าชม) แม้ว่านี่จะเป็นตำแหน่งที่รุนแรง (และในปัจจุบันไม่สามารถใช้งานได้) แต่ก็ยังเป็นกรณีที่เมื่อใช้ผลลัพธ์เราควรจะไปพิสูจน์และตรวจสอบว่ามันถูกต้องหรือไม่ ในพื้นที่ของฉันมีเอกสารสองสามฉบับที่ทราบกันว่าผิด แต่ไม่เคยหดกลับคืนซึ่งสถานะถูกถ่ายทอดจากปากหนึ่งถึงหูท่ามกลางผู้เชี่ยวชาญ


ความคิดเห็นไม่ได้มีไว้สำหรับการอภิปรายเพิ่มเติม การสนทนานี้ได้รับการย้ายไปแชท
DW

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

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

2
@svick คุณพูดถูกสำหรับการโต้ตอบกับผู้ใช้บางครั้งอาจไม่ชัดเจนว่าพฤติกรรมที่เหมาะสมควรทำอย่างไร ดังนั้นเราจึงควรให้ความสำคัญกับสิ่งที่มีคุณสมบัติเป็นทางการที่เหมาะสม (เช่นการพิสูจน์คอมไพเลอร์)
อเล็กซ์ Vong

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

77

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

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

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

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


3
ประเด็นที่เกี่ยวกับ "การใช้รหัสซ้ำ" นั้นค่อนข้างมีประโยชน์ แปลหลักฐานยาวจากรัสเซียเป็นภาษาอังกฤษจะใช้เวลาค่อนข้างมากของการพิมพ์ ; แต่แปลโปรแกรมคอมพิวเตอร์ที่มีขนาดใหญ่จากสมมติว่า, C ++ เข้า Java จะใช้เวลาค่อนข้างมากของความคิด นอกจากนี้การฟื้นคืนชีพหลักฐาน 3000 ปีในภาษากรีกโบราณก็เป็นเรื่องง่ายเช่นกัน การเรียกคืนโปรแกรมอายุ 30 ปีใน PL / 1 เป็นเรื่องยากหรือยากขึ้น
Quuxplusone

2
ตัวอย่างกรีกโบราณยังทำให้ฉันรู้: การเขียนโปรแกรมคอมพิวเตอร์ใช้ตันของแสลงท้องถิ่นและ colloquialisms เช่น(void*)1และopen('/dev/null')ซึ่งอาจไม่ได้เป็นแบบพกพาระหว่างวัฒนธรรมที่แตกต่างกันให้อยู่คนเดียวที่แปลเป็นภาษาปลายทาง (ผู้อ่านเพียงแค่ต้องเซาะความหมายโดยประมาณของพวกเขาโดยอาศัยประสบการณ์อันยาวนาน) ฉันคิดว่าบทพิสูจน์ทางคณิตศาสตร์มีคำสแลงประเภทนี้น้อยกว่า หากการพิสูจน์ใช้คำความหมายสากลที่แท้จริงของมันควรจะเป็นข้อสรุปโดยผู้อ่านอย่างใด โปรแกรมคอมพิวเตอร์ที่ไม่ได้มีความหมายสากล!
Quuxplusone

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

@Nat คุณสามารถทำอย่างละเอียด? ฉันไม่เข้าใจ
Gregory Magarshak

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

55

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

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

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

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

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

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

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

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

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


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


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

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

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


2
ฉันเป็นคนธรรมดา Dijkstra หมายถึงอะไรโดย "การเขียนโปรแกรม"
Ovi

2
@Ovi ฉันไม่แน่ใจอย่างแน่นอน แต่ความแตกต่างที่สำคัญคือเขาพูดถึงปัญหาอัลกอริทึม (ไม่ใช่เรื่องไม่สำคัญ) ในการแก้ปัญหามากกว่าการเขียนโปรแกรม 'ทั่วไป' นั่นคือแน่นอนว่าเขาไม่ได้พูดถึงโปรแกรม CRUD ที่ต้องการเชื่อมต่อบางอย่าง สถาปัตยกรรมที่มีอยู่หรือส่วนประกอบอื่น ๆ อื่น ๆ เพิ่มเติมเกี่ยวกับความเห็นของ Dijkstra เกี่ยวกับการเขียนโปรแกรมสามารถดูได้ในคำตอบนี้
Discrete lizard

3
โหวตขึ้นโหวตจาก Dijkstra แต่คุณเลือกที่ผิด! เขาได้เขียนเกี่ยวกับปัญหานี้มากในย่อหน้าแรกของการเขียนโปรแกรมแบบโครงสร้าง ฉันไม่ต้องการเปลี่ยนคำตอบของคุณโดยส่งใบเสนอราคาที่ต่างออกไป แต่ฉันหวังว่าคุณน่าจะเพิ่มคำตอบของคุณในบทความนี้!
wvxvw

@Ovi ฉันเดาคำถามของคุณคือการเขียนโปรแกรมในเวลา Dijkstra หมายถึงการเขียนรหัสการประกอบกับยุคที่ทันสมัยของภาษาระดับสูง ในทำนองเดียวกันฉันกำลังอ่าน Mythical Man-Month ฉบับปี 1974 แนวคิดยังคงเป็นปัจจุบัน แต่การอ้างอิงทางเทคนิคคือแอสเซมเบลอร์ระดับระบบหรือ PL / I ซึ่งแตกต่างจากสิ่งที่คนส่วนใหญ่คิดว่าการเขียนโปรแกรมในวันนี้
JimLohse

46

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

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

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


6
บทความเดียวกัน: "หลักฐานพอสมควรแสดงให้เห็นว่ามากถึงหนึ่งในสามของเอกสารทั้งหมดที่ตีพิมพ์ในวารสารคณิตศาสตร์มีข้อผิดพลาด - ไม่ใช่แค่ข้อผิดพลาดเล็กน้อย แต่เป็นทฤษฎีและบทพิสูจน์ที่ไม่ถูกต้อง" นั่นคือใน 90 แต่วันนี้มันแตกต่างกันหรือไม่? น่าจะเป็นเอกสารเหล่านั้นที่มีอยู่ในสมัยนั้นยังคงมีอยู่และทุกสิ่งทุกอย่างทวีขึ้น ... ดังนั้นฉันไม่เชื่ออย่างเต็มที่ว่าหลักฐานทางคณิตศาสตร์ที่ให้ไว้ในเอกสารมีข้อผิดพลาดน้อยลง
MarkokraM

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

@DW ฉันส่งข้อความอีเมลไปที่ Leslie ถ้าเขาสามารถให้หลักฐานเพิ่มเติมสำหรับการเรียกร้อง
MarkokraM

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

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

39

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

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

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


14
+1 สำหรับย่อหน้าสุดท้ายของคุณ ในขณะที่การพิสูจน์ทางคณิตศาสตร์อยู่ในหลักการที่สร้างขึ้นมาจากคนอื่นโดยปกติแล้วพื้นฐานที่เป็นที่เข้าใจกันดีแล้วคอมพิวเตอร์ห้องสมุด (แม้ว่าพวกเขาจะยังมีข้อบกพร่อง ... ) และหลักฐานที่แท้จริงไม่นานเกินไป ในทางตรงกันข้ามซอฟต์แวร์สำหรับผู้บริโภคนั้นมีความยาวและซับซ้อนและมีโอกาสมากมายที่จะล้มเหลว
Yuval Filmus

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

2
@DanBryant สถานการณ์นั้นเกิดขึ้นในวิชาคณิตศาสตร์ โดยเฉพาะคำจำกัดความของคำศัพท์จะเปลี่ยนไปตามกาลเวลาและมักจะคลุมเครือแม้จะถูกใช้ "หลักฐานและการหักล้าง" ของ Imre Lakatos อธิบายสิ่งนี้ด้วยคำว่า "รูปหลายเหลี่ยม" สิ่งที่คล้ายกันเกิดขึ้นกับ "ฟังก์ชั่น" และในระดับที่น้อยกว่า "อินทิกรัล" แม้กระทั่งทุกวันนี้ "หมวดหมู่" ก็ไม่ได้คลุมเครือและสามารถพิสูจน์ได้และทฤษฏีล้มเหลวขึ้นอยู่กับว่าคุณหมายถึงอะไร
Derek Elkins

25

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

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

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

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

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

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

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


3
คำตอบที่ดี! ยกเว้นว่าในคอมพิวเตอร์ฉันคัดค้านการใช้คำว่า "ไม่จำเป็น" ;) [สมมติว่านี่เป็นเพียงขั้นตอนเดียวในการพิสูจน์ขนาดใหญ่ที่มีจุดประสงค์เพื่อพิสูจน์ว่า-xเป็นแบบประกอบ ความจริงที่ว่าขั้นตอนนี้ผิดเมื่อ-x = 3มีความเกี่ยวข้องอย่างมากกับความถูกต้องของการพิสูจน์ที่สมบูรณ์!]
Quuxplusone

@Quuxplusone: = P
Mehrdad

คอมพิวเตอร์สามารถใช้คณิตศาสตร์เชิงสัญลักษณ์และกฎการเขียนซ้ำที่ไม่ได้กำหนดได้เช่นกันเพียงว่าภาษาที่เราใช้เช่น C ++ นั้นอยู่ในระดับที่ต่ำมากและใช้เทคโนโลยีโบราณ (C มีคุณสมบัติน้อยกว่า Algol 60 เป็นต้น) ข้อยกเว้นเพียงอย่างเดียวคือภาษาพิสูจน์ / ตรวจสอบเช่น Idris / Agda, Lisp พร้อมตัวแก้สัญลักษณ์และ Mathematica ja.wolframalpha.com/input/…
aoeu256

23

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

nn!

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

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


18

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

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

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

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

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

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

อาจคุ้มค่าที่จะกล่าวถึงว่าการเทียบเท่า 'indempotency' ของโปรแกรมนั้นเป็นความบริสุทธิ์ของฟังก์ชันซึ่งได้รับการยอมรับและสนับสนุนในบางภาษาเช่น Haskell
Pharap

12

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

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

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

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

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

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

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

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


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

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

11

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

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

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

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

ให้ c = a + b

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

ให้ a = input ();

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

ให้ c = a + b;

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

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

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


10

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

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

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


7

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

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

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

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

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


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

ป้อนคำอธิบายรูปภาพที่นี่


4

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

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

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

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


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

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

4

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

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

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

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

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

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


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

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

3

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

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

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


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

3

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

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

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

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

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


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

ฉันรู้ว่ามันค่อนข้างลึกซึ้งสำหรับ C หรือสิ่งที่คล้ายกัน แต่ประเด็นของฉันคือ: คณิตศาสตร์อยู่ใกล้กว่าผู้เริ่มต้น CS ทั่วไปอาจคิดว่า!
Oleg Lobachev

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

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

3

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

π


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

1
@Discretelizard ใช่มีแพ็คเกจพิเศษที่มีความแม่นยำตามอำเภอใจ แต่ถึงกระนั้นหน่วยความจำที่มีอยู่ก็จะจำกัดความแม่นยำที่ทำได้จริง พวกเขายังเป็นแพ็คเกจพิเศษ มีการเขียนโปรแกรมเพียงเล็กน้อยเท่านั้นด้วยแพ็คเกจดังกล่าวและส่วนใหญ่อยู่ในสภาพแวดล้อมทางวิชาการ
crobar

π

@Discretelizard ฉันคิดว่าจุดของฉันยังคงยืนอยู่โปรแกรมเมอร์ส่วนใหญ่ไม่ได้ใช้ระบบ CAS ดังกล่าว มันช้าเกินไปสำหรับการเขียนโปรแกรมในโลกแห่งความเป็นจริง การเขียนโปรแกรมส่วนใหญ่นั้นเกี่ยวข้องกับการดำเนินการกับตัวเลขที่แม่นยำ ภาษายอดนิยมคือ C, C ++, Python, Java เป็นต้นไม่มีการใช้การแทนค่าลักษณะของ CAS ตามค่าเริ่มต้น (แม้ว่าจะมีการสร้างแพ็คเกจเพื่อทำสิ่งนี้) ตัวอย่างตัวอย่างของคุณเป็นส่วนย่อยเล็ก ๆ ของภาษา / ระบบคอมพิวเตอร์
crobar

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

3

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

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

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

ป้อนคำอธิบายรูปภาพที่นี่

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

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

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

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


3

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

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

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


3

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

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

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


3

ฉันไม่พบข้อมูลอ้างอิง แต่ฉันคิดว่า 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)

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

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


2

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

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

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


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

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

@DW: คุณกำลังสมมติว่า (1) พฤติกรรมที่ต้องการสามารถระบุได้อย่างสมบูรณ์ในทุกกรณี (2) มีการพิสูจน์ที่จำเป็น (เช่นปัญหาไม่สามารถอธิบายได้) และ (3) หากการพิสูจน์มีอยู่เรา สามารถค้นหาได้ ฉันคิดว่าสมมติฐานทั้งสามข้อนี้เป็นเท็จในบางกรณี (อาจเป็นได้เกือบทุกกรณี) Re 3 โปรดทราบว่าถึงแม้ว่าหลักฐานบางอย่างอาจง่าย แต่มีหลายหลักฐานที่หายาก
Ben Crowell

@DerekElkins: การอ้างสิทธิ์ของฉันที่มีนักศึกษาเพียงไม่กี่คนที่สามารถเขียนได้แม้หลักฐานอันไม่สำคัญนั้นขึ้นอยู่กับประสบการณ์ของฉันกับนักเรียนของฉัน นี่เป็นวิทยาลัยชุมชนดังนั้น YMMV ความจริงที่ว่าชั้นเรียนเรขาคณิตของโรงเรียนมัธยมบางแห่งมีการเขียนพิสูจน์จำนวนมากไม่ได้แปลความจริงที่ว่านักศึกษาวิทยาลัยทุกคนสามารถเขียนบทพิสูจน์ได้ พวกเขาควรรู้ด้วยว่าจะต้องทำพีชคณิตพื้นฐานได้อย่างไร แต่ที่โรงเรียนของฉันนักเรียนชั้นปีที่ 1 คิดไม่ถึงครึ่งซึ่งไม่สามารถช่วยอธิบายได้ว่าทำไมจึงล้มเหลวมากมาย
Ben Crowell

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

2

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

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


1
"มีเพียงส่วนน้อยของข้อความทางคณิตศาสตร์ที่เป็นจริงซึ่งสามารถพิสูจน์ได้จริง" - คุณวัด "ส่วน" อย่างไร สิ่งนี้อยู่ภายใต้การแจกแจงความน่าจะเป็นหรือไม่? คุณมีหลักฐานสนับสนุนข้อความนี้หรือไม่?
DW

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

@DW: หาก X และ Y เป็นข้อความมุมฉากที่เป็นจริง แต่ไม่สามารถพิสูจน์ได้ดังนั้นสำหรับทุกข้อความที่พิสูจน์ได้ P จะมีข้อความอย่างน้อยสองประโยค (P และ X) และ (P และ Y) ซึ่งเป็นจริง แต่ไม่ใช่ -provable เมื่อต้องรับมือกับเซตที่ไม่มีที่สิ้นสุดตรรกะดังกล่าวไม่จำเป็นต้องพิสูจน์อะไรเลยตั้งแต่หนึ่งสามารถใช้ตรรกะที่คล้ายกันเพื่อแสดงว่ามีจำนวนเต็มสองเท่าเป็นจำนวนเต็มเป็นเลขคี่เนื่องจากสำหรับทุกเลขจำนวนเต็มคี่สามารถระบุจำนวนเต็มสองคู่ได้ (4x + 2) ที่ไม่ได้เชื่อมโยงกับเลขจำนวนเต็มคี่อื่น ๆ แต่แน่นอนว่าเลขจำนวนเต็มคู่และเลขคี่นั้นมีความสำคัญเท่ากับ
supercat

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

... เพื่อกำหนดความน่าจะเป็นของการรวมกันของความล้มเหลวที่แตกต่างกัน ถ้าใครประมาณความน่าจะเป็นที่จะเกิดความล้มเหลวในช่วงระยะเวลาหนึ่งนาทีตามอำเภอใจให้เป็นหนึ่งใน 10 ^ -500 คนหนึ่งอาจจะถูกยกเลิกด้วยคำสั่งหลายร้อยแห่งและยังคงมีระบบที่เชื่อถือได้ ระบบจะล้มเหลวประมาณสองสามครั้งทุกปี
supercat

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

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

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

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


2

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

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

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

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

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

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


1

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

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

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

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


2
คำจำกัดความของคุณของ "ความผิดปกติ" ในโปรแกรมคืออะไร?
user56834

0

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


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

@ DavidRicherby ดีฉันมีในใจเช่นทฤษฎีบท Last แฟร์มาต์และ Apollo github.com/chrislgarry/Apollo-11 math.wisc.edu/~boston/869.pdf ของ NASA และเรายังไม่ได้พูดถึงระบบปฏิบัติการและอื่น ๆ
Exeus

0

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

ลองดูสิ่งต่าง ๆ ในระดับที่ง่ายที่สุดและพื้นฐานที่สุด

สำหรับคณิตศาสตร์เรามี:
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 ที่หายากซึ่งไม่ได้เป็นตัวแทนและยังคงยกเลิกโอกาส ในการมีมาตรฐานที่สูงขึ้นดังกล่าว (ทัศนคติที่แตกต่างกันมากกว่ารากฐานที่ไว้วางใจได้มากที่เราเห็นในคณิตศาสตร์)


1
ในขณะที่คุณทำกรณีที่ดีสำหรับความซับซ้อนของการเขียนโปรแกรมคุณแทบจะไม่พิจารณาคณิตศาสตร์เลย! ในความเป็นจริงคุณดูถูกดูแคลนความซับซ้อนที่เกี่ยวข้องในคณิตศาสตร์อย่างเป็นทางการ: "เมื่อคุณทำลายสิ่งต่าง ๆ ในวิชาคณิตศาสตร์คุณจะได้ชิ้นส่วนที่เด็ก ๆ สามารถเข้าใจได้" จริงเหรอ? นอกจากนี้ยังสามารถพูดได้เหมือนกันเกี่ยวกับการเขียนโปรแกรม 'ระดับสูง' อย่างเพียงพอ (เช่น Scratch ถูกออกแบบมาสำหรับเด็ก) โปรดทราบว่าถึงแม้ว่า C-spec แบบเต็มจะไม่สามารถใช้งานได้คอมไพเลอร์ที่สนับสนุนชุดย่อยที่สำคัญได้รับการแสดงอย่างเป็นทางการโดยใช้การพิสูจน์ด้วยคอมพิวเตอร์
จิ้งจกไม่ต่อเนื่อง

2+3=5

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

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

0

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

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

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

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


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

@Discretelizard นี่คือความคิดเห็นที่เป็นประโยชน์ ฉันคิดว่าเส้นแบ่งระหว่าง "อะไร" และ "วิธีการ" นั้นคลุมเครืออย่างแน่นอน การพิสูจน์อัลกอริทึมทำในสิ่งที่คุณคิดว่าจริง ๆ แล้วไม่ได้อธิบาย "วิธีการ" ในใจของฉันมันเป็นเพียงการรับประกันคุณสมบัติบางอย่างไว้ จากมุมมองทางปรัชญาฉันคิดว่า "วิธีการ" ความรู้ต้องมีการโต้ตอบกับโลก โปรแกรมจะทำสิ่งที่คุณบอกพวกเขาเสมอ เมื่อคุณมีข้อผิดพลาดสิ่งที่คุณบอกให้ทำไม่สอดคล้องกับโลก (สิ่งที่คุณกำลังสร้างแบบจำลอง) คณิตศาสตร์ซึ่งเป็นอิสระจากแอปพลิเคชัน (เช่นปัญหาทางฟิสิกส์) ดูเหมือนจะขึ้นอยู่กับการเชื่อมโยงกัน
Justin Meiners
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.