कंप्यूटर कोड लिखने की तुलना में गणितीय प्रमाण को अधिक दोषपूर्ण क्यों लिखा जा रहा है?

Question

मैंने देखा है कि मुझे बगैर किसी गलती के कंप्यूटर प्रोग्राम लिखने की तुलना में गणितीय प्रमाण लिखना बहुत आसान लगता है।

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

फिर भी लोग गणितीय पत्रों के पूरे कागजात या किताबें बिना किसी संकलक के कभी भी उन्हें दे सकते हैं कि उन्होंने कोई गलती की है, और कभी-कभी दूसरों से भी प्रतिक्रिया लिए बिना।

मुझे स्पष्ट होने दो। यह कहना नहीं है कि लोग गणितीय प्रमाणों में गलतियां नहीं करते हैं, लेकिन यहां तक ​​कि हल्के से अनुभवी गणितज्ञों के लिए, गलतियां आमतौर पर समस्याग्रस्त नहीं होती हैं, और कुछ "बाहरी ओरेकल" की मदद के बिना हल की जा सकती हैं जैसे कि एक संकलक आपकी ओर इशारा करते हुए गलती।

वास्तव में, अगर यह मामला नहीं था, तो गणित शायद ही ऐसा हो सकता है जो मुझे लगता है।

तो इसने मुझे यह सवाल पूछने के लिए प्रेरित किया: दोषपूर्ण गणितीय प्रमाण लिखने और दोषरहित कंप्यूटर कोड लिखने के बारे में ऐसा क्या अलग है जो इसे बनाता है ताकि पूर्ववर्ती उत्तरार्द्ध की तुलना में बहुत अधिक ट्रैफ़िक हो?

कोई यह कह सकता है कि यह केवल एक तथ्य है कि लोगों के पास एक संकलक का "बाहरी अलंकृत" है जो उन्हें उनकी गलतियों की ओर इशारा करता है जो प्रोग्रामर को आलसी बनाता है, उन्हें ऐसा करने से रोकता है जो कठोरता से कोड लिखने के लिए आवश्यक है। इस दृष्टिकोण का अर्थ यह होगा कि यदि उनके पास कोई कंपाइलर नहीं है, तो वे गणितज्ञों की तरह दोषरहित हो सकेंगे।

आपको यह प्रेरक लग सकता है, लेकिन मेरे अनुभव प्रोग्रामिंग और गणितीय प्रमाण लिखने के आधार पर, यह मेरे लिए सहज रूप से लगता है कि यह वास्तव में स्पष्टीकरण नहीं है। ऐसा लगता है कि दो प्रयासों के बारे में मौलिक रूप से कुछ अलग है।

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

दूसरे शब्दों में, यदि किसी प्रमाण में स्टेप सही है, तो स्टेप में गलती करने से स्टेप कभी गड़बड़ नहीं होगी । लेकिन अगर कोड की एक पंक्ति को सही ढंग से लिखा गया है, तो लाइन में एक गलती करने से लाइन के काम पर प्रभाव पड़ेगा , ताकि जब भी हम लाइन लिखें तो हमें अन्य सभी लाइनों के संबंध में इसका ध्यान रखना होगा। हम इस तरह की सीमा तक इनकैप्सुलेशन और उन सभी चीजों का उपयोग कर सकते हैं, लेकिन इसे पूरी तरह से हटाया नहीं जा सकता है।वाई एक्स एक्स वाई वाई एक्स $X$$Y$$X$$X$$Y$$X$$X$

इसका मतलब यह है कि गणितीय प्रमाण में त्रुटियों के लिए जाँच की प्रक्रिया अनिवार्य रूप से प्रमाण-चरणों की संख्या में रैखिक है, लेकिन कंप्यूटर कोड में त्रुटियों के लिए जाँच की प्रक्रिया अनिवार्य रूप से कोड की लाइनों की संख्या में घातीय है।

तुम क्या सोचते हो?

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

Comments

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

— ब्लिसॉर्बलाडे

एक नुथ उद्धरण की याद दिलाता है, मुझे लगता है कि "उपरोक्त कोड से सावधान रहें! मैंने केवल इसे सही साबित किया, मैंने इसे कभी भी परीक्षण नहीं किया"

— हेगन वॉन एटिजन

टिप्पणियाँ विस्तारित चर्चा के लिए नहीं हैं; इस वार्तालाप को बातचीत में स्थानांतरित कर दिया गया है ।

— गाइल्स

मुझे एक हाथ से लिखा गणित का प्रमाण दें जो 100 मिलियन लंबी हो और जिसमें कोई "बग" न हो, और मैं आपको वह सब कुछ दूंगा जो मेरे पास है।

— Davor

सबूतों की तुलना में कार्यात्मक कार्यक्रम लिखना बहुत आसान हो सकता है, हालांकि, जैसे ही राज्य में आता है ... कठिनाई का पता

— चलता है

Answer 1

मुझे आपके प्रश्न के उत्तर के रूप में एक कारण और एक गलत धारणा प्रदान करते हैं।

मुख्य कारण यह लिखने के लिए (प्रतीत होता है) सही गणितीय प्रमाणों आसान है कि है कि वे एक बहुत ही उच्च स्तर पर लिखा जाता है। मान लीजिए कि आप इस तरह एक कार्यक्रम लिख सकते हैं:

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)

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

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

एक महत्वपूर्ण गलत धारणा यह है कि गणितीय प्रमाण अक्सर सही होते हैं। वास्तव में, यह शायद आशावादी है। गलतियों के बिना जटिल प्रमाण लिखना बहुत कठिन है, और कागजात में अक्सर त्रुटियां होती हैं। शायद सबसे हाल ही में मनाए गए मामले विल्स का पहला प्रयास है (एक विशेष मामला) प्रतिरूपकता प्रमेय (जिसका अर्थ है फ़र्मेट की अंतिम प्रमेय), और परिमित सरल समूहों के वर्गीकरण में विभिन्न अंतराल शामिल हैं, जिनमें कुछ 1000+ पृष्ठ क्वासिथिन समूहों के लिए थे माना जाता है कि वर्गीकरण के 20 साल बाद लिखा गया था।

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

Comments

टिप्पणियाँ विस्तारित चर्चा के लिए नहीं हैं; इस वार्तालाप को बातचीत में स्थानांतरित कर दिया गया है ।

— DW

क्या यह संभव है कि भविष्य में, प्रमाण सहायकों का उपयोग आपके कोड और प्रमाण दोनों की जांच के लिए किया जाएगा? हो सकता है कि यह समय आपके लिए एक एजडा सीखने का हो ? (सॉरी ...)

— एलेक्स वोंग

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

— svick

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

— एलेक्स वोंग

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

— xji

Answer 2

(मैं शायद यहां कुछ डाउनवोट्स को जोखिम में डाल रहा हूं, क्योंकि मेरे पास इसे उचित उत्तर देने के लिए कोई समय / रुचि नहीं है, लेकिन मुझे लगता है कि उद्धृत पाठ (और उद्धृत लेख के बाकी) नीचे काफी व्यावहारिक हैं, यह भी विचार करते हुए कि वे लिखे गए हैं एक प्रसिद्ध गणितज्ञ द्वारा। शायद मैं बाद में जवाब में सुधार कर सकता हूं।)

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

एक कंप्यूटर प्रोग्राम प्राप्त करने के लिए आवश्यक शुद्धता और पूर्णता का मानक गणितीय समुदाय के मान्य प्रमाणों की तुलना में अधिक परिमाण के आदेशों का एक जोड़ा है। बहरहाल, बड़े कंप्यूटर प्रोग्राम, यहां तक ​​कि जब वे बहुत सावधानी से लिखे गए हैं और बहुत सावधानी से परीक्षण किए गए हैं, तो हमेशा कीड़े लगते हैं। [...] गणित जैसा कि हम अभ्यास करते हैं, यह अन्य विज्ञानों की तुलना में बहुत अधिक औपचारिक रूप से पूर्ण और सटीक है, लेकिन यह कंप्यूटर प्रोग्रामों की तुलना में इसकी सामग्री के लिए बहुत कम औपचारिक और सटीक है। अंतर केवल प्रयास की मात्रा के साथ नहीं है: प्रयास का प्रकार गुणात्मक रूप से भिन्न है। कंप्यूटर के बड़े कार्यक्रमों में, असंख्य अनुकूलता के मुद्दों पर जबरदस्त प्रयास करना चाहिए: यह सुनिश्चित करना कि सभी परिभाषाएँ सुसंगत हों, "अच्छा" डेटा संरचनाएँ जो उपयोगी होती हैं, लेकिन बोझिल सामान्यता नहीं, कार्यों के लिए "सही" सामान्यता आदि पर निर्णय लेना, किसी बड़े कार्यक्रम के कामकाजी हिस्से पर खर्च ऊर्जा का अनुपात, जैसा कि बहीखाता भाग से अलग है, आश्चर्यजनक रूप से छोटा है। संगतता के मुद्दों के कारण जो लगभग अनिवार्य रूप से हाथ से बाहर निकल जाते हैं क्योंकि "सही" परिभाषाएं बदल जाती हैं क्योंकि सामान्यता और कार्यक्षमता को जोड़ा जाता है, कंप्यूटर प्रोग्राम को आमतौर पर अक्सर स्क्रैच से, फिर से लिखना पड़ता है।

