आर पैकेज क्यों और कब बनाएं?

Question

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

उन बिंदुओं के बीच, जो मुझे इन निर्णयों के लिए प्रेरित कर सकते हैं, मैंने (काफी गैर-थकाऊ फैशन में) सोचा है:

• एक ही उप-क्षेत्र में अन्य पैकेजों की गैर-मौजूदगी;
• अन्य शोधकर्ताओं के साथ आदान-प्रदान और प्रयोगों के प्रतिलिपि प्रस्तुत करने की अनुमति की आवश्यकता;

और उन बिंदुओं के बीच जो विपरीत निर्णय ले सकता है:

• पहले से उपयोग किए गए तरीकों का हिस्सा कुछ अन्य पैकेजों में मौजूद है;
• नए स्वतंत्र पैकेज बनाने के लिए औचित्य के लिए नए कार्यों की संख्या पर्याप्त नहीं है।

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

Answer 1

मैं आर में कार्यक्रम नहीं करता, लेकिन मैं अन्यथा कार्यक्रम करता हूं, और मुझे यहां कोई आर-विशिष्ट मुद्दा नहीं दिखता है।

मुझे लगता है कि ज्यादातर लोग पहले कुछ लिखते हैं क्योंकि वे वास्तव में खुद के लिए चाहते हैं। इसके विपरीत, किसी भी भावना है कि किसी को सॉफ्टवेयर प्रकाशित करना चाहिए क्योंकि यह करने की चीज है जिसका दृढ़ता से विरोध किया जाना चाहिए। स्मार्ट लोग घटिया प्रोग्रामर हो सकते हैं, और अक्सर होते हैं।

सार्वजनिक रूप से जाना यह विश्वास करने का विषय है कि आपके पास कुछ ऐसा है जो पहले से ही सार्वजनिक है या उससे बेहतर है जो एक अंतर को भरता है। यह जानकर कि अन्य लोग भी ऐसा ही करना चाहते हैं, निश्चित रूप से एक बढ़ावा है।

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

इस पर एक किताब हो सकती है, लेकिन कुछ संकेत वसंत को ध्यान में रखते हैं:

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

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

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

Comments

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

— जीन-बैप्टिस्ट कैम्प

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

— निक कॉक्स

हारने वालों से विजेता और आपके बहुत ही मान्य बिंदुओं के बारे में: # 1: सौभाग्य से, आर में कुछ बिंदु हैं जो आसानी से जांच सकते हैं , और जो केवल औपचारिक आवश्यक मदद पृष्ठों की तुलना में बेहतर प्रलेखन की ओर इशारा करते हैं। एक विगनेट प्रदान किया गया है ( sos::findFnइस जानकारी को परिणाम तालिका में डालने के लिए यह मानदंड काफी महत्वपूर्ण है!)। एक डेमो? अधिक जानकारी के साथ एक वेब पेज? करता है citationएक उचित कागज दे या बुक # 2 यदि आप अपने कोड के साथ उदाहरण डेटा शिप कर सकते हैं तो भले ही कोई अन्य कार्यान्वयन आप के खिलाफ अपने कोड का परीक्षण कर सकते हैं अब दूसरों तुम्हारा के खिलाफ उनके कार्यान्वयन का परीक्षण कर सकते हैं।

— cbeleites मोनिका का समर्थन करता है

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

— जोरन

दीर्घवृत्त ... एक तरफ एक तलना संकेत था। यह आर समुदाय के लिए अपने स्वयं के मानकों को निर्धारित करने के लिए, या कम से कम उन पर बहस करने के लिए है।

— निक कॉक्स

Answer 2

यह एक महत्वपूर्ण और व्यावहारिक प्रश्न है। आइए एक पैकेज लिखने और CRAN पर इसे प्रकाशित करने के बीच अंतर करके शुरू करें।

पैकेज नहीं लिखने के कारण :

• कीमत का सामर्थ्य।
• अनुभव की कमी।

R पैकेज लिखने के कारण:

