हम सही ढंग से सही कार्यक्रमों के बारे में क्या जानते हैं?

Question

कंप्यूटर कार्यक्रमों की बढ़ती जटिलता और हमारे समाज में तेजी से महत्वपूर्ण स्थिति वाले कंप्यूटरों ने मुझे आश्चर्यचकित किया है कि हम अभी भी सामूहिक रूप से प्रोग्रामिंग भाषाओं का उपयोग क्यों नहीं करते हैं जिसमें आपको औपचारिक प्रमाण देना होगा कि आपका कोड सही तरीके से काम करता है।

मेरा मानना ​​है कि यह शब्द एक 'प्रमाणित कंपाइलर' है (मैंने इसे यहां पाया ): एक प्रोग्रामिंग भाषा को संकलित करने वाला एक कंपाइलर जिसमें न केवल कोड लिखना होता है, बल्कि कोड के स्पेसिफिकेशन को भी बताना होता है और यह साबित करना होता है कि कोड उसी का पालन करता है विनिर्देश (या ऐसा करने के लिए एक स्वचालित कहावत का उपयोग करें)।

इंटरनेट पर खोज करते समय, मुझे केवल ऐसी परियोजनाएँ मिलीं जो या तो बहुत ही सरल प्रोग्रामिंग भाषा का उपयोग करती हैं या विफल परियोजनाएँ जो आधुनिक प्रोग्रामिंग भाषाओं को अनुकूलित करने का प्रयास करती हैं। यह मुझे मेरे प्रश्न की ओर ले जाता है:

क्या कोई प्रमाणित कम्पाइलर एक पूर्ण विकसित प्रोग्रामिंग भाषा को लागू कर रहे हैं, या यह बहुत कठिन / सैद्धांतिक रूप से असंभव है?

इसके अतिरिक्त, मैंने अभी तक किसी भी जटिलता वर्ग को देखने योग्य कार्यक्रमों को शामिल करते हुए देखा है, जैसे कि 'ट्यूरिंग मशीन द्वारा निर्णायक सभी भाषाओं का वर्ग, जिसके लिए एक प्रमाण मौजूद है कि यह ट्यूरिंग मशीन रुक जाती है', जिसे मैं $ProvableR$ कहूंगा। एल ई आर के लिए एक एनालॉग के रूप में, $R$ , पुनरावर्ती भाषाओं के सेट।

मैं इस तरह के एक जटिलता वर्ग का अध्ययन कर के लाभ देख सकते हैं: उदाहरण के लिए, के लिए $ProvableR$ लंगड़ा समस्या डिसाइडेबल है (मैं भी अनुमान $ProvableRE$ स्पष्ट तरह से परिभाषित किया जाएगा भाषाओं का सबसे बड़ा वर्ग जिसके लिए यह निर्णायक है)। इसके अलावा, मुझे संदेह है कि हम किसी भी व्यावहारिक रूप से उपयोगी कार्यक्रमों को नियंत्रित करेंगे: जब आप इसे समाप्त नहीं कर सकते तो कौन प्रोग्राम का उपयोग करेगा?

तो मेरा दूसरा सवाल है:

हम उन जटिलता वर्गों के बारे में क्या जानते हैं जिनके लिए कुछ विशिष्ट गुणों वाली भाषाओं की आवश्यकता होती है?

Comments

एक कंपाइलर लंबाई के सभी संभावित प्रमाणों की गणना कर सकता है, जो मुझे 1 से अनंत तक जाने देता है, जब तक कि यह एक सबूत नहीं मिल जाता है कि कार्यक्रम रुक जाता है। यदि हमें आवश्यकता है कि संकलक के लिए इनपुट काफी हद तक रुक गया है, तो संकलक को हमेशा वह प्रमाण मिलेगा। चूंकि रुकने की समस्या अनिर्वाय है, इसलिए हमें निष्कर्ष निकालना चाहिए कि ऐसे कार्यक्रम हैं जो रुके हैं, लेकिन इसके लिए कोई प्रमाण मौजूद नहीं है। महत्वपूर्ण बिंदु यह है कि प्रोग्राम यह पता लगाने में असमर्थ हैं कि क्या कोई प्रमाण मौजूद है, ऐसा नहीं है कि वे मौजूद होने पर प्रमाण खोजने में असमर्थ हैं।

