Neden ve ne zaman bir R paketi yaratmalı?

Bu sorunun oldukça geniş bir soru olduğunu anlıyorum, ancak R için yeni bir paket oluşturmaya (ya da vermeme) karar vermede belirleyici noktaların ne olması gerektiğini merak ediyorum. Daha açık olmak gerekirse, sorunun nedenlerle ilgili olmadığını da ekleyeceğim. Çeşitli komut dosyalarını derleme ve bunları yeni bir pakete entegre etme kararı hakkında R'yi kendi içinde kullanın.

Bu kararlara yol açabilecek noktalar arasında, aşağıdakileri düşündüm (oldukça ayrıntılı olmayan bir biçimde):

• aynı alt alanda başka paketlerin bulunmaması;
• diğer araştırmacılarla değiş tokuş yapma ve deneylerin tekrarlanabilirliğini sağlama ihtiyacı;

Ve aksi karara yol açabilecek hususlar arasında:

• zaten kullanılan bazı paketlerde bulunan yöntemlerin bir kısmı;
• yeni bir bağımsız paket oluşturmak için gerekçelendirmek için yeterli olmayan yeni fonksiyon sayısı.

Her iki listede de olabilecek birçok noktayı unutmuş olabilirim ve bu kriterler kısmen öznel görünebilir. Öyleyse, ne demek istersiniz ve hangi noktada, çeşitli fonksiyonları ve verileri yeni bir dokümante edilmiş ve geniş çapta temin edilebilir bir pakette bir araya getirmeye başlamalısınız?

R'de programlamıyorum, ancak başka programlarım ve burada R'ye özgü bir sorun göremiyorum.

Çoğu insan ilk önce bir şeyler yazıyor, çünkü gerçekten kendileri için istiyorlar. Tersine, bir yazılım yayınlaması gerektiğine dair herhangi bir duygu, çünkü yapılacak şey şiddetle karşı koyulmalıdır. Akıllı insanlar kötü programcılar olabilir ve genellikle öyledir.

Kamuya açılmak, zaten kamusal olandan daha iyi veya daha iyi bir şeye sahip olduğunuzdan ve bir boşluğu doldurduğunuzdan emin olmak gibi görünüyor. Başkalarının da aynı şeyi yapmak istediğini bilmek kesinlikle bir destek.

Eğer şüpheniz varsa, yayınlama. Birçok toplulukta, kritik olmayan ya da deneyimsiz programcılar tarafından piyasaya sürülen vasat ya da buggy yazılımının kalite kontrol sorunu vardır, ancak sorunun ne kadar kötü olduğu tartışmaya açık kalır. İyimserler, önemsizliğin sadece göz ardı edilebileceğini ve kullanıcıların böcek ve sınırlamaları yeterince hızlı şekilde açığa çıkaracaklarını düşünüyor; karamsarlar, kalitesiz şeylerde boğulduğumuzu hissediyorlar ve kazananlara kaybedenlerden söylemek zor. (Diğer taraftan, yayından edinilen deneyim, programcıların gelişmesine izin veren şeyin bir parçasıdır.)

Bununla ilgili bir kitap olabilir, ancak birkaç işaretçi akla yatmaktadır:

1. Kaliteli belgeler, iyi yazılımları ve iyi kodları ayırt eder, hatta bazen daha açık bir şekilde. Kodun hak ettiği belgeleri sağlamak için ne kadar çalışmanız gerektiğini asla küçümsemeyin. R programcıları genellikle R kullanıcılarının, uygulanan teknikle ilgili bildikleri kadarını bilmelerini ve asgari düzeyde belgelemelerini zorunlu kılarlar.

2. Kodunuzu test edin, böylece yayınlanmış çözümleri başka bir yerden gelen gerçek verilerle yeniden oluşturabilirsiniz. (Tamamen yeni bir şeyi kodluyorsanız, bu daha zor olabilir, ancak imkansız değildir. Ayrıca, sık sık kendi böceklerinin mi yoksa sizin mi olduğunu merak ederek kendinizi de bulabilirsiniz.)