गणितज्ञों द्वारा कार्यक्रम और कार्यक्रम (पृ। 9-10) पर, विलीम पी। थुरस्टन https://arxiv.org/pdf/math/9404236.pdf द्वारा

Comments

"कोड पुन: उपयोग" के बारे में बिंदु काफी एप्रोपोस है। रूसी से अंग्रेजी में एक लंबा सबूत का अनुवाद करने में काफी टाइपिंग होती है ; लेकिन एक बड़े कंप्यूटर प्रोग्राम का अनुवाद करते हुए, आइए C ++ को जावा में कहते हैं, यह काफी सोचनीय है । इसके अलावा, प्राचीन ग्रीक में 3000 साल पुराने प्रमाण को फिर से जीवित करना उतना ही आसान है; पीएल / 1 में एक 30 वर्षीय कार्यक्रम को पुनर्जीवित करना बस उतना ही कठिन या कठिन है।

— क्क्सप्लसोन

प्राचीन ग्रीक उदाहरण ने मुझे यह भी एहसास कराया: कंप्यूटर प्रोग्रामर स्थानीय स्लैंग और बोलचाल के एक टन का उपयोग करते हैं , जैसे कि (void*)1और open('/dev/null'), जो कि विभिन्न उप-संस्कृति के बीच पोर्टेबल भी नहीं हो सकता है, अकेले गंतव्य भाषा में अनुवाद योग्य होने दें। (पाठक सिर्फ थोड़े लंबे अनुभव के द्वारा अपने अनुमानित शब्दार्थ को पकड़ना चाहते हैं।) मुझे लगता है कि गणितीय प्रमाण में इस तरह के "स्लैंग" कम होते हैं। यदि कोई प्रमाण किसी शब्द का उपयोग करता है, तो इसका वास्तविक सार्वभौमिक अर्थ पाठक द्वारा किसी भी तरह से समझा जाना चाहिए । कंप्यूटर प्रोग्राम भी नहीं है है सार्वभौमिक अर्थ!

— क्क्सप्लसोन

+1, क्योंकि एक रचनाकार के रूप में, एक अनियंत्रित रूप से बड़े मूल्य से अलग construct के विशाल अनुमान ने मुझे पागल कर दिया। यह एक मूल्य-स्तर की गिरावट से तार्किक गिरावट तक बढ़ जाता है जब गणितज्ञ अनंत श्रृंखला के बारे में बात करना शुरू करते हैं और फिर उन श्रृंखलाओं के आधार पर तर्क बनाते हैं, जो एक छिपे हुए पर-त्रुटि को प्रभावित करते हैं- 0$\infty$ गिरावट। $\frac{0}{0}$

— Nat

@ क्या आप विस्तृत कर सकते हैं? मुझे नहीं मिला।

— ग्रेगरी मैगर्सक

@GregoryMagarshak इस उत्तर ने एक मामले का प्रदर्शन किया जिसमें यह माना गया कि श्रृंखला निर्माण में अनन्तता की वैधता एक पतन की ओर ले जाती है, जिसे मैं इस तरह छिपा हुआ बता रहा था- पतन$\frac{0}{0}$(विकिपीडिया अनुभाग में"प्रच्छन्न" संस्करण कम)। एक शास्त्रीय गणितज्ञ कह सकता है कि गलती यह मान रही थी कि एक अनंत श्रृंखला अभिसरण करती है, हालांकि एक रचनाकार इस अनैतिकता को अनन्तता के अयोग्य अनुमान के रूप में वर्णित करेगा।

— नेट

Answer 3

मुझे EW Dijkstra के हवाले से शुरू करने की अनुमति दें:

"प्रोग्रामिंग गणित की सबसे कठिन शाखाओं में से एक है; गरीब गणितज्ञों के पास बेहतर गणितज्ञों का रहना बेहतर था।" (EWD498 से)

हालाँकि 'प्रोग्रामिंग' से दिक्जस्त्र का मतलब वर्तमान उपयोग से काफी अलग है, फिर भी इस उद्धरण में कुछ योग्यता है। अन्य उत्तरों ने पहले ही उल्लेख किया है कि गणित में अमूर्तता का स्तर प्रोग्रामिंग की तुलना में बहुत अधिक होने की अनुमति है, जिसका अर्थ है कि हम कुछ पेचीदा भागों को अनदेखा कर सकते हैं यदि हम ऐसा करना चाहते हैं।

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

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

तो, आपको आश्चर्यचकित नहीं होना चाहिए कि सही प्रमाण उत्पन्न करना अपेक्षाकृत दोष-सबूत है: यह संपूर्ण "अभ्यास" का बिंदु है। (फिर भी, इसका मतलब यह नहीं है कि गलतियाँ नहीं हैं या बमुश्किल मौजूद हैं, जब तक कि केवल मानव ही नहीं है, वे कहते हैं)

अब, यदि हम प्रोग्रामिंग पर विचार करते हैं, तो हमारा उद्देश्य क्या है? हम वास्तव में समझने की तलाश नहीं करते हैं, हम कुछ ऐसा चाहते हैं जो काम करे । लेकिन जब कुछ "काम" करता है? कुछ काम करता है जब हमने सफलतापूर्वक कुछ ऐसा बनाया है जो कुछ अजीब मशीन को उस कार्य को पूरा करने की अनुमति देता है जिसे हम करना चाहते हैं और अधिमानतः बहुत तेजी से।

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

इसलिए, अंत में, केवल इसे आज़माने के अलावा और कोई रास्ता नहीं होता है और शायद तब तक असफल हो जाते हैं, ठीक कर देते हैं, जब तक कि हम परिणाम से कुछ हद तक संतुष्ट नहीं हो जाते हैं।

---

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

---

जैसा कि @wvxvw ने टिप्पणियों में उल्लेख किया है, 'संरचित प्रोग्रामिंग पर नोट्स' से निम्नलिखित पैराग्राफ (EWD249, पृष्ठ 21) बहुत प्रासंगिक हैं:

(...) एक कार्यक्रम कभी भी अपने आप में एक लक्ष्य नहीं होता है; एक कार्यक्रम का उद्देश्य अभिकलन को निकालना है और अभिकलन का उद्देश्य एक वांछित प्रभाव स्थापित करना है। यद्यपि प्रोग्राम प्रोग्रामर द्वारा बनाया गया अंतिम उत्पाद है, लेकिन इसके द्वारा विकसित संभावित गणनाएं - जिनमें से "बनाने" को मशीन पर छोड़ दिया जाता है! - उसके व्यापार के सच्चे विषय हैं। उदाहरण के लिए, जब भी कोई प्रोग्रामर कहता है कि उसका प्रोग्राम सही है, तो वह वास्तव में उन गणनाओं के बारे में एक जोर देता है, जो उसे हो सकती हैं।

(...) एक अर्थ में एक कार्यक्रम का निर्माण एक गणितीय सिद्धांत बनाने की तुलना में अधिक कठिन है: कार्यक्रम और सिद्धांत दोनों संरचित, कालातीत वस्तुएं हैं। लेकिन जबकि गणितीय सिद्धांत समझ में आता है क्योंकि यह कार्यक्रम केवल इसके निष्पादन के माध्यम से समझ में आता है।

Comments

मैं सिर्फ एक आम आदमी हूं; दिज्क्स्त्र ने वास्तव में "प्रोग्रामिंग" का क्या उल्लेख किया?

— ओवी

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

— छिपकली

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

— wvxvw

@ आपके प्रश्न पर मेरा अनुमान है कि दिज्क्स्ट्रा के समय में प्रोग्रामिंग का अर्थ अक्सर उच्च-स्तरीय भाषाओं का विधानसभा कोड बनाम आधुनिक युग लिखना होता था। इसी प्रकार, मैं १ ९ the४ के पौराणिक कथा-मास का संस्करण पढ़ रहा हूं, अवधारणाएं अभी भी चालू हैं, लेकिन तकनीकी संदर्भ सिस्टम-स्तरीय कोडांतरक या पीएल / I हैं, जो कि अधिकांश लोग आज प्रोग्रामिंग के बारे में सोचते हैं, उससे बहुत अलग हैं

