Tại sao phân nhóm hành vi không thể giải quyết được?

Công việc của Liskov trong lĩnh vực này tập trung vào phân nhóm hành vi, bên cạnh loại an toàn hệ thống được thảo luận trong bài viết này cũng yêu cầu các phân nhóm bảo tồn tất cả các bất biến được đảm bảo bởi các siêu kiểu trong một số hợp đồng. [3] Định nghĩa về phân nhóm nói chung là không thể giải quyết được, do đó, nó không thể được xác minh bởi trình kiểm tra loại.

Từ: http://www.wikiwand.com/en/Subtyping#/Function_types

type-systems subtypes

— q126
nguồn

Câu trả lời:

Đặt hợp đồng hoạt động ocủa Type Tlà nó tạm dừng cho tất cả các đầu vào. Bây giờ hãy quyết định xem hoạt động ocủa phân nhóm có S <: Tthỏa mãn hợp đồng đó hay không: bạn vừa giải quyết vấn đề Dừng .

Tổng quát hơn, S::ophải tính toán hàm giống như T::onếu S <: T. Quyết định xem hai chương trình tính toán cùng một hàm có được gọi là Bài toán hàm hay không và tương đương với việc giải bài toán Dừng.

Nói chung, quyết định tĩnh bất kỳ thuộc tính thời gian chạy không tầm thường nào hầu như luôn tương đương với Vấn đề Dừng.

— Jorg W Găngag
nguồn

Đó là dòng cuối cùng móng tay nó. Khoảnh khắc bạn muốn chứng minh một tài sản về những gì chương trình có thể làm trong môi trường hành vi mà bạn đang bước vào điều không thể. Các hệ thống loại lý do và các công cụ phân tích tĩnh hoạt động là chúng xử lý một ngôn ngữ khác (của các loại chương trình, về phạm vi của các biến trong chương trình, v.v.) chứ không phải các thuộc tính về cách chương trình chạy trực tiếp.

— Benjamin Gruenbaum

@BenjaminGruenbaum Câu trả lời của Jorg và nhận xét của bạn là đúng nhưng có một sự tinh tế đối với nó tôi muốn làm rõ. Thường có thể chứng minh một tài sản về một chương trình cụ thể . Không có thuật toán nào bạn có thể làm theo một cách mù quáng sẽ hoạt động cho tất cả các chương trình. Xem xét phương thức này được viết bằng Java:

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

Không khó để chứng minh rằng phương thức cụ thể đó luôn trả về tổng của các phần tử của một số nguyên và không làm gì khác (với điều kiện là đối số không phải là null).

— Doval

Và khi nó không tương đương với vấn đề tạm dừng, nó thường còn tồi tệ hơn . Bởi vì không thể không đủ khó.

— user2357112 hỗ trợ Monica

Hoặc để đặt quan điểm của Doval theo cách khác (cùn), đây chính là lý do tại sao các ngôn ngữ không hoàn chỉnh lại rất thú vị và hữu ích. Bạn thường không cần Turing-đầy đủ (chắc chắn ở cấp độ mô-đun) cho công việc thực tế.

— Leushenko

@Doval: Điểm rất tốt. Mặc dù đúng là bạn không thể có một thuật toán chứng minh sự chấm dứt và / hoặc tính chính xác của một chương trình ngẫu nhiên, có thể viết các chương trình theo cách mà bạn có thể chứng minh tính đúng đắn của chúng.

— Giorgio

Bởi vì hầu hết mọi câu hỏi về hành vi của các chương trình là không thể giải quyết được. Theo định lý của Rice , bất kỳ vấn đề quyết định nào của mẫu:

Một số chương trình tính toán các hàm có thuộc tính này, các chương trình khác tính toán các hàm không có thuộc tính này. Cho một chương trình P, hàm được tính bởi P có thuộc tính nói trên hay không?

là không thể giải quyết được Vì vậy, ví dụ, bạn không thể luôn phân biệt mã tính bình phương của đầu vào với mã không. Mặc dù trong các trường hợp đơn giản, thường có thể chứng minh rằng một hàm làm hoặc không làm như vậy, không có quy trình chung nào hoạt động cho tất cả chương trình.

Hầu như bất kỳ hành vi bất biến thú vị nào đều thuộc định lý của Rice, vì những câu nói đó hiếm khi (nếu có) nói về phương thức trông như thế nào trong nội bộ, chỉ những gì nó trả về và tác dụng phụ của nó khi phản ứng với những đầu vào nhất định.

Bạn có thể làm rõ một chút: Không phải là một chương trình nhất định, dù bệnh lý đến đâu, có thể chống lại tất cả các phân tích, nhưng đối với bất kỳ phân tích nhất định nào, tồn tại ít nhất một chương trình không thể được phân loại chính xác với chương trình đó.

— Nathan Tuggy