— एलेक्स टेन ब्रिंक

मुझे लगता है कि आपको उन्हें अलग करना चाहिए। वे अलग-अलग उत्तरों के साथ अलग-अलग प्रश्न हैं।

— मार्क रीटब्लाट

पहले सवाल पर, एक प्रभावशाली पेपर "सामाजिक प्रक्रियाओं और प्रमेयों और कार्यक्रमों के प्रमाण", portal.acm.org/citation.cfm?id=359106

— कॉलिन

कार्यक्रम का सत्यापन अपरिहार्य है। इसलिए एक समस्या यह है कि एक अच्छा समाधान क्या है। Cstheory.stackexchange.com/questions/4016/…

— Radu GRIGore

@ कोलिन: वह कागज अपने प्रमाण के विश्लेषण के लिए पढ़ने लायक है, लेकिन इसकी भविष्यवाणियां गलत बताई गई हैं। आज हमारे पास सही संकलक हैं, ऑपरेटिंग सिस्टम कर्नेल, कचरा संग्रहकर्ता और डेटाबेस, जिनमें से सभी ने असंभव होने की भविष्यवाणी की थी। उनके आलोचकों को बाहर निकालने की चाल औपचारिक प्रमाणों के निम्न-स्तरीय विवरणों के मानव सत्यापन से बचने के लिए थी, लेकिन सबूतों के मशीन सत्यापन का उपयोग करने के लिए, और सबूत परीक्षक को सत्यापित करने के लिए मनुष्यों का उपयोग करना था। सिद्धांत के प्रकार के लिए नोआम का संदर्भ वह जगह है जहां कला की स्थिति होती है, जो टाइप थ्योरी कार्यात्मक होने के बाद से किसी चीज में अनिवार्य कार्यक्रमों को छोड़ देती है।

— नील कृष्णस्वामी

Answer 1

"प्रमाणित कंपाइलर" का अर्थ आमतौर पर कुछ अलग होता है: इसका मतलब है कि आपके पास एक कंपाइलर है जो यह साबित कर सकता है कि मशीन कोड जो इसे सही ढंग से उत्सर्जित करता है वह उच्च स्तर के शब्दार्थों को लागू करता है। यही है, यह एक प्रमाण है कि संकलक कीड़े नहीं हैं। कंपाइलर को लोग जो प्रोग्राम देते हैं, वह अभी भी गलत हो सकता है, लेकिन कंपाइलर गलत प्रोग्राम का सही मशीन कोड वर्जन जेनरेट करेगा। इन पंक्तियों के साथ सबसे बड़ी सफलता की कहानी है कॉम्पर्ट सत्यापित सत्यापनकर्ता , जो सी के एक बड़े उपसमूह के लिए एक संकलक है।

कॉम्पेर्ट कंपाइलर अपने आप में एक शुद्धता प्रमाण (कोक में किया गया) वाला प्रोग्राम है, जो यह गारंटी देता है कि यदि यह प्रोग्राम के लिए कोड जनरेट करता है, तो यह सही होगा (असेंबली और सी के संचालन शब्दार्थों के संबंध में जो कॉम्पेंसेटर का उपयोग किया जाता है)। इन चीजों को मशीन-चेक करने का प्रयास काफी बड़ा है; आमतौर पर शुद्धता का प्रमाण आपके द्वारा सत्यापित किए जा रहे कार्यक्रम के आकार से 1x से 100x कहीं भी होगा। मशीन-चेक किए गए प्रोग्राम और प्रमाण लिखना एक नया कौशल है जिसे आपको सीखना है - यह हमेशा की तरह गणित या प्रोग्रामिंग नहीं है, हालांकि यह दोनों को अच्छी तरह से करने में सक्षम होने पर निर्भर करता है। ऐसा लगता है कि आप खरोंच से शुरू कर रहे हैं, जैसे एक नौसिखिया प्रोग्रामर फिर से होना।

