क्या हम गारंटी दे सकते हैं कि कोई कार्यक्रम कभी गलत नहीं होगा?

10

हमारे यहां एक सिस्टम है। हाल ही में सिस्टम द्वारा उत्पन्न रिपोर्ट में संख्या में से एक में एक गलत गणना है। हमारे अनुभव के माध्यम से, हमने कुछ वर्षों तक इस प्रणाली में किसी भी समस्या / त्रुटि का सामना नहीं किया है।

क्योंकि इस प्रणाली के लेखक पहले ही जा चुके थे, हम शायद ही कार्यक्रमों का पता लगा सकें। लेकिन हमने इनपुट डेटा, सेटिंग को सत्यापित किया है और वे सही हैं।

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

मैं मानता हूं कि मेरा विचार काफी पागल है, लेकिन मैं सिर्फ जानना चाहता हूं, हम कैसे जान सकते हैं कि समस्या कार्यक्रम और इनपुट के कारण नहीं है, लेकिन कुछ अन्य कारक हैं?

PS इस पागल प्रणाली का कोई लॉग नहीं है।

debugging

— lamwaiman1988
स्रोत

8

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

— user281377

16

हां, इसे हटाकर

— स्टीवन ए। लोवे

6

हार्डवेयर के कुछ टुकड़ों में वास्तव में बग होते हैं। यह दिन के चीपमेकर्स के लिए एक वसीयतनामा है कि वे इतने कम हैं। मुझे पहले सॉफ़्टवेयर पर संदेह होगा।

किसी प्रोग्राम के गलत होने का हमेशा एक तार्किक कारण होता है। एक स्लैम एक तार्किक कारण है।

— मौविसील

2

आपके पास एक सांख्यिकीय बम, या एक दुर्भावनापूर्ण संकलक, या खराब राम, डिस्क, या एक वायरस हो सकता है जो आपके राम को लिख सकता है या ओएस, या ओएस बग, या किसी लाइब्रेरी में बग, या प्रसिद्ध मर्ज सॉर्ट बग को संशोधित कर सकता है, या ...

— जॉब

8

मैं कहूंगा कि नहीं!

सिद्धांत रूप में उत्तर नहीं है, हम केवल इसके लिए परीक्षण कर सकते हैं: -

कुछ सीमित वातावरण।
कुछ सीमित समयसीमा।
कुछ सीमित संख्या में परीक्षण मामले।

यह पर्यावरण, समय और मामलों की कुल संभावित संख्या से काफी कम है, जो कार्यक्रम के अपने जीवनकाल में सामना कर सकते हैं। इसके अलावा, हमारे पास भविष्य के बारे में बहुत कम जानकारी है कि क्या आपको 10,000% मुद्रास्फीति के साथ प्रोग्राम करना चाहिए, क्या आपका कार्यक्रम सुपर डुपर 31 नए बिट आर्किटेक्चर के साथ सामना करना चाहिए?

सिद्धांत अनुभव द्वारा समर्थित है जो मैंने व्यक्तिगत रूप से सामना किया है: -

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

— जेम्स एंडरसन
स्रोत

मैं कहता हूं, एक प्रावधान के साथ - यदि आपके पास एक बहु-सूत्रण है। कभी "रेस कंडीशन" के बारे में सुना।

— मटनज

6

सिद्धांत रूप में, यदि आप समान स्थिति से शुरू करते हैं, तो परिणाम समान होगा। वास्तव में, "सर्वर आकार" उपकरण में समान प्रारंभिक स्थिति का आश्वासन देना बहुत असंभव है।

असिंचित चर ले लो। इस कोड को देखें:

  short i;

  if(i==-1)
  {
        //do something special
  }
  else
  {
        i=0;
        //do something else
  }

यह 65536 रन में एक बार अप्रत्याशित परिणाम देगा। और जब तक आप आश्वासन नहीं देंगे कि स्मृति प्रत्येक रन से पहले उसी स्थिति में iहोगी , पूरी तरह से यादृच्छिक होगी।

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

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

— एस एफ।
स्रोत

6

अब मेरा प्रश्न यह है कि क्या बिना किसी तार्किक कारण के कंप्यूटर प्रोग्राम अचानक गलत हो जाएगा?

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

