ทำไมการพิมพ์ย่อยย่อยแบบพฤติกรรมไม่สามารถตัดสินใจได้?

งานของ Liskov ในพื้นที่นี้มุ่งเน้นไปที่พฤติกรรมย่อยซึ่งนอกเหนือจากประเภทความปลอดภัยของระบบที่กล่าวถึงในบทความนี้ยังต้องการให้ชนิดย่อยรักษาค่าคงที่ทั้งหมดที่รับประกันโดย supertypes ในสัญญาบางอย่าง [3] คำจำกัดความของการพิมพ์ย่อยนี้โดยทั่วไปไม่สามารถระบุได้ดังนั้นจึงไม่สามารถตรวจสอบได้โดยตัวตรวจสอบชนิด

จาก: http://www.wikiwand.com/en/Subtyping#/Function_types

type-systems subtypes

— q126y
แหล่งที่มา

คำตอบ:

ปล่อยให้สัญญาการทำงานoของ Type Tเป็นว่ามันจะหยุดสำหรับอินพุตทั้งหมด ตอนนี้ตัดสินใจว่าการดำเนินงานoของชนิดย่อยS <: Tน่าพอใจว่าสัญญา: คุณมีการแก้ไขเพียงลังเลปัญหา

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

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

— Jörg W Mittag
แหล่งที่มา

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

— Benjamin Gruenbaum

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

BigInteger sum(int[] arr) { BigInteger sum = BigInteger.ZERO; for (int x: arr) sum = sum.add(BigInteger.valueOf(x)); return sum; }

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

— Doval

และเมื่อมันไม่เทียบเท่ากับลังเลปัญหาก็มักจะแย่ลง เพราะเป็นไปไม่ได้ไม่ยากพออยู่แล้ว

— user2357112 รองรับ Monica

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

— Leushenko

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

— Giorgio

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

บางโปรแกรมคำนวณฟังก์ชันที่มีคุณสมบัตินี้โปรแกรมอื่น ๆ คำนวณฟังก์ชันที่ไม่มีคุณสมบัตินี้ รับโปรแกรม P ฟังก์ชั่นที่คำนวณโดย P มีคุณสมบัติข้างต้นหรือไม่?

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

เกือบคงที่พฤติกรรมที่น่าสนใจใด ๆ ตกอยู่ภายใต้ทฤษฎีบทของข้าวเนื่องจากงบเหล่านั้นไม่ค่อย (ถ้าเคย) พูดคุยเกี่ยวกับสิ่งที่วิธีการดูเหมือนว่าภายในเพียงสิ่งที่มันส่งกลับและสิ่งที่มีผลข้างเคียงมันทำให้เกิดการตอบสนอง

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

— Nathan Tuggy