हालांकि इसके लिए कोई विशेष सैद्धांतिक बाधाएं नहीं हैं। इन पंक्तियों के साथ एकमात्र बात ब्लम साइज प्रमेय है कि किसी भी भाषा के लिए जिसमें सभी कार्यक्रम कुल हैं, आप एक सामान्य पुनरावर्ती भाषा में एक कार्यक्रम पा सकते हैं जो कुल भाषा में प्रोग्राम किए जाने पर कम से कम तेजी से बड़ा होगा। इस परिणाम को समझने का तरीका यह है कि कुल भाषा न केवल एक कार्यक्रम है, बल्कि एक समाप्ति प्रमाण भी है। इसलिए आपके पास दीर्घकालिक समाप्ति प्रमाण के साथ छोटे कार्यक्रम हो सकते हैं। हालाँकि, यह वास्तव में व्यवहार में नहीं है, क्योंकि हम केवल प्रबंधनीय समाप्ति साक्ष्यों के साथ कार्यक्रम लिखने जा रहे हैं।

संपादित करें: दाई ले ने अंतिम बिंदु के कुछ विस्तार के लिए कहा।

यह ज्यादातर एक व्यावहारिक दावा है, इस तथ्य पर आधारित है कि यदि आप समझ सकते हैं कि एक कार्यक्रम क्यों काम करता है, तो यह संभावना नहीं है कि इसका कारण लाखों पृष्ठों के कुछ विशाल अपरिवर्तनीय हैं। (मेरे द्वारा उपयोग किए गए सबसे लंबे इंवेरिएंट कुछ पृष्ठ लंबे हैं, और क्या वे समीक्षकों को गदगद करते हैं! इसलिए भी, क्योंकि इंवेरेन्ट ही वह कारण है जिससे कार्यक्रम सभी कथाओं से छीन लिया जाता है जिससे लोगों को इसे समझने में मदद मिलती है।)

लेकिन इसके कुछ सैद्धांतिक कारण भी हैं। असल में, हम उन कार्यक्रमों को व्यवस्थित रूप से आविष्कार करने के लिए बहुत सारे तरीके नहीं जानते हैं जिनके शुद्धता प्रमाण बहुत लंबे हैं। मुख्य विधि यह है कि (1) उस तर्क को लें जिसमें आप शुद्धता साबित करते हैं, (2) एक ऐसी संपत्ति पाते हैं जिसे सीधे उस तर्क में व्यक्त नहीं किया जा सकता है (संगतता प्रमाण विशिष्ट स्रोत हैं), और (3) एक प्रोग्राम खोजें जिसका शुद्धता का प्रमाण अकथनीय संपत्ति के स्पष्ट परिणाम के परिवार पर निर्भर करता है। क्योंकि (2) अकथनीय है, इसका मतलब है कि प्रत्येक व्यक्त परिणाम का प्रमाण स्वतंत्र रूप से किया जाना चाहिए, जो आपको शुद्धता प्रमाण के आकार को उड़ाने देता है। एक साधारण उदाहरण के रूप में, ध्यान दें कि पहले-क्रम तर्क में एक मूल संबंध के साथ, आप पूर्वज संबंध को व्यक्त नहीं कर सकते।$k$$k$$k$

इस विषय पर परिष्कृत रूप को "रिवर्स गणित" कहा जाता है, और यह अध्ययन है कि दिए गए प्रमेयों को साबित करने के लिए स्वयंसिद्ध आवश्यक हैं। मैं इसके बारे में इतना नहीं जानता, लेकिन यदि आप इसके आवेदन पर एक सवाल सीएस को पोस्ट करते हैं, और मुझे यकीन है कि कम से कम टिमोथी चाउ, और शायद कई अन्य लोग, आपको दिलचस्प बातें बता पाएंगे।

Comments

क्या आप कृपया इस बिंदु को विस्तृत कर सकते हैं "हम केवल प्रबंधनीय समाप्ति साक्ष्यों के साथ कार्यक्रम लिखने जा रहे हैं"?

— दाई ले