आपके मामले में, मुझे लगता है कि समस्या हो सकती है (और आमतौर पर) वह नहीं जो मैंने ऊपर वर्णित किया है। समस्या यह हो सकती है कि:

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

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

यदि मैं सर्वर मशीन पर स्लैम करता हूं, तो क्या वह संख्या जो कंप्यूटर की गणना कर रही है, एक और संख्या बन जाएगी और गणना को गलत कर देगा?

उत्तर सामान्य रूप से नहीं है, सॉफ्टवेयर उस अर्थ में नाजुक नहीं है।

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

स्मृति भ्रष्टाचार त्रुटियों के बारे में अद्यतन जानकारी: कृपया स्मृति भ्रष्टाचार देखें

— कोई मौका नहीं
स्रोत

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

— 7

3

आधुनिक ऑपरेटिंग सिस्टम अन्य कार्यक्रमों से संबंधित मेमोरी को संशोधित (या यहां तक कि पढ़ने) की अनुमति नहीं देते हैं।

— Péter Török

हां, आधुनिक OSes उस प्रकृति की किसी भी चीज़ की अनुमति नहीं देते हैं।

— डेडएमजीन ऑक्ट

"च आपके पास एक ही कंप्यूटिंग वातावरण है, तो एक प्रोग्राम को इनपुट एक्स दिया जाता है हमेशा उसी परिणाम का उत्पादन करेगा आर" मुझे यकीन नहीं है कि यह सच है। क्या होगा यदि स्मृति घटकों में से एक एसआर लैच में से कुछ पहले के भ्रष्टाचार के कारण दो 1 हो जाता है? en.wikipedia.org/wiki/…

— Yam Marcovic

@DeadMG और Péter Török आपकी प्रतिक्रिया के लिए धन्यवाद, मैंने संदेश को संपादित कर दिया है और एक पृष्ठ पर एक संदर्भ जोड़ दिया है जिसमें वर्णन किया गया है कि यह समस्या अभी भी हो सकती है (मुझे पाठ में वर्णित के रूप में पता है, कि यह बहुत ही असंभव है)।

— NoChance

5

क्या आप गारंटी दे सकते हैं कि कार्यक्रम में कोई बग नहीं है और कभी गलत नहीं होगा? नहीं बदकिस्मती से नहीं।

क्या आप यह प्रदर्शित कर सकते हैं कि एक कार्यक्रम में पर्याप्त संख्या में कीड़े हैं जिन्हें खोजने और उन्हें ठीक करने की लागत उस कार्रवाई से लाभ से अधिक है? यह मुझे लगता है जैसे आप पहले से ही है।

एक पुराने आंकड़े को अधिकतम करने के लिए, सभी कार्यक्रम गलत हैं, लेकिन कुछ कार्यक्रम उपयोगी हैं।

— जॉन एन
स्रोत

1

+1 के लिए "सभी प्रोग्राम गलत हैं, लेकिन कुछ प्रोग्राम उपयोगी हैं"

— एक CVn

मुझे नहीं लगता कि यह उत्तर वास्तव में प्रासंगिक है। ऐसा लगता है कि वह पूछ रहा है कि क्या एक सही कार्यक्रम कभी-कभी कुछ पर्यावरणीय दोषों के कारण अप्रत्याशित रूप से संचालित हो सकता है।

— यम मारकोविच

मेरा पूरा कहना यह है कि कोई भी कार्यक्रम कभी भी "सही" नहीं होता है। सब कुछ हमेशा एक कार्य प्रगति पर है, और केवल तब तक ही सही है जब तक यह गलत न हो। कंप्यूटर विज्ञान सब के बाद एक विज्ञान है । मैं देख रहा हूं कि आप क्या कह रहे हैं, और यह अधिक हो सकता है जहां उसके सवाल का फोकस है। हालांकि, मुझे लगता है कि मेरे जवाब को कम करने के बजाय सभी अधिक प्रासंगिक बनाता है।

— जॉन एन

@ हेलनज़िल: मेरा मानना है कि मैंने सफलतापूर्वक "हैलो, वर्ल्ड!" लिखा है। कार्यक्रम और पसंद है। मैंने भी सही उपयोगी प्रोग्राम लिखे हैं (हालाँकि बड़े नहीं हैं)।