— जिमलोसे

Answer 4

लामपोर्ट प्रमाण में त्रुटियों की व्यापकता पर असहमति के लिए कुछ आधार प्रदान करता है कि कैसे एक प्रमाण लिखना है (पृष्ठ 8-9) :

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

... इस शैली को पहली बार मार्टिन अबादी के साथ लिखे गए एक पेपर में साधारण प्रमेयों के प्रमाणों पर लागू किया गया था। उन्होंने पहले ही पारंपरिक प्रमाण लिख दिए थे- सबूत जो हमें समझाने के लिए पर्याप्त थे और संभवतः, रेफरी। साक्ष्यों को एक संरचित शैली में पुनर्लेखन करते हुए, हमने पाया कि लगभग हर एक में गंभीर गलतियाँ थीं, हालांकि प्रमेय सही थे। कोई भी उम्मीद है कि गलत सबूत गलत प्रमेयों को जन्म नहीं दे सकते हैं जो हमारे अगले सहयोग में नष्ट हो गया था। बार-बार, हम अनुमान लगाते हैं और ब्लैकबोर्ड पर एक प्रूफ स्केच लिखते हैं — एक स्केच जो आसानी से एक कन्वेंशनल ट्रेडिशनल प्रूफ में बदल सकता है - केवल एक स्ट्रक्चर्ड प्रूफ लिखने की कोशिश करके, कि अनुमान गलत था। तब से, मैंने कभी भी सावधानीपूर्वक, संरचित प्रमाण के बिना परिणाम पर विश्वास नहीं किया।

Comments

एक ही पेपर: "एंकोडेटल सबूत बताते हैं कि गणितीय पत्रिकाओं में प्रकाशित सभी पत्रों में से एक तिहाई में गलतियां हैं - न केवल मामूली त्रुटियां, बल्कि गलत प्रमेय और प्रमाण"। ठीक है, यह 90 के दशक में था, लेकिन क्या यह आज अलग है? संभवत: वे कागजात उन दिनों विद्यमान थे, अभी भी मौजूद हैं और सब कुछ ढेर हो गया है ... इसलिए, मुझे पूरी तरह से यकीन नहीं है कि कागजात में प्रदान किए गए गणितीय प्रमाण कम त्रुटियां हैं।

— मार्कोकराम

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

— DW

@ मैं लेस्ली को एक ईमेल संदेश भेजता हूं, अगर वह दावे के लिए और सबूत दे सकता है।

— मार्कोकराम

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

— मार्कोक्राएम

@DW उपाख्यान या दो दर्शाता है कि एक गणितीय प्रमाण "सही" कैसे प्रकट हो सकता है लेकिन वास्तव में निराधार हो सकता है। किसी ऐसे व्यक्ति के लिए जिसने एक जटिल कंप्यूटर एल्गोरिदम लिखा है और एक गणितीय प्रमाण किया है, और एक गणितीय प्रमाण पत्र की तरह एक कंप्यूटर एल्गोरिथ्म लिखने की कोशिश की है और फिर खोज की है कि कैसे उच्च स्तर "एल्गोरिथ्म" को विवरणों में कई, कई बगों द्वारा धोखा दिया जाता है, परिणाम आश्चर्य की बात बिल्कुल नहीं है।

— यमक

Answer 5

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

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

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

Comments

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

— युवल फिल्मस

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

— डेन ब्रायंट

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

— डेरेक एल्किंस

Answer 6

वे कहते हैं कि कंप्यूटर के साथ समस्या यह है कि वे वही करते हैं जो आप उन्हें बताते हैं।

मुझे लगता है कि यह कई कारणों में से एक हो सकता है।

ध्यान दें कि, कंप्यूटर प्रोग्राम के साथ, लेखक (आप) स्मार्ट है लेकिन पाठक (सीपीयू) गूंगा है।
लेकिन गणितीय प्रमाण के साथ, लेखक (आप) स्मार्ट है और पाठक (समीक्षक) भी स्मार्ट है।

इसका मतलब यह है कि आप कभी भी एक "कुएं में नहीं जा सकते, आप जानते हैं कि कंप्यूटर के साथ मेरी स्थिति क्या है "। यह वही करता है जो आप इसे बताते हैं, अपने इरादों को जाने बिना।

उदाहरण के लिए, मान लें कि यह किसी प्रमाण में एक कदम है:

$$\begin{align*} \displaystyle\frac{x^2 + 4x + 3}{x+3} = \displaystyle\frac{(x+1)(x+3)}{x+3} = x+1 \end{align*}$$

यदि आप कंप्यूटर को का मूल्यांकन करने के लिए कहते हैं और फिर इसे x + 3 से विभाजित करते हैं , तो यह x = - 3 को आपके प्रोग्राम पर चोक कर देगा । लेकिन एक गणितज्ञ इस बिंदु पर बेवजह अटक नहीं जाएगा। वह महसूस करेंगे कि यह उस बिंदु के लिए सबसे अधिक संभावनाहीन है जिसे आप बनाने की कोशिश कर रहे हैं, और यह कि इस मामूली मुद्दे के बारे में शिकायत करने से कोई फायदा नहीं होगा। उसे वही मिलेगा जो तुम्हारा मतलब है क्योंकि वह तुम्हारा पीछा नहीं करता है; वह आपको समझता है। जब आपका पाठक स्मार्ट होता है तो असफल होना कठिन होता है।$x^2+4x+3$$x+3$$x = -3$

Comments

बहुत बढ़िया जवाब! सिवाय एक कंप्यूटर के रूप में, मुझे आपके "अनावश्यक" शब्द के उपयोग पर आपत्ति है। ;) [मान लीजिए कि यह साबित करने के लिए एक बड़े सबूत में सिर्फ एक कदम था जो कि -xसमग्र है। तथ्य यह है कि यह कदम गलत है जब -x = 3पूरा सबूत की शुद्धता के लिए अत्यधिक प्रासंगिक है!]

— क्क्सप्लसोन

@Quuxplusone: = पी

— Mehrdad

कंप्यूटर प्रतीकात्मक गणित और गैर-नियतात्मक पुनर्लेखन नियमों का भी उपयोग कर सकते हैं, इसका सिर्फ इतना है कि हम जिन भाषाओं का उपयोग C ++ की तरह करते हैं, वे सभी बहुत ही निम्न स्तर के हैं और प्राचीन तकनीक पर आधारित हैं (उदाहरण के लिए Algol 60 की तुलना में कम विशेषताएं थीं)। एकमात्र अपवाद इदरीस / एजडा जैसी प्रतीकात्मक / जाँच भाषाएं हैं, प्रतीकात्मक सॉल्वर और गणितज्ञ के साथ लिस्प। ja.wolframalpha.com/input/…

— aoeu256

Answer 7

एक मुद्दा जो मुझे लगता है कि युवल के जवाब में संबोधित नहीं किया गया था, यह है कि ऐसा लगता है कि आप विभिन्न जानवरों की तुलना कर रहे हैं।

$n$$n!$

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

मैं युवल को मजबूत करूंगा और कहूंगा कि पूरे क्षेत्र गणितीय प्रमाणों को लिखने की प्रेरणा से बढ़े हैं जिन्हें कुछ औपचारिक प्रणाली में लिखा और सत्यापित किया जा सकता है, इसलिए यहां तक ​​कि सत्यापन प्रक्रिया बिल्कुल भी नहीं है।

Answer 8

दोषपूर्ण गणितीय प्रमाण लिखने और दोषरहित कंप्यूटर कोड लिखने के बारे में ऐसा क्या अलग है जो इसे बनाता है ताकि पूर्ववर्ती उत्तरार्द्ध की तुलना में बहुत अधिक ट्रैफ़िक हो?

मेरा मानना ​​है कि प्राथमिक कारण बेमियादी हैं (समान इनपुट के लिए समान परिणाम देता है) और अपरिवर्तनीयता (परिवर्तन नहीं होता है)।

क्या होगा अगर एक गणितीय प्रमाण अलग परिणाम दे सकता है अगर इसे मंगलवार को पढ़ा गया या जब वर्ष 1999 से 2000 तक उन्नत हो? क्या होगा अगर एक गणितीय प्रमाण का हिस्सा कुछ पृष्ठों को वापस जाना था, कुछ पंक्तियों को फिर से लिखना, और फिर उस बिंदु से फिर से शुरू करना?