आपके अद्यतन उत्तर के लिए धन्यवाद! आपका जवाब वास्तव में मेरा दृष्टिकोण खोलता है। वास्तव में मैं खुद भी "रिवर्स गणित" पर थोड़ा काम करता हूं, लेकिन मुझे आपके द्वारा बताए गए कनेक्शन का एहसास नहीं हुआ। एक बार फिर धन्यवाद!

— दाई ले

आपके संपादन में बिंदु इस तथ्य से संबंधित है कि हमारे पास प्राकृतिक प्रूफ सिस्टम (जैसे, कहो, फ्रीज) में लंबे प्रमाणों की आवश्यकता वाले लोगों के लिए शायद ही कोई हो। इसका कारण यह है कि एकमात्र तरीका जिसे हम जानते हैं कि एक तनातनी पहले स्थान पर है, क्योंकि हमारे मन में एक प्रमाण था, जो जरूरी नहीं कि इतना लंबा था!

— जोशुआ ग्रोचो

Answer 2

मुझे लगता है कि पहले प्रश्न का उत्तर यह है कि आम तौर पर यह वर्तमान उपकरणों के साथ बहुत अधिक काम करता है । भावना प्राप्त करने के लिए, मैं सुझाव देता हूं कि Coq में बबल सॉर्ट (या यदि आप थोड़ी और चुनौती पसंद करते हैं, तो सही सॉर्ट का उपयोग करें) को सही साबित करने की कोशिश करें। मुझे नहीं लगता है कि जब तक ऐसे बुनियादी एल्गोरिदम की शुद्धता साबित करना कठिन और समय लेने वाला साबित नहीं हो जाता है, तब तक प्रोग्रामर को सत्यापित कार्यक्रम लिखने की उम्मीद करना उचित नहीं है।

यह प्रश्न यह पूछने के समान है कि गणितज्ञ प्रूफ चेकरों द्वारा सत्यापन योग्य औपचारिक प्रमाण क्यों नहीं लिखते हैं? एक औपचारिक शुद्धता प्रमाण के साथ एक कार्यक्रम लिखने का मतलब है लिखित कोड के बारे में गणितीय प्रमेय साबित करना, और उस प्रश्न का उत्तर आपके प्रश्न पर भी लागू होता है।

इसका मतलब यह नहीं है कि सत्यापित कार्यक्रमों के सफल मामले नहीं आए हैं। मुझे पता है कि ऐसे समूह हैं जो माइक्रोसॉफ्ट के हाइपरवाइजर जैसी प्रणालियों की शुद्धता साबित कर रहे हैं । एक संबंधित मामला Microsoft का सत्यापित सी कंपाइलर है । लेकिन सामान्य तौर पर वर्तमान प्रोग्रामर (और गणितज्ञ) के लिए उपयोगी बनने से पहले वर्तमान उपकरणों को बहुत अधिक विकास (उनके एसई और एचसीआई पहलुओं सहित) की आवश्यकता होती है।

केवल कुल कार्यों के साथ भाषाओं के लिए कार्यक्रम के आकार के विकास के बारे में नील के जवाब के अंतिम पैराग्राफ के बारे में, वास्तव में इसे और भी अधिक साबित करना आसान है (यदि मैंने इसे सही ढंग से समझा)। यह उम्मीद करना उचित है कि किसी भी प्रोग्रामिंग भाषा का सिंटैक्स CE होगा और कुल कम्प्यूटेशनल फ़ंक्शन का सेट CE नहीं है, इसलिए किसी भी प्रोग्रामिंग भाषा के लिए जहां सभी प्रोग्राम कुल हैं, कुल कम्प्यूटेशनल फ़ंक्शन है जिसे किसी भी प्रोग्राम द्वारा गणना नहीं की जा सकती है ( किसी भी आकार में) उस भाषा में।

---

$AC^0$$AC^0$- जटिलता वर्ग के लिए अपूर्ण, इसलिए इसमें जटिलता वर्ग में सभी समस्याएं हैं और उन कार्यक्रमों की समग्रता को साबित कर सकता है। सबूत और जटिलता सिद्धांत के बीच के संबंध का अध्ययन सबूत जटिलता में किया जाता है, एसए कुक और पी। गुयेन की हालिया पुस्तक " लॉजिकल फाउंडेशंस ऑफ प्रूफ जटिलता " देखें यदि आप रुचि रखते हैं। ( 2008 से एक मसौदा उपलब्ध है।) तो मूल उत्तर यह है कि कई वर्गों के लिए "प्रोवीसीली सी = सी"।