— डेविड थोरले

2

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

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

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

— एक CVn
स्रोत

1

अधिकांश (मानक) कंप्यूटिंग नियतात्मक है, मुझे लगता है।

यदि संभव हो, तो इसे एक ही इनपुट डेटा के साथ 1000 या 10000, आदि के बैच को करने के लिए सेट करें, और सत्यापित करें कि परिणाम समान हैं।

सुनिश्चित करें कि गणना में जाने वाले वर्तमान मूल्य कहीं भी एक ओवर-या अंडरफ्लो का कारण बनेंगे (यदि यह एक पुरानी प्रणाली है तो इसका उपयोग लंबे समय तक करने का इरादा नहीं हो सकता है)।

Y2K11 कोई भी?

— jonsca
स्रोत

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

— बजे एक CVn

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

— जोंस्का

1

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

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

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

दूसरे शब्दों में, जबकि हार्डवेयर और OS सही नहीं हो सकता है, आपको संभवतः उस स्तर के विस्तार के बारे में चिंता करने की आवश्यकता नहीं होगी। बस किसी ऐसे व्यक्ति को ढूंढें जो भाषा जानता है, और डिबगर के साथ काम करता है, और अंदर खुदाई करता है।

"सरल स्पष्टीकरण हैं, अन्य चीजें समान हैं, आम तौर पर अधिक जटिल लोगों की तुलना में बेहतर है।" - ओकाम के रेजर का सारांश।

— क्रेग मालोनी
स्रोत

0

हां, एक सिस्टम को हिट करने से एक अस्थायी ओपन-सर्किट (या संभवतः शॉर्ट-सर्किट, हालांकि यह संभवतः कम होने की संभावना है) के कारण भागों को मोड़ और / या स्थानांतरित कर सकता है।

— जेरी कॉफ़िन
स्रोत

0

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

तब से, नहीं।

— ddyer
स्रोत

0

परीक्षण उपस्थिति को दर्शाता है, बग की अनुपस्थिति नहीं है (एद्स्गर डब्ल्यू। दिक्जस्त्र)

यदि आप यह साबित करने की कोशिश कर रहे हैं कि आपका प्रोग्राम सही तरीके से परीक्षण करके काम करता है, तो यह काम नहीं करेगा।

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

— Raku
स्रोत

क्या आपने प्रश्न पढ़ा है?

— विंस्टन इवर्ट

मैंने किया और मैं कह रहा हूं कि वह यह सुनिश्चित करने के लिए परीक्षणों का उपयोग नहीं कर सकता है कि एक कार्यक्रम कभी गलत नहीं होगा। यही उसके सवाल का शीर्षक कहता है, है ना?

— राकू

हां, शीर्षक ऐसा लगता है। शरीर स्पष्ट रूप से नहीं करता है।

— विंस्टन इवर्ट

0

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

इसलिए मुझे नहीं लगता कि यह भी संभव या अपेक्षित है कि कंप्यूटर सॉफ्टवेयर प्रोग्राम हमेशा ऐसा ही व्यवहार करेगा क्योंकि पर्यावरण हमेशा बदल रहा है।

सॉफ़्टवेयर अपेक्षित रूप से लंबे समय तक चल सकता है, लेकिन अंततः या तो होस्ट ओएस सॉफ़्टवेयर में एक छोटा सा बदलाव आएगा, जो प्रोग्राम को प्रश्न में प्रभावित करेगा या हार्डवेयर को महत्व देगा।

मैं वर्तमान कंप्यूटर के बारे में बात कर रहा हूँ।

— SoftwareCarpenter
स्रोत

0

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

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

— dan_waterworth
स्रोत

-1

यह मुश्किल से ही संभव है कि समस्या रैम के विफल होने से होती है, लेकिन यह अपेक्षाकृत (बहुत) संभावना नहीं है। मेमोरी टेस्ट चलाएं, लेकिन कोड के माध्यम से देखने के लिए तैयार रहें।

— जेम्स मैकलियोड
स्रोत

Downvoter करने के लिए - मैंने ऐसा होते देखा है। एक बार।

— जेम्स मैकलेओड