मुझे यकीन है कि इस तरह के प्रमाण लगभग कंप्यूटर कोड के एक सामान्य सेगमेंट के रूप में बग के लिए खतरा होंगे।

मैं अन्य माध्यमिक कारकों को भी देखता हूं:

1. गणितज्ञ आमतौर पर एक महत्वपूर्ण / publishable प्रमाण लिखने का प्रयास करने से पहले अधिक शिक्षित होते हैं। स्व-शीर्षक वाले पेशेवर डेवलपर्स के 1/4 ने 6 साल पहले ( एसओ सर्वेक्षण 2017 देखें ) से कम कोडिंग शुरू की थी , लेकिन मुझे लगता है कि अधिकांश गणितज्ञ औपचारिक गणित शिक्षा के एक दशक से अधिक हैं।
2. गणितीय प्रमाण शायद ही कभी कंप्यूटर कोड के समान स्तर पर जांच किए जाते हैं। एक एकल टाइपो एक कार्यक्रम को तोड़ सकता है / कर सकता है, लेकिन एक प्रमाण के मूल्य (बस इसकी पठनीयता) को नष्ट करने के लिए दर्जनों टाइपो पर्याप्त नहीं हो सकते हैं।
3. विवरण में शैतान और कंप्यूटर कोड विवरण को छोड़ नहीं सकते। सबूत ऐसे कदमों को छोड़ने के लिए स्वतंत्र हैं जिन्हें सरल / नियमित माना जाता है। आधुनिक भाषाओं में कुछ अच्छे सिंटैक्टिक शक्कर उपलब्ध हैं, लेकिन ये हार्ड-कोडेड हैं और तुलना में काफी सीमित हैं।
4. गणित पुराना है और एक अधिक ठोस आधार / कोर है। गणित में निश्चित रूप से नए और चमकदार उपक्षेत्रों की अधिकता है, लेकिन अधिकांश मूल सिद्धांत दशकों से उपयोग में हैं। इससे स्थिरता आती है। दूसरी तरफ, प्रोग्रामर अभी भी बुनियादी कोडिंग पद्धति पर असहमत हैं (बस फुर्तीले विकास और इसके गोद लेने की दर के बारे में पूछें)।

Comments

उल्लेखनीय है कि प्रोग्रामिंग की 'इंडम्पोटोटेंसी' के समतुल्य कार्यात्मक पवित्रता है , जिसे यास्केल जैसी कुछ भाषाओं में मान्यता प्राप्त है और समर्थित है।

— चरण

Answer 9

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

इसके विभिन्न कारण हैं। एक यह है कि अधिकांश सॉफ्टवेयर इंजीनियरों के पास गणितीय रूप से समस्याओं को स्पष्ट रूप से तैयार करने का कौशल नहीं है और न ही वे जानते हैं कि शुद्धता प्रमाण कैसे लिखें।

एक और यह है कि एक जटिल सॉफ्टवेयर सिस्टम (विशेष रूप से वितरित एक) के लिए शुद्धता की शर्तों को परिभाषित करना एक बहुत ही कठिन और समय लेने वाला कार्य है। उनसे कुछ ऐसा करने की उम्मीद की जाती है जो हफ्तों के मामले में काम करता है।

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

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

जब लोगों के पास शुद्धता को परिभाषित करने के लिए कौशल नहीं होते हैं और न ही सही प्रोग्राम लिखते हैं और न ही ऐसा करने की अपेक्षा की जाती है और ऐसा करना मुश्किल होता है तो कोई आश्चर्य की बात नहीं है कि सॉफ्टवेअर सही नहीं हैं।

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

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

Comments

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

— डेरेक एलकिंस

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

— केव

Answer 10

बहुत सारे अच्छे उत्तर पहले से ही हैं लेकिन अभी भी अधिक कारण हैं गणित और प्रोग्रामिंग समान नहीं हैं।

1 गणितीय प्रमाण कंप्यूटर प्रोग्राम की तुलना में बहुत सरल होते हैं। काल्पनिक प्रमाण के पहले चरणों पर विचार करें:

आज्ञा देना एक पूर्णांक

आज्ञा देना बी एक पूर्णांक है

चलो सी = ए + बी

अभी तक प्रमाण ठीक है। आइए इसे एक समान कार्यक्रम के पहले चरणों में बदल दें:

एक = इनपुट दो ();

चलो बी = इनपुट ();

चलो c = a + b;

हम पहले से ही समस्याओं का असंख्य है। यह मानते हुए कि उपयोगकर्ता ने वास्तव में एक पूर्णांक दर्ज किया है, हमें सीमाओं की जांच करनी होगी। है एक से अधिक -32,768 (या जो भी मिनट आपके सिस्टम पर पूर्णांक है)? है एक 32767 से भी कम समय? अब हमें b के लिए उसी चीज को जांचना होगा । और क्योंकि हमने a और b को जोड़ दिया है, जब तक कि प्रोग्राम सही नहीं है + b-32768 से अधिक और 32767 से कम है। 5 अलग-अलग स्थितियों में एक प्रोग्रामर को इस बारे में चिंता करनी होगी कि एक गणितज्ञ उपेक्षा कर सकता है। न केवल प्रोग्रामर को उनके बारे में चिंतित होना पड़ता है, उसे यह पता लगाना होता है कि क्या करना है जब उन शर्तों में से एक को पूरा नहीं किया जाता है और कोड को लिख दिया जाता है कि उसने जो भी निर्णय लिया है वह उन परिस्थितियों को संभालने का तरीका है। गणित सरल है। प्रोग्रामिंग कठिन है।

2 प्रश्नकर्ता यह नहीं कहता है कि वह संकलन-समय त्रुटियों या रन-टाइम त्रुटियों का उल्लेख कर रहा है, लेकिन प्रोग्रामर आमतौर पर संकलन-समय त्रुटियों के बारे में परवाह नहीं करते हैं। संकलक उन्हें पाता है और उन्हें ठीक करना आसान होता है। वे टाइपो हैं। पहली बार त्रुटियों के बिना लोग कितनी बार कई पैराग्राफ टाइप करते हैं?

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

Answer 11

मुझे युवल का जवाब पसंद है, लेकिन मैं इसके लिए थोड़ा और अलग होना चाहता था। एक कारण यह हो सकता है कि आपको मैथ के प्रमाण लिखने में आसानी हो सकती है कि मैटल ऑन्कोलॉजी कैसे होती है। यह देखने के लिए कि मेरा क्या मतलब है, निम्नलिखित पर विचार करें:

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

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

Answer 12

मौलिक गणितीय प्रमाण एक वास्तविक विश्व अनुप्रयोग की राशि नहीं है, जिसे जीवित मनुष्यों की जरूरतों को पूरा करने के लिए डिज़ाइन किया गया है।

मनुष्य कंप्यूटर प्रोग्राम के दायरे में दैनिक आधार पर अपनी इच्छाओं, जरूरतों और आवश्यकताओं को बदल देगा।

दोषपूर्ण गणितीय प्रमाण लिखने और दोषरहित कंप्यूटर कोड लिखने के बारे में ऐसा क्या अलग है जो इसे बनाता है ताकि पूर्ववर्ती उत्तरार्द्ध की तुलना में बहुत अधिक ट्रैफ़िक हो?

गणितीय समस्या के रूप में स्पष्ट आवश्यकता के साथ, एक दोषरहित कार्यक्रम लिखा जा सकता है। यह मानते हुए कि दिक्क्स्ट्रा का एल्गोरिथ्म एक बिंदु पर दो बिंदुओं के बीच सबसे छोटा रास्ता खोज सकता है, एक कार्यक्रम को लागू करने के समान नहीं है जो मनमाने ढंग से आदानों को स्वीकार करता है और इसमें किसी भी दो बिंदुओं के बीच सबसे छोटा बिंदु खोजता है।

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

---

या, अधिक रसीला होने के लिए :

Answer 13

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

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

जैसे, कंप्यूटर प्रोग्राम लिखने से पहले 'साबित करना', फिर हार्डवेयर स्तर पर तर्क को साबित करना, ऑपरेटिंग सिस्टम स्तर, ड्राइवर स्तर, प्रोग्रामिंग भाषा, कंपाइलर, शायद दुभाषिया और इतने पर, हार्डवेयर के हर संभव संयोजन के लिए जिसमें प्रोग्राम शामिल हो गर्भ धारण करने पर चलाया जा सकता है और किसी भी बोधगम्य डेटा जो इसे निगलना कर सकता है। आप शायद अंतरिक्ष मिशनों, हथियार प्रणालियों या परमाणु ऊर्जा नियंत्रण प्रणालियों पर तैयारी और समझ के इस स्तर को पा लेंगे, जहां विफलता का मतलब है दसियों अरबों डॉलर का खो जाना और संभवतः कई खोए हुए जीवन, लेकिन बहुत कुछ नहीं।