$PA$$\epsilon_0$$T$$PA^2$$F$$I\Sigma_1$

लेकिन यह मुझे नहीं लगता है कि कार्यक्रम सत्यापन संदर्भ में इसका मतलब बहुत है, क्योंकि ऐसे कार्यक्रम भी हैं जो समान रूप से एक ही फ़ंक्शन की गणना कर रहे हैं, लेकिन हम यह साबित नहीं कर सकते हैं कि दो प्रोग्राम एक ही फ़ंक्शन की गणना कर रहे हैं, अर्थात प्रोग्राम एक्सटेंसिवली समान हैं, लेकिन नहीं जानबूझ कर। (यह मॉर्निंग स्टार और ईवनिंग स्टार के समान है।) इसके अलावा किसी एक को प्राप्त करने के लिए किसी दिए गए कुल प्रोग्राम को संशोधित करना आसान है, जो सिद्धांत अपनी समग्रता को साबित करने में असमर्थ है।

---

$P$$n$$n$$P$प्रमाण से कारक के लिए एल्गोरिथ्म। (ऐसे शोधकर्ता भी हैं जो यथासंभव पहले दृष्टिकोण को स्वचालित करने की कोशिश करते हैं, लेकिन कार्यक्रमों के दिलचस्प गैर-तुच्छ गुणों की जांच करना कम्प्यूटेशनल रूप से कठिन है और झूठी सकारात्मक और नकारात्मक के बिना पूरी तरह से सत्यापित नहीं किया जा सकता है।)

Comments

अच्छा जवाब! आप उल्लेख करते हैं कि एक तरीका सबूतों से कार्यक्रमों को निकालने का है, जो कि कुछ ऐसा है जो कॉक में स्वचालित रूप से कर सकता है, उदाहरण के लिए। एक संबंधित क्षेत्र प्रमाण खनन है , जहां लोग (आमतौर पर गणितीय तर्क में काम करते हैं) किसी दिए गए प्रमाण से जानकारी निकालने का प्रयास करते हैं। उदाहरण के लिए, यह कुछ मामलों में (स्वचालित रूप से) एक शास्त्रीय एक दिए गए अंतर्ज्ञान संबंधी प्रमाण को खोजने के लिए संभव है।

— रादु GRIGore 21

$\Pi^0_2$$PA$$HA$

अपने ब्लॉग पर एक नया दिलचस्प पोस्ट किया है, जिसमें वह बोएल में गॉडल की डाइलक्टिका इंटरप्रिटेशन साबित करते हैं ।

— केवह

Answer 3

पहले सवाल के बारे में आप जो पूछ रहे हैं, उसे कभी-कभी "वेरिफाइंग कंपाइलर" कहा जाता है, और कुछ साल पहले टोनी होरे ने इसे कंप्यूटिंग अनुसंधान के लिए एक बड़ी चुनौती के रूप में पेश किया । कुछ हद तक यह पहले से ही मौजूद है और कॉक प्रमेय प्रोवर जैसे उपकरणों में सक्रिय उपयोग में है , जो समस्या को प्रकार सिद्धांत और प्रस्ताव-के-प्रकार सिद्धांत (" करी-हावर्ड ") के माध्यम से व्यवस्थित करते हैं ।

EDIT: बस "कुछ हद तक" पर जोर देना चाहता था। यह एक सुलझी हुई समस्या से दूर है, लेकिन कोक की सफलता यह आशा करती है कि यह एक पाइप सपना नहीं है।

Comments