3. Programcılar çoğu zaman kullanıcıların bir programda uygun olmayan verileri atma yeteneğini küçümser. Bu yüzden, neyin yanlış gidebileceğini düşünün, örneğin, eksik değerler, bir programın pozitif olduğu varsayılırsa sıfırlar vb. (Buradaki huysuzluk, sorunları bulmak ve geri bildirimleriyle kodu geliştirmek kullanıcıların görevidir. , fakat kolayca bozulan bir program itibarınızı arttırmaz.)

Bu önemli ve pratik bir sorudur. Bir paket yazmak ile onu CRAN'da yayınlamak arasında ayrım yaparak başlayalım.

Nedenleri değil bir paket yazmak için:

• Maliyet verimliliği
• Tecrübe eksikliği.

Bir R paketi yazmanın nedenleri:

• İnsanlarla ve platformlarla paylaşma.
• Düzenli bir kod ve iş süreci zorlar.
• Fonksiyonlar birikmeye başladığında kullanım kolaylığı (kendi için bile).

Bir paket gönderme nedenleri (CRAN, Bioconductor, ...):

• Topluma katkı.
• Dağıtım kolaylığı

Unutmayın ki seçenek # 3; ilgili paketin sahibine kodunuzu veya verilerinizi eklemesini isteyebilirsiniz.

Ambalajlama için kişisel tetikleyicilerim:

• Başka bir veri analizi projesi için bir kez yazdığım bazı kodları kullanıyorum.
• Sanırım tekrar yazdığım yönteme ihtiyacım olacak.

• Bir meslektaşım benden kod istedi. Yazdığım kodun önemli bir kısmı, en azından meslektaşlarının isteği üzerine (R kullanan ancak kendileri kadar programlamayan), kendim için olduğu kadar.

• Bir paketi (belgeler) resmi olarak “temizlemeye ve kodumu belgelemeye zorlamak” için kullanıyorum.

@JohnRos ile bir paket yazmak ile paketi yayınlamak arasında oldukça fark olduğu konusunda hemfikirim.