आपके 'रोजमर्रा के' प्रोग्रामर और / या व्यवसाय के लिए, यह कहीं अधिक प्रभावी है, एक निश्चित स्तर की सटीकता को ज्यादातर-सही कोड में स्वीकार करने और एक प्रयोग करने योग्य उत्पाद को बेचने के लिए प्रभावी है, और डेवलपर्स पूर्वव्यापी रूप से कीड़े को ठीक कर सकते हैं क्योंकि वे इसके दौरान उजागर होते हैं। उपयोग।

Comments

आपको लगता है कि गणित क्या है के बारे में एक संकीर्ण दृष्टिकोण है और एक कंप्यूटर प्रोग्राम को "साबित" करने के लिए बहुत दूर तक फैला हुआ दृश्य है। आपको किसी प्रोग्राम को सही साबित करने के लिए पूरे सिस्टम को सही साबित करने की जरूरत नहीं है, आपको सिर्फ यह साबित करने की जरूरत है कि यह सही है कि दूसरे कंपोनेंट उनके स्पेसिफिकेशन को पूरा करें। यदि वे नहीं करते हैं, तो यह आपके कार्यक्रम की गलती नहीं है। दूसरी ओर, यदि आपका प्रोग्राम टूट जाता है क्योंकि यह उन विवरणों पर निर्भर करता है जो उन घटकों के विनिर्देश का हिस्सा नहीं हैं, उदाहरण के लिए IEEE754 के कार्यान्वयन के रूपांतर हैं, तो यह आपकी गलती है।

— डेरेक एल्किंस

निष्पक्ष टिप्पणी। मैं संभवतः अपनी अकादमिक पृष्ठभूमि के रूप में कुछ शब्दावली का दुरुपयोग कर रहा हूं। हालांकि मुझे लगता है कि यह मानना ​​कि अन्य घटक निर्दोष हैं, मेरी पिछली टिप्पणियों के कारण, यह एक बुद्धिमान बात नहीं है।

— नाविक_

Answer 14

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

फिर भी हमें गणनाओं को इस तरह व्यवस्थित करना चाहिए कि हमारी सीमित शक्तियां इस बात की गारंटी देने के लिए पर्याप्त हों कि गणना वांछित प्रभाव स्थापित करेगी। इस आयोजन में कार्यक्रम की संरचना शामिल है और वहाँ हमें आकार, अर्थात की अगली समस्या का सामना करना पड़ रहा है। कार्यक्रम पाठ की लंबाई, और हमें इस समस्या को भी स्पष्ट मान्यता देनी चाहिए। हमें इस तथ्य से अवगत रहना चाहिए कि हम एक पाठ को किस हद तक पढ़ या लिख ​​सकते हैं, यह उसके आकार पर बहुत अधिक निर्भर करता है। [...]

यह उसी मूड में है कि मुझे इस तथ्य पर पाठक का ध्यान आकर्षित करना चाहिए कि "स्पष्टता" ने मात्रात्मक पहलुओं का उच्चारण किया है, एक तथ्य जो कई गणितज्ञों, उत्सुकता से पर्याप्त है, अनजान लगते हैं। एक थ्योरी एक निष्कर्ष की वैधता बताते हुए जब शर्तों से भरे दस पेज संतुष्ट हैं, तो शायद ही एक सुविधाजनक उपकरण है, जब भी प्रमेय की अपील की जाती है, तो सभी स्थितियों को सत्यापित करना होगा। यूक्लिडियन ज्यामिति में, पाइथागोरस की प्रमेय किन्हीं तीन बिंदुओं A, B और C के लिए है, जैसे A और C के माध्यम से B और C. के माध्यम से एक सीधी रेखा को orthogonal खींचा जा सकता है। कितने गणितज्ञ इस बात की सराहना करते हैं कि प्रमेय तब लागू होता है जब कुछ या सभी बिंदुओं A, B और C का संयोग? अभी तक यह उस सुविधा के लिए काफी हद तक जिम्मेदार है जिसके साथ पाइथागोरस प्रमेय का उपयोग किया जा सकता है।

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

यह दिज्क्स्ट्रा के संरचित प्रोग्रामिंग के पहले अध्याय से पिछले तीन पैराग्राफों को थोड़ा संपादित किया गया है।

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

Comments

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

— युवल फिल्मस

@YuvalFilmus बोली की तरह: मनुष्यों के लिए मुख पृष्ठ के दस पृष्ठ लंबे हैं। मैं एक कार्यक्रम की लंबाई के बारे में कैसे आंकता हूं? खैर, डिक्स्ट्रा ने एक मीट्रिक की पेशकश की: इसके पाठ की लंबाई। मुझे लगता है कि यह बहुत सरल हो सकता है, लेकिन फिर भी यह एक अच्छा अनुमान है। उदाहरण के लिए, अन्य, अधिक दिलचस्प मैट्रिक्स हैं, जैसे, चक्रीय जटिलता

— wvxvw

Answer 15

जैसा कि उनके उत्तरों में अन्य उत्तर छुआ है (मैं विस्तृत करना चाहता हूं), लेकिन समस्या का एक बड़ा हिस्सा पुस्तकालय उपयोग है। यहां तक ​​कि सही दस्तावेज के साथ (बगैर कोड के सामान्य), लाइब्रेरी का उपयोग करके प्रत्येक प्रोग्रामर को पुस्तकालय का पूरा ज्ञान हस्तांतरित करना असंभव है। यदि प्रोग्रामर पूरी तरह से अपने पुस्तकालय को नहीं समझता है, तो वे इसका उपयोग करते समय गलतियां कर सकते हैं। कभी-कभी ये महत्वपूर्ण बग हो सकते हैं जो कोड के काम न करने पर खोजे जाते हैं। लेकिन मामूली कीड़े के लिए, ये किसी का ध्यान नहीं जा सकता है।

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

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

Comments

रुको, आपको क्या लगता है कि गणितज्ञ "सबूतों और लेम्स" को पूरी तरह से समझते हैं जो वे उपयोग करते हैं? मुझे यकीन नहीं है कि गणितज्ञ और प्रोग्रामर के बीच क्या अंतर है जिसे आप यहां प्रदर्शित करने की कोशिश कर रहे हैं।

— डेरेक एलकिंस

Answer 16

मैं उन सभी शानदार उत्तरों के बाद मूल बनने की कोशिश करूँगा।

कार्यक्रम कर रहे हैं सबूत

करी-हावर्ड समाकृतिकता हमें बताता है, अपने कार्यक्रम में प्रकार प्रमेयों कर रहे हैं और वास्तविक कोड उनके सबूत है।

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

एक साइड नोट के रूप में: "धाराओं का संगीत" दोनों के बीच सबसे सुंदर पुलों में से एक है। यह मूल रूप से कहने के लिए सक्षम होने के लिए चीजों को सेट "मैं चाहता हूँ इस में है कि जिस तरह से" और मशीन जादुई करता है यह बिल्कुल के रूप में वांछित।

Comments

मैं पूरी तरह से नहीं देख रहा हूँ कि क्या यह सवाल का समाधान है। ओपी ने कोई संकेत नहीं दिया कि वे शक्तिशाली प्रकार की प्रणालियों के साथ प्रोग्रामिंग भाषाओं के बारे में बात कर रहे थे, और मुझे लगता है कि उनका मतलब अधिक सामान्य प्रकार की प्रणालियों से है। तो इस मामले में करी-हावर्ड एक तरह से तुच्छ है।

— ६००५

मुझे पता है कि यह सी या इसी तरह की चीजों के लिए थोड़ी दूर है। लेकिन मेरा कहना है: गणित एक ठेठ सीएस शुरुआत की तुलना में करीब हो सकता है!

— ओलेग लोबचेव

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

— छिपकली

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

— डेरेक एलकिंस

Answer 17

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

$\pi$

Comments

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

— असतत छिपकली

@Discretelizard, हाँ, विशेष पैकेज मनमानी परिशुद्धता के साथ मौजूद हैं, लेकिन फिर भी, उपलब्ध स्मृति वास्तविक प्राप्त परिशुद्धता को सीमित करेगी। इसके अलावा वे विशेष पैकेज हैं। प्रोग्रामिंग का केवल एक छोटा सा हिस्सा ऐसे पैकेजों के साथ किया जाता है, और ज्यादातर एक अकादमिक सेटिंग में।

— crobar

$\pi$