• लोगों और प्लेटफार्मों के साथ साझा करना।
• एक स्पष्ट कोड और काम की प्रक्रिया के लिए मजबूर करता है।
• कार्यों में आसानी होने पर (स्वयं के लिए भी) उपयोग में आसानी।

पैकेज जमा करने के कारण (CRAN, Bioconductor, ...):

• समुदाय के लिए योगदान।
• वितरण में आसानी।

Comments

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

— ग्रीम वाल्श

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

— जीन-बैप्टिस्ट कैम्प

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

— ग्रीम वॉल्श

Answer 3

याद रखें कि विकल्प # 3 है; आप अपने कोड या डेटा को शामिल करने के लिए एक प्रासंगिक पैकेज के अनुरक्षक से पूछ सकते हैं।

Answer 4

पैकेजिंग के लिए मेरे व्यक्तिगत ट्रिगर हैं:

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

• एक सहकर्मी मुझसे कोड मांगता है। मेरे द्वारा लिखे गए कोड का पर्याप्त हिस्सा कम से कम उन सहयोगियों के अनुरोध पर है (जो आर का उपयोग करते हैं लेकिन खुद के लिए उतना प्रोग्राम नहीं करते हैं)।

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

मैं @ जॉनरोस से सहमत हूं कि पैकेज लिखने और पैकेज प्रकाशित करने के बीच काफी अंतर है।

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

• मेरे काम के अनुबंध के अनुसार, मेरे नियोक्ता के पास इस निर्णय पर अंतिम शब्द है कि क्या और कैसे एक पैकेज बाहरी दुनिया के लिए प्रकाशित किया जा सकता है।

वह चीज जहां मेरे पास अभी तक पैकेजिंग के लिए एक अच्छी रणनीति नहीं है, डेटा है।

---

आपके कारणों की सूची पर टिप्पणियाँ:

• एक ही उप-क्षेत्र में अन्य पैकेजों की गैर-मौजूदगी;

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

• अन्य शोधकर्ताओं के साथ आदान-प्रदान और प्रयोगों के प्रतिलिपि प्रस्तुत करने की अनुमति की आवश्यकता;

निश्चित। संभवतः पहले से ही मेरे द्वारा उपयोग किए जाने वाले कई कंप्यूटरों के बीच साझा करने की आवश्यकता है।

और उन बिंदुओं के बीच जो विपरीत निर्णय ले सकता है:

• पहले से उपयोग किए गए तरीकों का हिस्सा कुछ अन्य पैकेजों में मौजूद है;

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

• नए स्वतंत्र पैकेज बनाने के लिए औचित्य के लिए नए कार्यों की संख्या पर्याप्त नहीं है।

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

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

Comments

+1। संकुल को सार्वजनिक करने का एक और अच्छा तरीका पैकेज स्रोत को GitHub पर रखना है - यह कोड को CRAN पर पैकेज के निहित पॉलिश के बिना योगदान करने के लिए दूसरों को खोजने और प्रोत्साहित करने में आसान बनाता है।

— मैट पार्कर

Answer 5

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

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

मैं कह सकता हूँ कि तीन उपकरण महत्वपूर्ण हैं:

• devtools pkg , संकुल बनाने के लिए सुपर आसान बनाने के लिए (भक्त github पृष्ठों पर विकि भी देखें
• roxygen2 pkg , आपके पैकेज के लिए लेखन दस्तावेज को आसान बनाने के लिए
• GitHub, आप install_githubGitHub से सीधे इंस्टॉल करने के लिए (या इसी तरह install_bitbucket, आदि) का उपयोग कर सकते हैं , जो दूसरों के साथ साझा करने के लिए अच्छा है।

Answer 6

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

R- विशेष कारण R पैकेज लिखने के लिए:

• क्योंकि आप सी में लिखते हैं

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

Answer 7

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

यह काफी समय बचा सकता है अगर कुछ रीनलिसिस किया जाना है, या यह भी प्रकाशित किया जा सकता है (या अर्धप्रकाशित) यदि विश्लेषण प्रकाशित किया जाता है।