मैं कहूंगा कि भवन निर्माण सॉफ्टवेयर सत्यापित है जहाँ 1956 में सादा पुराने सॉफ़्टवेयर का निर्माण किया गया था। यह पहले से ही स्पष्ट था कि सॉफ्टवेयर अविश्वसनीय रूप से महत्वपूर्ण होने जा रहा था, और पहले से ही बड़ी सफलता की कहानियाँ थीं। हालांकि, लोग अभी भी कई लापता मूलभूत अवधारणाएं (उदाहरण के लिए, प्रक्रियाओं और चर क्या थे की एक स्पष्ट समझ), और सिद्धांत से अभ्यास तक की दूरी एक प्रमेय में कोड को प्रोग्रामिंग करके लिस्प को लागू करने के रूप में कम हो सकती है। यह भाषाओं और सत्यापन पर काम करने का एक रोमांचक समय है।

— नील कृष्णस्वामी

Answer 4

एक उपकरण जो यह जाँचता है कि क्या कोई प्रोग्राम सही है, कभी-कभी प्रोग्राम वेरिफ़ायर कहलाता है। इस संदर्भ में, "सही" का अर्थ आमतौर पर दो चीजों से होता है: यह कि प्रोग्राम कभी भी कुछ आउटपुट (थिंक सेक्शन फॉल्ट, NullPointerException, आदि) का उत्पादन नहीं करता है और यह कि प्रोग्राम एक विनिर्देश के साथ सहमत है।

कोड और विनिर्देश सहमत हो सकते हैं और अभी भी गलत माना जा सकता है। एक अर्थ में, डेवलपर्स को विनिर्देशों को लिखने के लिए कहना दो डेवलपर्स को समस्या को हल करने के लिए कहने जैसा है। यदि दो कार्यान्वयन सहमत हैं तो आपको अधिक विश्वास है कि वे ठीक हैं। हालांकि, दूसरे अर्थ में, विनिर्देश एक दूसरे कार्यान्वयन से बेहतर हैं। क्योंकि विनिर्देश को कुशल या निष्पादन योग्य होने की आवश्यकता नहीं है, यह बहुत अधिक सफल हो सकता है और इसलिए गलत होने के लिए कठिन है।

मन में इन गुच्छों के साथ, मैं आपको कल्पना # कार्यक्रम सत्यापनकर्ता को देखने की सलाह देता हूं ।

Comments

जहाँ तक मुझे Spec # (और इसका विस्तार Sing #) समझ में आता है, यह प्रोग्रामर को वैधानिक रूप से सत्यापित करने की क्षमता देता है, लेकिन इसके लिए प्रोग्रामर को ऐसा करने की आवश्यकता नहीं होती है, न ही यह कोड के मनमाने गुणों को साबित करने की क्षमता प्रदान करता है।

— एलेक्स दस ब्रिंक

सिद्धांत रूप में मनमाने गुण को फॉल्स एश्योरेंस के रूप में एन्कोड किया जा सकता है। मुझे यकीन नहीं है कि आप क्या चाहते हैं उपकरण की आवश्यकता है। क्या आप यह कहना चाहते हैं कि आउटपुट सभी संभावित सूचनाओं के लिए होना चाहिए?

— रादु GRIGore

Answer 5

सामान्य मामले में, एक एल्गोरिथ्म बनाना असंभव है जो पुष्टि करता है कि क्या एल्गोरिथ्म एक विनिर्देश के बराबर है। यह एक अनौपचारिक प्रमाण है:

लगभग सभी प्रोग्रामिंग भाषाएं ट्यूरिंग-पूर्ण हैं। इसलिए, टीएम द्वारा तय की गई किसी भी भाषा का निर्णय इस भाषा में लिखे गए प्रोग्राम द्वारा किया जा सकता है।

$Equivalence/TM$

$Equivalence/TM$$Non-emptiness/TM$$Emptiness/TM$$Emptiness/TM$$Equivalence/TM$$Equivalence/TM$अस्वीकार्य भी है। इसलिए आप एक एल्गोरिथ्म का उपयोग कर सकते हैं चाहे दो मशीनें समतुल्य हों या न हों, लेकिन आप सुनिश्चित नहीं हो सकते हैं कि वे समान हैं, या आपने अपना एल्गोरिथ्म हर बार नहीं दिया है।