@Discretelizard, मुझे लगता है कि मेरी बात अभी भी कायम है, ज्यादातर प्रोग्रामर ऐसे CAS सिस्टम का उपयोग नहीं कर रहे हैं। वे वास्तविक दुनिया की प्रोग्रामिंग के लिए बहुत धीमी हैं। अधिकांश प्रोग्रामिंग मूल रूप से सीमित सटीक संख्याओं पर संचालन शामिल है। शीर्ष भाषाएँ C, C ++, Python, Java आदि हैं, कोई भी डिफ़ॉल्ट रूप से CAS शैली प्रतिनिधित्व का उपयोग नहीं करता है (हालाँकि ऐसा करने के लिए पैकेज उनमें बनाए जा सकते हैं)। आपका प्रतिसाद कंप्यूटर भाषाओं / प्रणालियों का एक छोटा सा आला सबसेट है।

— crobar

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

— डेरेक एलकिंस

Answer 18

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

उदाहरण के लिए, यदि हम गणितीय प्रमाण को ZFC जैसी औपचारिक भाषा में अनुवाद करने का प्रयास करते हैं, तो इसमें बग भी होंगे। ऐसा इसलिए है क्योंकि ये प्रमाण वास्तव में लंबे समय तक मिल सकते हैं, इसलिए हमें प्रमाण बनाने के लिए एक कार्यक्रम लिखने के लिए मजबूर किया जाता है। कुछ लोग अपने जोखिम पर, मुसीबत में जाते हैं, हालांकि मूलभूत प्रमाणों को औपचारिक रूप देने में सक्रिय अनुसंधान होता है।

और वास्तव में, गणित बीएसओडी प्राप्त कर सकता है! यह पहली बार नहीं होगा!

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

यहाँ फ्लिप पक्ष है। देखिए, हमने पहले ही फंडिंग प्राप्त कर ली है, व्यापार अवधारणा को मान्य कर दिया है, सभी दस्तावेज आपके लिए पढ़ने के लिए यहीं हैं। हमें बस आपको निष्पादित करने की आवश्यकता है और यह एक निश्चित बात है!

आइए हिल्बर्ट के लिए भी खेद महसूस न करें , वह जानता था कि वह क्या कर रहा था। यह सिर्फ व्यवसाय है।

यदि आप वास्तव में निश्चित होना चाहते हैं, तो केस-बाय-केस आधार पर सब कुछ लें और अपना निष्कर्ष निकालें!

Answer 19

मुझे दो महत्वपूर्ण कारण दिखाई देते हैं कि गणित के प्रमाण की तुलना में प्रोग्राम अधिक त्रुटि वाले क्यों होते हैं:

1: कार्यक्रमों में समय के साथ परिवर्तनशील या गतिशील वस्तुएं होती हैं, जबकि प्रमाणों में गणितीय वस्तुएं सामान्य रूप से स्थिर होती हैं। इस प्रकार, गणित में अंकन का उपयोग तर्क के प्रत्यक्ष समर्थन के रूप में किया जा सकता है, (और यदि a = b, तो यह मामला रहता है) जहां यह कार्यक्रमों में काम नहीं करता है। इसके अलावा, यह समस्या और भी बदतर हो जाती है जहां कार्यक्रम समानांतर होते हैं या कई थ्रेड होते हैं।

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

Answer 20

आपको दो अलग-अलग "श्रेणियों" में अंतर करना चाहिए:

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

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

Answer 21

मुझे संदर्भ नहीं मिल रहा है, लेकिन मुझे लगता है कि टोनी होरे ने एक बार निम्नलिखित पंक्तियों के साथ कुछ कहा था: एक कार्यक्रम की जाँच करने और एक प्रमाण की जाँच करने के बीच का अंतर यह है कि एक प्रमाण को एक बार में दो पंक्तियों की जाँच की जा सकती है।

एक शब्द में: स्थानीयता।

प्रमाण लिखे जाते हैं ताकि उन्हें आसानी से जांचा जा सके। प्रोग्राम लिखे जाते हैं ताकि उन्हें निष्पादित किया जा सके। इस कारण से, प्रोग्रामर आमतौर पर ऐसी जानकारी को छोड़ देते हैं जो प्रोग्राम की जाँच करने वाले किसी व्यक्ति के लिए उपयोगी होगी।

इस कार्यक्रम पर विचार करें, जहां 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)

इसे निष्पादित करना आसान है, लेकिन जांचना मुश्किल है।

लेकिन अगर मैं लापता दावे में वापस जोड़ता हूं, तो आप स्थानीय स्तर पर कार्यक्रम की जांच कर सकते हैं कि असाइनमेंट का प्रत्येक अनुक्रम अपने पूर्व और पश्चात के पश्चाताप के साथ सही है और प्रत्येक लूप के लिए, लूप का पोस्टकॉन्डेंस निहित है। अपरिवर्तनीय और लूप गार्ड की उपेक्षा।

    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)

मूल प्रश्न पर वापस आ रहे हैं: क्यों गणितीय प्रमाणों को लिखना कंप्यूटर कोड लिखने की तुलना में अधिक दोषपूर्ण है? चूँकि प्रमाणों को उनके पाठकों द्वारा आसानी से जाँचने के लिए डिज़ाइन किया गया है, इसलिए वे आसानी से अपने लेखकों द्वारा जाँच लिए जाते हैं और इस प्रकार सतर्क लेखक अपने प्रमाणों में तार्किक त्रुटियों को कम से कम (या कम से कम रखने) नहीं करते हैं। जब हम कार्यक्रम करते हैं, तो हम अक्सर इस कारण को लिखने में असफल होते हैं कि हमारा कोड सही है; परिणाम यह है कि कोड की जांच करने के लिए एक प्रोग्राम के पाठकों और लेखक दोनों के लिए यह कठिन है; परिणाम यह होता है कि लेखक त्रुटियां करते हैं (और फिर रख देते हैं)।

लेकिन उम्मीद है। यदि, जब हम कोई प्रोग्राम लिखते हैं, तो हम इस कारण को भी लिखते हैं कि हमें लगता है कि प्रोग्राम सही है, हम फिर कोड की जांच कर सकते हैं क्योंकि हम इसे लिखते हैं और इस प्रकार कम बगिया कोड लिखते हैं। इसका यह लाभ भी है कि अन्य हमारे कोड को पढ़ सकते हैं और इसे अपने लिए जांच सकते हैं।

Answer 22

हम पूछ सकते हैं कि क्या प्रैक्टिस में , या सिद्धांत रूप में , प्रमाण लिखना या कोड लिखना अधिक कठिन है ।

व्यवहार में, कोडिंग की तुलना में साबित करना बहुत कठिन है। बहुत कम लोग जिन्होंने दो साल का कॉलेज स्तर का गणित लिया है, वे प्रमाण लिख सकते हैं, यहाँ तक कि तुच्छ भी। जिन लोगों ने कॉलेज स्तर के सीएस के दो साल ले लिए हैं, उनमें से शायद कम से कम 30% FizzBuzz को हल कर सकते हैं ।

लेकिन सिद्धांत रूप में , मूलभूत कारण हैं कि यह दूसरा तरीका क्यों है। सबूत, कम से कम सिद्धांत रूप में, एक प्रक्रिया के माध्यम से शुद्धता के लिए जाँच की जा सकती है जिसे किसी भी निर्णय की आवश्यकता नहीं है या जो भी समझ में आता है। प्रोग्राम नहीं कर सकते हैं - हम किसी भी निर्धारित प्रक्रिया के माध्यम से यह भी नहीं बता सकते हैं कि क्या कोई कार्यक्रम रुक जाएगा।

Comments

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

— डेरेक एल्किंस

हम उसी तरह से प्रोग्राम लिख सकते थे। आप एक आवश्यकता की कल्पना कर सकते हैं कि आपके द्वारा लिखे गए प्रत्येक फ़ंक्शन / प्रक्रिया को एक औपचारिक विनिर्देश प्रदान करना है और एक सबूत (कोक में, कहना है) कि यह कल्पना को पूरा करता है। फिर उस सबूत को सही तरीके से जांचने के तरीके हैं जिसमें किसी भी फैसले या किसी को समझने की आवश्यकता नहीं है।

— DW

@ डब्लू: आप यह मान रहे हैं कि (1) वांछित व्यवहार पूरी तरह से सभी मामलों में निर्दिष्ट किया जा सकता है, (2) आवश्यक प्रमाण मौजूद है (यानी, समस्या असंदिग्ध नहीं है), और (3) यदि प्रमाण मौजूद है, तो हम इसे पा सकते हैं। मुझे लगता है कि इन तीनों धारणाएं कम से कम कुछ मामलों (शायद लगभग सभी मामलों) में झूठी हैं। पुन: 3, ध्यान दें कि हालांकि कुछ प्रमाण आसान हो सकते हैं, कई प्रमाण बहुत मुश्किल हैं।

