कोड की अभिलेखीय दीर्घायु बढ़ाना

Question

क्या कोड की दीर्घायु सुनिश्चित करने के लिए सर्वोत्तम प्रथाओं की एक प्रकाशित सूची है, जिसमें प्रजनन योग्य वैज्ञानिक परिणामों की ओर एक आँख है? (जैसे ओपन सोर्स, डॉक्यूमेंटेशन प्रैक्टिस, निर्भरता का चयन, भाषा का चयन, वर्चुअल मशीन, आदि)।

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

Comments

भी यह देख Stats.SE पर लंबी अवधि के reproducibility बढ़ाने पर समान प्रश्न

— Jeromy Anglim

Answer 1

TeX की योजनाबद्ध दीर्घायु की बात मन में आती है:

“1977 में उन शुरुआत के बाद से, टीईएक्स अनुसंधान परियोजना जिसे मैंने शुरू किया था, दो प्रमुख लक्ष्यों से प्रेरित था। पहला लक्ष्य गुणवत्ता था: हम ऐसे दस्तावेज़ों का उत्पादन करना चाहते थे जो न केवल अच्छे थे, बल्कि वास्तव में सबसे अच्छे थे। (…) दूसरा प्रमुख लक्ष्य अभिलेखीय था: सिस्टम बनाने के लिए जो मुद्रण प्रौद्योगिकी में यथासंभव परिवर्तन से स्वतंत्र होगा। जब मुद्रण उपकरणों की अगली पीढ़ी के साथ आया, तो मैं सभी समस्याओं को हल करने के बजाय पहले से ही हासिल की गई गुणवत्ता को बनाए रखने में सक्षम होना चाहता था। मैं कुछ ऐसा डिजाइन करना चाहता था जो अभी भी 100 वर्षों में प्रयोग करने योग्य हो। "- डोनाल्ड ई। नुथ: डिजिटल टाइपोग्राफी, पी। 559 ( http://de.wikipedia.org/wiki/TeX से उद्धृत )

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

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

TeX के लिए, 1990 के लेख में ठंड की घोषणा की गई है

TEX और METAFONT का भविष्य http://www.ntg.nl/maps/05/34.pdf

"मैं दृढ़ता से मानता हूं कि अपरिवर्तनीय प्रणाली का बहुत बड़ा मूल्य है, भले ही यह स्वयंसिद्ध है कि किसी भी जटिल प्रणाली में सुधार किया जा सकता है। इसलिए मेरा मानना ​​है कि TEX और METAFONT नामक प्रणालियों में" सुधार "करने के लिए यह नासमझ है। आइए इन के संबंध में विचार करें। सिस्टम same xed अंक के रूप में, जो कि आज से 100 साल पहले के समान परिणाम देते हैं। "

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

यदि मुझे मूल प्रश्न से बहुत अधिक निराशा हो रही है, तो मुझे क्षमा करें। ['साइंटिस्ट्स फॉर रिप्रोड्यूसबल रिसर्च' से प्रेषित क्रॉस, [e-mail]]

Comments

माथियास को इस पर लाने के लिए धन्यवाद। और scicomp में आपका स्वागत है!

— एरन अहमदिया

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

— वोल्फगैंग बैंगर्थ

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

— cboettig

Answer 2

ऐसी कई तकनीकी चुनौतियां हैं, जो कम्प्यूटेशनल परिणामों की सटीक बिट-फॉर-बिट बिट प्रजनन क्षमता बनाती हैं।

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

एक निचले स्तर पर, किसी भी कोड या नए संकलक के साथ या अलग-अलग संकलक अनुकूलन के साथ कोड द्वारा उपयोग किए जाने वाले पुस्तकालयों में से किसी एक को पुनः स्थापित करना भी समस्या पैदा कर सकता है। एक कारण यह है कि कोड के विभिन्न ऑपरेशनों को एक अलग क्रम में किया जा सकता है जब कोड को फिर से जोड़ा जाता है। चूँकि फ़्लोटिंग पॉइंट जोड़ सहयोगी नहीं है (a + b) + c <> a + (b + c), यह अलग-अलग परिणाम दे सकता है।

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

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

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

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

Comments

वैसे, विभिन्न संकलक संस्करणों के साथ समस्या यह बताती है कि स्रोत कोड के "जमे हुए" संस्करण को वितरित करने के लिए वास्तव में पर्याप्त क्यों नहीं है- संकलित कोड जो उत्पन्न होता है वह संकलक के किस संस्करण के उपयोग के आधार पर भिन्न हो सकता है और यह कर सकता है विभिन्न परिणामों के लिए नेतृत्व।

— ब्रायन बोरचर्स

Answer 3

