มีส่วนย่อยของโปรแกรมที่หลีกเลี่ยงปัญหาการหยุดชะงักหรือไม่

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

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

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

การอ่านจากอินพุตมาตรฐานเป็นตัวอย่างจะต้องถูก จำกัด แต่ก็ง่ายพอ - ฉันจะ จำกัด การป้อนข้อมูลของฉันเหลือ 10,000,000 ตัวอักษรขึ้นอยู่กับโดเมนปัญหา

TIA

[Update]

หลังจากอ่านความคิดเห็นและคำตอบบางทีฉันควรทบทวนคำถามอีกครั้ง

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

[อัพเดท 2]

นี่คือคำตอบคือใช่ย้อนกลับไปในปี 1967 จากhttp://www.isp.uni-luebeck.de/kps07/files/papers/kirner.pdf

ปัญหาการหยุดชะงักอย่างน้อยในทางทฤษฎีสามารถแก้ไขได้สำหรับระบบ fi nite-state ได้รับการถกเถียงกันโดย Minsky ในปี 1967 [4]: ​​"... เครื่อง ite nite-state ใด ๆ หากปล่อยให้ตัวเองสมบูรณ์ รูปแบบซ้ำ ๆ ระยะเวลาของรูปแบบการทำซ้ำนี้ต้องไม่เกินจำนวนสถานะภายในของเครื่อง ... "

(และถ้าคุณติดกับเครื่องจักรทัวริง จำกัด คุณสามารถสร้าง oracle ได้)

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

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

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

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

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

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

ผมขอแนะนำให้คุณอ่านGödel, Escher โสด มันเป็นหนังสือที่สนุกและให้ความกระจ่างซึ่งเหนือสิ่งอื่นใดที่สัมผัสกับทฤษฎีบทที่ไม่สมบูรณ์ของGödelและปัญหาการหยุดชะงัก

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

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

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

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

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

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

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

ประการที่สองคุณต้องระวังความหมายของ 'อินพุตมากที่สุด' หมายความว่าความน่าจะเป็นที่โปรแกรมสุ่มของ 'ความยาว' n สามารถตรวจสอบได้โดยอัลกอริทึมนี้มีแนวโน้มที่ 1 เนื่องจาก n มีแนวโน้มที่จะไม่มีที่สิ้นสุด กล่าวอีกนัยหนึ่งถ้า n มีขนาดใหญ่พอโปรแกรมแบบสุ่มที่มีความยาว n สามารถตรวจสอบได้ด้วยอัลกอริทึมนี้

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

แม้ว่าโปรแกรมเกือบทั้งหมดสามารถตรวจสอบได้ด้วยวิธีนี้ แต่ไม่มีโปรแกรมใดที่สามารถตรวจสอบด้วยวิธีนี้มีความน่าสนใจมากและโดยทั่วไปจะไม่ได้รับการออกแบบโดยมนุษย์ดังนั้นนี่จึงไม่มีคุณค่าในทางปฏิบัติใด ๆ

นอกจากนี้ยังระบุว่าความซับซ้อนของกรณีทั่วไปอาจไม่สามารถช่วยเราได้ในปัญหาการหยุดชะงักเนื่องจากโปรแกรมที่น่าสนใจเกือบทั้งหมดตรวจสอบได้ยาก หรืออีกนัยหนึ่งคือเกือบทุกโปรแกรมไม่มีความน่าสนใจ แต่ง่ายต่อการตรวจสอบ

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

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

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

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

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

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

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

นี่คือคำตอบคือใช่ย้อนกลับไปในปี 1967 จากhttp://www.isp.uni-luebeck.de/kps07/files/papers/kirner.pdf

ปัญหาการหยุดชะงักอย่างน้อยในทางทฤษฎีสามารถแก้ไขได้สำหรับระบบ fi nite-state ได้รับการถกเถียงกันโดย Minsky ในปี 1967 [4]: ​​"... เครื่อง ite nite-state ใด ๆ หากปล่อยให้ตัวเองสมบูรณ์ รูปแบบซ้ำ ๆ ระยะเวลาของรูปแบบการทำซ้ำนี้ต้องไม่เกินจำนวนสถานะภายในของเครื่อง ... "

(และถ้าคุณติดกับเครื่องจักรทัวริง จำกัด คุณสามารถสร้าง oracle ได้)

แน่นอนว่าต้องใช้เวลานานเท่าไรจึงจะเป็นอีกคำถามหนึ่ง

มีชุดย่อยของโปรแกรมที่สามารถกำหนดได้หากพวกเขาหยุด?

ใช่.

มันดีพอสำหรับโปรแกรมส่วนใหญ่หรือไม่?

กำหนด "มากที่สุด"

ฉันสามารถสร้างชุดภาษาสร้างที่ฉันสามารถกำหนด 'haltability' ของโปรแกรมได้หรือไม่

ใช่.

มีสิ่งที่เกือบทัวริงสมบูรณ์ซึ่งดีพอหรือไม่

กำหนด "เกือบ"

หลายคนเขียน Python โดยไม่ต้องใช้whileคำสั่งหรือเรียกซ้ำ

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

มันค่อนข้างง่ายที่จะหลีกเลี่ยงwhileและเรียกซ้ำ

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

เลขที่

ถ้าเป็นเช่นนั้นข้อ จำกัด ของภาษาคืออะไรและอะไรคือข้อ จำกัด ของชุดอินพุต

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

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

การขยายระบบพิสูจน์ง่ายกว่าการ จำกัด ภาษา ข้อ จำกัด ใด ๆ นำไปสู่ข้อโต้แย้งสำหรับอัลกอริธึมเดียวที่ยากต่อการแสดงออกเนื่องจากข้อ จำกัด

ชุดสูงสุดของโครงสร้างเหล่านี้จะกำหนดภาษาที่สามารถอนุมานได้ว่าจะหยุดหรือไม่ มีการศึกษาบางอย่างที่ทำกับสิ่งนี้หรือไม่?

ใช่. มันเรียกว่า "ทฤษฎีกลุ่ม" ชุดของค่าปิดภายใต้ชุดของการดำเนินการ สิ่งที่เข้าใจกันดี