— बेन क्राउल

@DerekElkins: मेरा दावा है कि बहुत कम कॉलेज के छात्र भी तुच्छ प्रमाण लिख सकते हैं, यह मेरे अपने छात्रों के साथ अपने अनुभव पर आधारित है। यह एक सामुदायिक कॉलेज में है, इसलिए YMMV। तथ्य यह है कि कुछ हाई स्कूल ज्यामिति कक्षाओं में प्रूफ-राइटिंग की भारी खुराक शामिल है, इस तथ्य का अनुवाद नहीं करती है कि सभी कॉलेज के छात्र प्रूफ लिख सकते हैं। उन्हें यह भी पता होना चाहिए कि मूल बीजगणित कैसे किया जाता है, लेकिन मेरे स्कूल में लगभग आधे ताजे केल् सी के छात्र नहीं कर सकते हैं - जो यह समझाने में मदद करता है कि इतने असफल क्यों हुए।

— बेन क्राउल

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

— DW

Answer 23

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

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

Comments

"केवल गणितीय कथनों का एक छोटा सा हिस्सा जो सच है, व्यावहारिक रूप से सिद्ध हो सकता है।" - आप "भाग" कैसे माप रहे हैं? क्या यह कुछ संभावना वितरण के तहत है? क्या आपके पास इस कथन का समर्थन करने के लिए सबूत हैं?

— DW

"कंप्यूटर को अक्सर उन चीज़ों को करने के लिए कहा जाता है जो उस सीमा से परे हैं जो सही-सही सॉफ़्टवेयर पूरा कर सकते हैं।" - क्या आपके पास इसके लिए कोई सबूत है? आपके पास कोई उदाहरण है? क्या आप यह दावा कर रहे हैं कि "सिद्धांत से परे क्या सही साबित हो सकता है" या "परे जो हम व्यवहार में साबित करने की उचित कल्पना कर सकते हैं"?

— DW

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

— सुपरकैट

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

— Supercat

... विफलताओं के विभिन्न संयोजनों की संभावनाओं को निर्धारित करने के लिए। यदि कोई व्यक्ति 10-500 में एक-एक मिनट की अवधि के दौरान विफलता की संभावना का अनुमान लगाता है, तो एक को परिमाण के सैकड़ों आदेशों से दूर किया जा सकता है और फिर भी एक विश्वसनीय प्रणाली हो सकती है, लेकिन यदि परिमाण के 494 आदेशों में से एक बंद है सिस्टम हर दो साल में एक बार विफल होगा।

— सुपरकाट

Answer 24

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

2. कंप्यूटर प्रोग्राम उपयोगी वास्तविक विश्व कार्य करते हैं। उन्हें ऐसा करने के लिए 100% सही होने की आवश्यकता नहीं है, और शुद्धता के उच्च मानक बहुत महंगे हैं। सबूत केवल तभी उपयोगी होते हैं यदि वे वास्तव में कुछ साबित करते हैं, इसलिए '100% सही' भाग को छोड़ देना गणितज्ञों के लिए एक विकल्प नहीं है।

3. गणितीय प्रमाण स्पष्ट रूप से परिभाषित हैं। यदि कोई प्रमाण त्रुटिपूर्ण है, तो लेखक ने गलती की है। कंप्यूटर प्रोग्राम में कई बग होते हैं क्योंकि आवश्यकताओं का ठीक से संचार नहीं किया गया था, या प्रोग्रामर ने कभी नहीं सुना है कुछ के साथ एक संगतता समस्या है।

4. कई कंप्यूटर प्रोग्राम सही साबित नहीं हो सकते हैं। वे चेहरे को पहचानने जैसी अनौपचारिक रूप से परिभाषित समस्याओं को हल कर सकते हैं। या वे स्टॉक मार्केट पूर्वानुमान सॉफ़्टवेयर की तरह हो सकते हैं और औपचारिक रूप से परिभाषित लक्ष्य हो सकते हैं, लेकिन बहुत सारे वास्तविक दुनिया चर भी शामिल हैं।

Answer 25

मानव गतिविधि के रूप में गणित का एक बड़ा हिस्सा डोमेन-विशिष्ट भाषाओं का विकास रहा है, जिसमें मानव के लिए साक्ष्यों का सत्यापन आसान है।

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

यह एक आसान प्रक्रिया नहीं है, और अनुसंधान के मामले में सबसे आगे से निकाले गए लोगों द्वारा देखे जाने वाले अधिकांश प्रमाण गणितीय क्षेत्रों (जैसे बीजगणित और विश्लेषण) में होते हैं, जो सैकड़ों, यदि हजारों नहीं, तो उस वर्ष के दौरान हुए हैं, जिस क्षेत्र में उस क्षेत्र की धारणा है। उस बिंदु तक परिष्कृत किया गया है जहां वास्तव में सबूतों को लिखने का कार्य एक हवा की तरह लगता है।

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

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

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

Answer 26

आप यहां सेब और संतरे की ईमानदारी से तुलना कर रहे हैं। दोष-प्रूफ और बग-मुक्त एक ही बात नहीं है।

एक कार्यक्रम संख्या तुलना हैं 2और 3और यह कहा गया है कि 2 is greater than 3, तो यह एक गाड़ी कार्यान्वयन की वजह से हो सकता है:

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

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

Comments

एक कार्यक्रम में "गलती" की आपकी परिभाषा क्या है?

— user56834

Answer 27

a) क्योंकि कंप्यूटर प्रोग्राम गणित के प्रमाणों से अधिक बड़े हैं

a.1) मेरा मानना ​​है कि गणित के प्रूफ की तुलना में जटिल कंप्यूटर प्रोग्राम को लिखने के दौरान अधिक लोग उपयोग करते हैं। इसका मतलब है कि गलती मार्जिन अधिक है।

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

ग) क्योंकि आप COMP विज्ञान में "गहन" ज्ञान के बिना प्रोग्रामर हो सकते हैं, इस बीच यह गणित में करना मुश्किल होगा (मुझे विश्वास है)

इसके अतिरिक्त:

नासा:

यह सॉफ्टवेयर बग-फ्री है। यह एकदम सही है, जैसा कि इंसानों ने हासिल किया है। इन आँकड़ों पर विचार करें: कार्यक्रम के अंतिम तीन संस्करण - प्रत्येक 420,000 लंबी लाइनें - प्रत्येक में सिर्फ एक त्रुटि थी। इस सॉफ्टवेयर के अंतिम 11 संस्करणों में कुल 17 त्रुटियां थीं।

ग्लोबल पोजिशनिंग सैटलाइट्स के साथ नेविगेट करने के लिए शटल को अनुमति देने के लिए सॉफ़्टवेयर के अपग्रेड को लें, एक बदलाव जिसमें प्रोग्राम का सिर्फ 1.5% या कोड की 6,366 लाइनें शामिल हैं। उस बदलाव के लिए विनिर्देशों में 2,500 पृष्ठ हैं, जो फोन बुक की तुलना में अधिक मोटा है। वर्तमान कार्यक्रम के लिए विनिर्देश 30 खंडों को भरते हैं और 40,000 पृष्ठ चलाते हैं।

https://www.fastcompany.com/28121/they-write-right-stuff

Comments

"कंप्यूटर प्रोग्राम गणित के प्रमाणों की तुलना में वाया बड़े होते हैं" जो कार्यक्रम और प्रमाण पर निर्भर करता है। और इसमें से बहुत ज्यादा सट्टा लगता है।

— डेविड रिचेर्बी

@DavidRicherby अच्छी तरह से मेरे मन में लास्ट फर्मट के प्रमेय और NASA के अपोलो github.com/chrislgarry/Apollo-11 math.wisc.edu/~boston/869.pdf जैसी चीजें थीं - और हम ऑपरेटिंग सिस्टम और इतने पर भी बात नहीं कर रहे थे।

— निर्गमन

Answer 28

मूल स्तर:

आइए चीजों को सबसे सरल और सबसे बुनियादी स्तर पर देखें।

गणित के लिए, हमारे पास:
2 + 3 = 5 है

मुझे इस बारे में पता चला कि जब मैं बहुत छोटी थी, तब बहुत छोटी थी। मैं सबसे बुनियादी तत्वों को देख सकता हूं: दो वस्तुएं, और तीन वस्तुएं। महान।

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

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