• Genelde erken paketlerim, ancak paketi sadece "yarı cumhuriyet" yapar. Yani, dahili bir sunucuda (ya da rge forge'da) bulunabilir, böylece meslektaşlarım pakete erişebilir. Ancak, CRAN'a yalnızca paket aylarca, hatta birkaç yıl yakın arkadaşlarım tarafından kullanıldıktan sonra yayınlarım. Bu, @Nick Cox'un # 3 no'lu noktasına göre bütün böcekleri ortaya çıkarmaz, ancak adil bir miktardır.
  Paketin sürümleri (sürüm numarasında çizgi sonrasındaki tarihi koydum) işleri düzeltmeyi kolaylaştırıyor ("bunu yapmak için, en azından geçen haftaki sürümleri doldurduğunuzdan emin olun")

• İş sözleşmeme göre, işverenim bir paketin dış dünyaya nasıl yayınlanıp yayınlanamayacağına dair son sözü verdi.

Ambalajlama için henüz iyi bir stratejime sahip olmadığım şey veri.

Nedenler listenize yorumlarınız:

• aynı alt alanda başka paketlerin bulunmaması;

İhtiyacım olanı yapan bir paket bulamıyorum , kod yazmayı tetikliyor , ancak paketleyip paketlememeye karar vermek zorunda değil.

• diğer araştırmacılarla değiş tokuş yapma ve deneylerin tekrarlanabilirliğini sağlama ihtiyacı;

Kesinlikle. Muhtemelen zaten kullandığım birkaç bilgisayar arasında paylaşmaya ihtiyacım var.

Ve aksi karara yol açabilecek hususlar arasında:

• zaten kullanılan bazı paketlerde bulunan yöntemlerin bir kısmı;

Bu yöntemleri paketinize / kodunuza aktarabilirsiniz: bu kod yazmaya karşı bir noktadır , ancak yalnızca dolaylı olarak paketlemeyle ilgisi vardır.

• yeni bir bağımsız paket oluşturmak için gerekçelendirmek için yeterli olmayan yeni fonksiyon sayısı.

Benim için bir paketi başlatmak için asgari sayıda işlev yoktur. Tecrübelerime göre, paketler "otomatik olarak" büyüme eğilimindedir. Aksine, kendimi birkaç kez başka bir paketten ayırırken bulduktan sonra (örneğin sonuçtaki bazı yardımcı işlevlerin tematik olarak farklı ve diğer durumlarda da yararlı olduğu ortaya çıktı) hemen yeni paketler oluşturarak.

Ayrıca, dokümantasyon ve testler yazmadıysanız, bu bir paket oluşturmak için "yeterli" sayıda işlev biriktiğinde, yasaklayıcı bir iş olabilir.
(Onları hemen yazarsanız, iş akışını öğrendikten sonra onu bir pakete koyma çabası önemsizdir).

R içinde yeterince büyük bir benzer görev kümesi yaptığınızda, bir şeyi bir ad alanına koyabileceğiniz (benzer şekilde adlandırılmış işlevlerle çakışmaları önlemek için) yazabileceğiniz bir paketten faydalanacağınızı söyleyebilirim. dokümantasyon. Hatta ilişkili olmayan bir paket fonksiyon paketi toplamak için github'a bile bir paketim var, ancak dokümantasyon, adam dosyaları vb. Hak ettiklerini düşündüğüm kadar sık ​​kullanıyorum.

Kağıt gönderirken başka bir kullanım durumu olabilir, çok sayıda işleve sahipseniz, bu işlevlerin dokümantasyonu, her işleve ilişkin örnekler ve nasıl kullanılacağına ilişkin bir öğretici içeren bir paket oluşturabilirsiniz. Yukarıdaki cevaplarda belirtildiği gibi onu CRAN'a koymanıza gerek yok. Bu tekrarlanabilirlik için harika olabilir.

Söyleyeceğim üç araç önemlidir:

• devtools pkg , paketleri oluşturmayı çok kolaylaştırmak için (ayrıca devtools github sayfalarındaki wiki'yi görün)
• roxygen2 pkg , paketiniz için kolay dökümantasyon yazmak için
• GitHub, install_githubBaşkalarıyla paylaşmak için güzel olan GitHub'dan doğrudan yüklemek için (veya benzer şekilde install_bitbucket, vb.) Kullanabilirsiniz .

Şu ana kadar okuduğum her şeye katılıyorum. Tüm bu nedenler iyi programlama pratiğidir ve özellikle R için geçerli değildir. Ancak kendimi çoğu zaman R paketleri yazarken buluyorum ve başka bir sebeple. Bu yüzden ekleyeceğim:

Bir R paketi yazmak için R'e özel sebep:

• çünkü C ile yazıyorsun

C, C ++ veya FORTRAN gibi yabancı dilleri ne zaman kullanırsanız (çoğunlukla yüksek performanslı bilgi işlem için), paket yazmak büyük sıkıntıya değer. Birden fazla fonksiyonunuz varsa, her yerden hızlı bir şekilde dosyalarınızı doldurun ve R ile C kodu arasında tutulması ve taşınması zor olan bağımlılıklar ile bitirin.

Diğer mükemmel cevaplarda belirtilmeyen sebeplerden biri: Büyük veya karmaşık bir veri analizi projeniz var. Öncelikle verileri paket olarak paketlemek ve daha sonra spesifik analizleri dönüştürmek, çizmek veya hesaplamak için faydalı fonksiyonlarla genişletmek. Bu şekilde, raporlanmış analizi hesaplamak için kullanılan tüm işlevler ile birlikte verilerin belgelenmiş bir sürümünü elde edersiniz. Ardından, projeden gelen rapor (lar) knitr veya çoğaltılabilir araştırma için diğer paketler kullanılarak yazılabilir!

Bazı yeniden analizlerin yapılması gerekiyorsa bu önemli ölçüde zaman kazandırabilir veya analiz yayınlanmışsa yayınlanabilir (veya yarı yayınlanmış).