प्रतिलिपि प्रस्तुत करने योग्य बनाने के लिए कई प्रयास हुए हैं और इस विषय पर एक पूरा साहित्य है। 15 साल के वैज्ञानिक सॉफ्टवेयर से मेरी व्यक्तिगत राय यह है कि यह मेरे जवाब के अनुसार असंतोषजनक है। समस्या यह है कि (i) जटिल सॉफ्टवेयर में कीड़े हैं और इसलिए इसे नहीं जमी जा सकती है; (ii) सॉफ्टवेयर कभी पूर्ण नहीं होता और इसलिए विकास जारी रहता है; (iii) कोड की कई सौ हज़ार लाइनों के साथ पेपर देने का मूल्य क्या है?

जैसा कि मैं कहता हूं, मुझे यह उत्तर असंतोषजनक लगता है। मेरा मानना ​​है कि एक क्षेत्र के रूप में, कम्प्यूटेशनल विज्ञान साहित्य का निर्माण करने में बहुत सफल नहीं रहा है जो विश्वास दिलाता है कि हम जो परिणाम प्रकाशित करते हैं वह सही और प्रतिलिपि प्रस्तुत करने योग्य हैं। उसी समय, मैं वास्तव में चीजों को बेहतर करने के तरीकों के साथ नहीं आ सकता हूं। सुनिश्चित करने के लिए, एक पेपर के साथ जाने वाला स्रोत कोड जारी करना उपयोगी है। इसी समय, हर कोई जो ईमानदार है वह इस बात से सहमत होगा कि एक पेपर में परिणाम आम तौर पर कोड के विभिन्न संस्करणों द्वारा उत्पादित किया जाएगा, जिसमें ज्यादातर मामलों में अलग-अलग सीमा स्थितियों, अलग-अलग दाहिने हाथों के किनारों आदि का वर्णन करने वाले हैक होते हैं, फिर एक पेपर होता है। एक ही कोड के विभिन्न संस्करणों के साथ आते हैं। यह पाठक के लिए शुरू करने के लिए अजीब है, लेकिन यह बिलकुल अनुत्पादक है अगर कोड बड़ा है जैसा कि आज भी अक्सर होता है - मेरे दो सबसे हाल के पेपरों में कोड का उपयोग किया गया है जो कोड की लगभग 20,000 लाइनें हैं और जो सौदा पर बनाते हैं। II (कोड के 600,000 लाइनें) और ट्रिलिनो (1.5M लाइनें) कोड का)। एक संभावित पाठक को कौन सी जानकारी प्रदान करता है? (मुझे कहना चाहिए कि मेरे कोड अभी भी उपलब्ध हैं।)

Comments

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

— बिल बर्थ

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

— वुल्फगैंग बंगर्थ

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

— बिल बर्थ

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

— cboettig

मुझे पूरा यकीन है कि अगर आप एक अच्छी राशि के साथ काम करना चाहते हैं तो आज से 15 साल पहले लिखा कोड प्राप्त कर सकते हैं। मुझे विश्वास है कि आप 15 वर्षों में चलने के लिए आज से अच्छी तरह से लिखित कोड प्राप्त कर सकते हैं।

— वोल्फगैंग बैंगर्थ

Answer 4

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

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

Answer 5

मेरा मानना ​​है कि जहां तक ​​भाषा का चुनाव होता है, एक मानकीकृत (उदाहरण के लिए C / फोरट्रान / C ++) का उपयोग करके "सर्वोत्तम अभ्यास" के रूप में योग्य होगा। यदि कोई पैकेज 10 अन्य देयताओं / पैकेजों पर निर्भर करता है, विशेष रूप से अस्पष्ट भाषाओं में लिखे गए हैं, तो यह स्पष्ट रूप से दीर्घायु के लिए बुरा है। कई परियोजनाएं कुछ समय बाद समाप्त हो जाती हैं। मुझे नहीं लगता कि प्रमुख काम / Api जैसे BLAS / LAPACK, PETSc, FFTW, MPI आदि कभी भी जल्द ही गायब हो जाएंगे। BLAS पहले से ही बहुत पुराना है।

कोड का निम्नलिखित टुकड़ा ( http://www.math.utah.edu/software/c-with-fortran.html से चुराया गया ) फोरट्रान 77 से पहले का है, चार हेरफेर के लिए हॉलेरिथ स्थिरांक का उपयोग करता है, लेकिन ठीक 40-50 साल बाद संकलित करता है ग्नू फोरट्रान कंपाइलर:

stali@x61:~$ cat olde.f

       CALL S(12HHello, world, 12)
       END
       SUBROUTINE S(MSG,N)
       INTEGER K, N, M
       INTEGER MSG(1)
       M = (N + 3) / 4
       WRITE (6,'(20A4)') (MSG(K), K = 1,M)
       END

stali@x61:~$ gfortran -std=legacy olde.f; ./a.out
Hello, world

ओपन सोर्सिंग / इसे कहीं और रखना जैसे कि googlecode जो जल्द ही गायब होने की संभावना कम है (हालांकि उन्होंने कोड खोज को बंद कर दिया था) कोई ब्रेनर नहीं है।

Comments

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

— कॉबेटिग ऑक्ट