इसके अलावा, अगर हम असेंबली को देखते हैं (जो आमतौर पर लोगों के समान निम्न स्तर का होता है), प्रत्येक व्यक्तिगत कदम को आमतौर पर उन लोगों द्वारा समझा जा सकता है जिन्हें प्रशिक्षित किया गया है और उनके पास उस कदम की व्याख्या करने के लिए संसाधन हैं। इस अर्थ में, उच्च स्तरीय भाषा की तुलना में असेंबली बहुत सरल है। हालांकि, असेंबली इतनी सरल है कि जटिल कार्य, या यहां तक ​​कि औसत दर्जे का कार्य करना, बहुत थकाऊ है। ऊपरी स्तर की भाषाएँ हमें इससे मुक्त करती हैं।

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

आधुनिकीकरण:

क्या आप 286 के लिए कोड चलाते हैं? या आप 64-बिट कोड चलाते हैं?

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

प्रयुक्त उपकरणों के मानक:

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

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

अन्य मामलों में, कभी-कभी केवल यह पता लगाने के बाद कि कोई वस्तु कैसे व्यवहार करती है, मैंने पाया है कि ऑब्जेक्ट (ऑपरेटिंग सिस्टम के साथ बंडल) छोटी गाड़ी है, और यह एक ज्ञात मुद्दा है कि Microsoft ने जानबूझकर तय नहीं किया जाएगा ।

ऐसे परिदृश्य में, क्या मैं OpenBSD पर भरोसा करता हूं, जो कि 10+ वर्षों में "केवल दो दूरस्थ छेद" के प्रसिद्ध सुरक्षा रिकॉर्ड के साथ, एक नियमित आधार पर (एक वर्ष में दो बार) नए मास्टर-शेड्यूल बनाने वाले मास्टरफुल प्रोग्रामर्स द्वारा बनाया गया है? (यहां तक ​​कि उनके पास कम गंभीर मुद्दों के लिए इरेटा पैच है।) नहीं, किसी भी तरह से नहीं। मैं इस तरह के उच्च गुणवत्ता वाले उत्पाद पर भरोसा नहीं करता, क्योंकि मैं ऐसे व्यवसाय के लिए काम कर रहा हूं जो उन व्यवसायों का समर्थन करता है जो उन मशीनों के साथ लोगों की आपूर्ति करते हैं जो माइक्रोसॉफ्ट विंडोज का उपयोग करते हैं, इसलिए मेरे कोड को काम करने की आवश्यकता है।

व्यावहारिकता / उपयोगिता की आवश्यकता है कि मैं उन प्लेटफार्मों पर काम करता हूं जो लोगों को उपयोगी लगते हैं, और यह एक ऐसा मंच है जो सुरक्षा के लिए प्रसिद्ध है (भले ही सहस्राब्दी के शुरुआती दिनों से जबरदस्त सुधार किए गए हैं जो एक ही कंपनी के उत्पाद बहुत खराब थे) ।

सारांश

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

ऑफहैंड, मुझे याद आ रहा है कि कुछ बहुत ही उपयोगी और लोकप्रिय कार्य कितने कम थे, जब मैंने स्ट्रलेन और स्ट्रैपी के लिए कुछ स्रोत कोड देखे। उदाहरण के लिए, स्ट्रलेन कुछ ऐसा हो सकता है जैसे "int strlen (char * x) {char y = x; जबकि ( (y ++)); return (yx) -1;};"

हालाँकि, सामान्य कंप्यूटर प्रोग्राम इससे अधिक लंबे होते हैं। इसके अलावा, बहुत सारे आधुनिक प्रोग्रामिंग अन्य कोड का उपयोग करेंगे जो कम अच्छी तरह से परीक्षण किया जा सकता है, या यहां तक ​​कि छोटी गाड़ी के रूप में भी जाना जाता है। आज की प्रणालियाँ इस बात की तुलना में अधिक विस्तृत हैं कि आसानी से किस माध्यम से सोचा जा सकता है, सिवाय हाथ-पांव के बहुत सारे मिनुतिया को छोड़कर "निचले स्तरों द्वारा संकलित विवरण" के रूप में।

यह अनिवार्य जटिलता, और जटिल और यहां तक ​​कि गलत प्रणालियों के साथ काम करने की निश्चितता, कंप्यूटर प्रोग्रामिंग को बहुत सारे गणित की तुलना में सत्यापित करने के लिए बहुत सारे हार्डवेयर बनाता है जहां चीजें बहुत सरल स्तरों तक उबालने के लिए होती हैं।

जब आप गणित में चीजों को तोड़ते हैं, तो आपको व्यक्तिगत टुकड़े मिलते हैं जिन्हें बच्चे समझ सकते हैं। ज्यादातर लोग गणित पर भरोसा करते हैं; कम से कम बुनियादी अंकगणित (या, कम से कम, गिनती)।

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

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

Comments

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

— छिपकली

$2+3=5$

मेटा नोट: यदि आप एक चीज़ के विशेषज्ञ हैं और दूसरे में एक विशेषज्ञ शुरुआत (या कम), तो आप दोनों की तुलना करने के लिए सबसे खराब स्थिति में हैं।

— राफेल

असतत छिपकली - यह कंप्यूटर साइंस एसई है। इसके अलावा, वास्तव में अन्य उत्तर पढ़ने से पहले मैंने पोस्ट किया, मुझे ऐसा लगा जैसे वे कंप्यूटर पर गणित से ज्यादा छूते हैं। मैंने महसूस किया कि मेरा उत्तर केवल शब्दों को जोड़ने के लिए लंबे समय तक नहीं बनाने से बेहतर था जो कि कहीं और लिखा गया था। /// स्क्रैच के लिए, उच्च स्तर अधिक जटिल है, सरल नहीं है (जब सभी चलती भागों को पूरी तरह से समझने के परिप्रेक्ष्य में देखा जाता है)। इस दृष्टिकोण से, जिसे मैं लिख रहा था, असेंबली अन्य परतों के ऊपर स्क्रैच की तुलना में सरल है (इलेक्ट्रॉनिक नंद द्वार अभी तक सरल है)

— TOOGAM

Answer 29

गणितीय प्रमाण में "क्या" ज्ञान और कार्यक्रमों का वर्णन है "कैसे" ज्ञान "।

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

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

एक प्रमाण में, कोई भी बदलते राज्य नहीं है। चर्चा की परिभाषाएँ और वस्तुएँ निश्चित हैं। साबित करने के लिए आम तौर पर समस्या के बारे में सोचने और बहुत सारे मामलों पर विचार करने की आवश्यकता होती है, लेकिन उन मामलों को परिभाषाओं द्वारा तय किया जाता है।

Comments

मैं कहूंगा कि गणितीय प्रमाण 'क्या' ज्ञान का वर्णन करने में पूरी तरह से सक्षम हैं: उदाहरण के लिए कोई भी प्रमाण जो अस्तित्व को साबित करने के लिए एक उदाहरण का निर्माण करता है या किसी मूल्य की गणना करने की विधि। फिर भी, मैं मानता हूं कि राज्य प्रमाणों में कुछ अनुपस्थित है, इस अर्थ में कि लेखक (या पाठक) द्वारा स्पष्ट रूप से वर्णित के अलावा कोई राज्य नहीं है। यह वास्तव में यह स्थिति है जो एक प्रोग्राम को कुछ करने की अनुमति देता है पाठक / लेखक इससे अनजान है, जबकि एक प्रमाण में यह असंभव है। (निश्चित रूप से, सबूतों में अनायास ही विशेषताएं या परिणाम हो सकते हैं, लेकिन उन्हें प्राप्त करने के लिए अभी भी कुछ सक्रिय सोच की आवश्यकता है)

— असतत छिपकली

@Discretelizard यह एक उपयोगी टिप्पणी है। मुझे लगता है कि "क्या" और "कैसे" के बीच की रेखा निश्चित रूप से फजी है। एक एल्गोरिथ्म को साबित करना आपको लगता है कि यह क्या करता है, वास्तव में मेरे दिमाग में "कैसे" का वर्णन नहीं है, इसके कुछ गुणों को रखने की गारंटी है। दार्शनिक दृष्टिकोण से, मुझे लगता है कि "कैसे" ज्ञान के लिए दुनिया के साथ एक पत्राचार की आवश्यकता होती है। कार्यक्रम हमेशा वही करते हैं जो आप उन्हें बताते हैं। जब आपके पास एक बग होता है जो आपने उसे बताया था कि वह दुनिया के साथ मेल नहीं खाता (जो आप मॉडलिंग कर रहे हैं)। गणित, एक आवेदन से स्वतंत्र (जैसे भौतिकी समस्याओं) सभी सुसंगतता पर निर्भर करते हैं।

— जस्टिन मीनर्स