हालांकि, यह केवल सामान्य मामले के लिए है। यह संभव है कि आप समस्या के अधिक आराम से संस्करण को हल करके यह तय कर सकते हैं कि विनिर्देश कार्यक्रम के बराबर हैं या नहीं। उदाहरण के लिए, आप केवल कुछ इनपुट्स की जांच कर सकते हैं या कह सकते हैं कि दोनों प्रोग्राम कुछ अनिश्चितता के बराबर हैं। यह वही है जो सॉफ्टवेयर परीक्षण के बारे में है।

अपने शेष प्रश्नों के लिए:

नोट: इस भाग को स्पष्टीकरण के लिए संपादित किया गया है। यह पता चला है कि मैंने वह गलती की, जिसे मैं टालने की कोशिश कर रहा था, क्षमा करें।

$TrueR$$TrueR \subseteq R$

$ProvableR = TrueR$$ProvableR \subset TrueR$$TrueR \subset ProvableR$$A \epsilon TrueR$$A$$A$$A \epsilon ProvableR$

अनौपचारिक रूप से, इसे इस रूप में संक्षेपित किया जा सकता है: आप यह नहीं जानते कि कोई भाषा तब तक विघटित होती है जब तक आप इसे सिद्ध नहीं करते। इसलिए अगर किसी औपचारिक प्रणाली में आपको ज्ञान है कि कोई भाषा निर्णायक है, तो यह ज्ञान उसके लिए एक प्रमाण के रूप में भी काम कर सकता है। इसलिए, आपको एक साथ ज्ञान नहीं हो सकता है कि एक भाषा दोनों निर्णायक है और यह साबित नहीं किया जा सकता है, ये दोनों कथन परस्पर अनन्य हैं।

$R$$ProvableR$$ProvableR \subset R$$R$

@ केवह इसे सर्वश्रेष्ठ रूप से संक्षेप में प्रस्तुत करता है: उपलब्ध हमेशा किसी प्रणाली / सिद्धांत में सिद्ध करने योग्य होता है और सामान्य रूप से सत्य के साथ मेल नहीं खाता है।

वही किसी भी अन्य जटिलता वर्ग के लिए है: सदस्यता निर्धारित करने के लिए आपको पहले एक प्रमाण की आवश्यकता होती है। यही कारण है कि मेरा मानना ​​है कि आपका दूसरा प्रश्न बहुत सामान्य है, क्योंकि इसमें न केवल जटिलता सिद्धांत है, बल्कि गणना सिद्धांत भी है, जिस संपत्ति पर आप भाषा चाहते हैं।

Comments

$R\subset ProvableR$$\Sigma^0_3$$\Sigma^0_1$

प्रदान करने योग्य हमेशा किसी न किसी प्रणाली / सिद्धांत में सिद्ध होता है और सामान्य रूप से सत्य के साथ मेल नहीं खाता है।

— केवह

अब मैं देखता हूं कि मेरे प्रश्न के दिलचस्प होने के लिए, ट्यूरिंग मशीनों के सेट के बारे में बात करनी चाहिए, न कि निर्णायक भाषाओं के सेट के बारे में।

— एलेक्स टेन ब्रिंक

@ अलेक्स वैसे, आपको भाषाओं के बारे में बात करने का कुछ तरीका चाहिए, लेकिन बेशुमार कई हैं। इसलिए, यदि आप किसी परिमित वस्तु (जैसे प्रमाण) से जुड़ी भाषाओं के बारे में बात करना चाहते हैं, तो आपको अपने आप को एक परिमित वस्तु द्वारा पहचानी जाने वाली भाषाओं में सीमित करना होगा, जैसे कि एक टीएम।

— बजे मार्क रीटब्लेट

$R$

Answer 6

निम्नलिखित क्लासिक मोनोग्राफ आपके लगभग दूसरे प्रश्न का अध्ययन करता है:

हार्टमैनिस, जे। व्यवहार्य संगणनाएँ और सुस्पष्ट जटिलता गुण , एप्लाइड गणित में CBMS-NSF क्षेत्रीय सम्मेलन श्रृंखला, 30. औद्योगिक और अनुप्रयुक्त गणित (SIAM), फिलाडेल्फिया, Pa।, 1978 के लिए सोसायटी।

$\{L(M_i) | T_i(n) \leq T(n) \text{ is provable in F}\}$$M_i$$T_i(n)$$M_i$$n$

$T(n) \geq n \log(n)$$g(n) \geq 1$$F$$TIME[T(n)] \subsetneq TIME[T(n) g(n)]$

प्रमेय 6.5: इसमें मौजूद संगणकीय रूप से बढ़ते समय सीमा है जिसके लिए - ।$T(n)$$F$$TIME[T(n)] \neq TIME[T(n)]$

प्रमेय 6.14: किसी भी अभिकलन , ।$T(n) \geq n \log(n)$$TIME[T(n)] = \{ L(M_i) | \text{F proves} (\exists j)[L(M_j) = L(M_i) \wedge T_j(n) \leq T(n)] \}$

अंतरिक्ष के लिए, हालांकि, स्थिति बेहतर नियंत्रित है:

प्रमेय 6.9: (1) यदि स्थान-निर्माण योग्य है, तो - ।$s(n) \geq n$$SPACE[s(n)] = F$$SPACE[s(n)]$

(2) यदि - ( ) है तो एक स्पेस-कंस्ट्रक्टेबल जैसे ।$SPACE[S(n)]=F$$SPACE[S(n)]$$S(n) \geq n$$s(n)$$SPACE[S(n)]=SPACE[s(n)]$

Answer 7

सवाल को सही ढंग से पेश करना होगा। उदाहरण के लिए, कोई भी कभी भी यह जानना नहीं चाहता है कि क्या कोई वास्तविक कार्यक्रम अनंत स्मृति और इसे एक्सेस करने के कुछ साधनों को पूरा करेगा (शायद कुछ संख्या के आधार पते को स्थानांतरित करने के लिए एक ऑपरेशन)। ट्यूरिंग की प्रमेय किसी भी ठोस अर्थ में शुद्धता को लागू करने के लिए अप्रासंगिक है और जो लोग इसे कार्यक्रम सत्यापन में बाधा के रूप में उद्धृत करते हैं वे दो बिल्कुल अलग चीजों को भ्रमित कर रहे हैं। जब इंजीनियर / प्रोग्रामर प्रोग्राम शुद्धता की बात करते हैं तो वे परिमित गुणों के बारे में जानना चाहते हैं। यह उन गणितज्ञों के लिए भी बहुत सही है, जो इस बात में रुचि रखते हैं कि क्या कुछ साबित हो सकता है। गोडेल का पत्र http://vyodaiken.com/2009/08/28/godels-lost-letter/ इस बारे में कुछ विस्तार से बताता है।

अर्थात्, इसका स्पष्ट रूप से मतलब होगा कि एन्सेचेइदंगस्प्रोब्लेम की अनिर्वायता के बावजूद, यस-या-नो प्रश्नों से संबंधित गणितज्ञ के मानसिक कार्य को पूरी तरह से एक मशीन द्वारा प्रतिस्थापित किया जा सकता है। आखिरकार, किसी को स्वाभाविक रूप से n इतनी बड़ी संख्या चुननी होगी कि जब मशीन परिणाम नहीं दे, तो समस्या के बारे में अधिक सोचने का कोई मतलब नहीं है।

यह एक वास्तविक कंप्यूटर पर निष्पादित होने वाले प्रोग्राम की विशाल स्थिति की जांच करने और खराब स्थिति का पता लगाने के लिए अच्छी तरह से संभव है, इसका कोई सैद्धांतिक कारण नहीं है कि यह क्यों नहीं किया जा सकता है। वास्तव में, इस क्षेत्र में बहुत प्रगति हुई है - उदाहरण के लिए http://www.cs.cornell.edu/gomes/papers/SATSolvers-KR-book-draft-07.pdf देखें (नील इम्मरमेन के लिए धन्यवाद) मुझे इस बारे में बता रहे हैं)

एक अलग और अधिक कठिन समस्या यह निर्दिष्ट कर रही है कि कौन से गुण सही होने के लिए एक कार्यक्रम चाहते हैं।