BerandaComputers and TechnologyDari Reproduksibilitas hingga Reproduksi Berlebih (2016)

Dari Reproduksibilitas hingga Reproduksi Berlebih (2016)

Bukan rahasia lagi bahwa penelitian biomedis membutuhkan semakin banyak analisis komputasi akhir-akhir ini, dan dengan itu telah muncul beberapa diskusi yang disambut baik tentang bagaimana membuat analisis tersebut dapat direproduksi. Pada tingkat tertentu, saya rasa ini tidak perlu dipikirkan lagi: jika tidak dapat direproduksi, itu bukan sains, bukan? Dan pada tingkat praktis, saya pikir ada banyak hal baik tentang membuat analisis Anda dapat direproduksi, termasuk yang berikut (diberi peringkat secara samar dimulai dengan apa yang saya anggap paling penting):

Secara seimbang, saya pikir membuat hal-hal semudah mungkin mereproduksi adalah menghabiskan waktu dengan baik. Secara khusus, ini adalah waktu yang dapat dihabiskan dengan baik oleh sebagian besar perusahaan penelitian biomedis yang saat ini tidak memikirkan hal semacam ini sama sekali, dan saya pikir sangat penting bagi kita yang memiliki kecenderungan komputasi untuk membantu melatih yang lain agar analisis mereka dapat direproduksi.

Kekhawatiran saya, bagaimanapun, adalah bahwa strategi untuk reproduktifitas yang sering dipromosikan tipe komputasi tidak sesuai target dan tidak harus disesuaikan dengan kebutuhan dan keterampilan orang yang mereka coba jangkau. Ada ketegangan tertentu dari kefanatikan yang dapat direproduksi yang menurut saya mengecilkan hati orang lain untuk mengadopsi beberapa praktik dasar yang dapat sangat bermanfaat bagi penelitian mereka, dan pada saat yang sama membatasi produktivitas bahkan para pelakunya sendiri. Anda tahu apa yang saya bicarakan: ini adalah gagasan untuk mengubah seluruh makalah Anda menjadi sebuah program, jadi Anda cukup mengetik “buat kertas” dan munculkan manuskrip yang sudah sepenuhnya terbentuk dan diformat. Baik secara abstrak, tetapi dalam pekerjaan (seperti banyak lainnya) di mana waktu adalah komoditas paling berharga kita, dorongan ini menunjukkan kegagalan total untuk mengukur biaya peluang dengan benar. Dengan kata lain, alih-alih membuat kode keras untuk penyesuaian jarak gambar pracetak LaTeX Anda, gunakan waktu itu untuk menulis makalah lain. Saya pikir sangat penting untuk diingat bahwa pekerjaan kita adalah sains, bukan pemrograman, dan jika kita terlalu fokus pada aspek prosedural dalam membuat semuanya dapat direproduksi dan didokumentasikan secara lengkap, kami berisiko mematikan mereka yang kurang nyaman dengan pemrograman karena manfaat yang sangat nyata dari membuat analisis mereka dapat direproduksi.

Berikut adalah dua penyebab terbesar dalam pandangan saya: kontrol versi dan skrip gambar.

Mari kita mulai dengan kontrol versi. Saya pikir kita semua bisa setuju bahwa bagian terpenting dari membuat analisis ilmiah dapat direproduksi adalah memastikan analisis ada dalam skrip dan tidak hanya diketik atau diklik ke program di suatu tempat , hanya untuk perintah tersebut menghilang ke dalam memori yang memudar. Skrip analisis yang baik dan dapat direproduksi harus dimulai dengan data mentah, melalui semua manipulasi komputasi yang diperlukan, dan meninggalkan Anda dengan angka atau elemen grafis yang berakhir di makalah Anda di suatu tempat. Hal ini membuat analisis dapat direproduksi, karena orang lain sekarang dapat menjalankan kode dan melihat bagaimana data mentah Anda berubah menjadi nilai-p di subpanel Gambar 4G. Dan ingat, bahwa orang lain kemungkinan besar adalah diri Anda di masa depan :).

Oke, semoga kita semua setuju tentang perlunya skrip. Namun, kemudian, hampir setiap diskusi tentang reproduktifitas komputasi dimulai dengan arahan untuk mengadopsi git atau beberapa sistem kontrol versi lainnya, seolah-olah itu adalah langkah selanjutnya yang jelas. Hmm. Saya hanya akan langsung mengatakannya dan mengatakan bahwa untuk sebagian besar proyek komputasi (setidaknya di lab kami), kontrol versi hanya membuang-buang waktu. Mengapa? Nah, apa tujuan membuat analisis yang dapat direproduksi? Saya yakin tujuannya adalah untuk memiliki kumpulan skrip yang mengambil data mentah dan secara andal mengubahnya menjadi semacam pengetahuan. Tujuan dari kontrol versi adalah untuk mengelola kode, secara khusus menekankan “reversibilitas, konkurensi, dan anotasi [of changes to code]”. Meskipun orang dapat membayangkan beberapa tumpang tindih di antara tujuan-tujuan ini, saya belum tentu melihat hubungan alami di antara keduanya. Untuk membuatnya lebih konkret, mari coba menjawab pertanyaan yang selama ini saya ajukan (dan pernah ditanyakan), yaitu “Mengapa tidak menggunakan Dropbox saja?”. Lagipula, Dropbox akan menyimpan semua kode dan data Anda (termasuk versi yang lebih lama), dibagikan di antara orang-orang dengan mulus, dan mungkin hanya akan mati jika PDIII pecah. Dan mudah digunakan . Berikut adalah beberapa argumen potensial yang dapat saya bayangkan orang-orang mungkin mendukung kontrol versi:

  1. Anda dapat menghindari Fig_1.ai, Fig_1_2.ai, Fig_1_2_final_AR_PG_JK.ai, dll. Lakukan saja perubahan dan lakukan! Anda memiliki semua versi lama!
  2. Anda dapat melacak siapa yang mengubah kode apa dan mengembalikan semuanya (dan mengelola konflik file).

Nah, untuk poin 1, saya benar-benar berpikir bahwa tidak ada yang salah dengan memiliki semua salinan file yang berbeda ini. Sangat mudah untuk melihat dengan cepat apa yang berubah di antara versi yang berbeda, yang sangat berguna untuk file biner (seperti file Illustrator) yang tidak dapat Anda jalankan dengan diff. Tentu, ini mungkin sedikit lebih bersih untuk memiliki hanya satu Fig_1.ai, tetapi dalam praktiknya, saya pikir itu sebenarnya kurang berguna. Di lab kami, kami tidak repot-repot melakukan itu, dan semuanya berjalan dengan baik.

Yang kemudian membawa kita ke poin 2, tentang perubahan kode pelacakan. Berkenaan dengan hal ini, menurut saya akan bermanfaat untuk memisahkan kode yang digunakan untuk alat tujuan umum di lab dan kode yang dikhususkan untuk proyek tertentu. Untuk alat kode untuk tujuan umum yang memberikan kontribusi beberapa anggota tim, kontrol versi sangat masuk akal – lagipula untuk itulah sebenarnya dirancang. Sangat membantu untuk melihat versi lama basis kode, melihat perubahan persis yang telah dibuat oleh anggota tim lainnya, dan sebagainya.

Namun, alasan ini tidak benar-benar berlaku pada kode yang akan ditulis orang untuk menganalisis data untuk proyek tertentu. Di lab kami, dan saya curiga sebagian besar orang lain, kode ini biasanya ditulis oleh satu atau dua orang, dan jika dua, mereka biasanya bekerja dalam kontak yang sangat dekat. Selain itu, tujuan akhirnya bukanlah untuk memiliki catatan basis kode yang bergeser, melainkan memiliki satu set skrip analisis yang diselesaikan yang akan mereproduksi angka dan angka di makalah. Karena alasan ini, kemampuan untuk memutar kembali ke versi kode sebelumnya dan membuat anotasi perubahan tidak banyak berguna dalam praktiknya. Saya bertanya di sekitar lab, dan saya pikir mungkin ada satu kali ketika kami memutar kembali kode. Jika tidak, pada dasarnya, untuk sebagian besar analisis makalah, kami hanya bergerak maju dan tidak mengkhawatirkannya. Saya kira secara teoritis ada kemungkinan bahwa beberapa analisis lama terbukti berguna sehingga Anda dapat memulihkan melalui kontrol versi, tetapi sejujurnya, sebagian besar waktu, itu berakhir di folder terpisah. (Orang mungkin mengatakan itu tidak bersih, tapi saya pikir itu sebenarnya baik-baik saja. Jika analisis berbeda jenisnya, maka menggantinya melalui kontrol versi tidak terlalu masuk akal – ini bukan penggantian kode sebelumnya semata.)

Tentu saja, orang dapat berkata, meskipun kontrol versi tidak sepenuhnya diperlukan untuk analisis yang dapat direproduksi, apa ruginya? Menurut pendapat saya, negatif besar adalah jumlah kontrol versi gesekan yang disuntikkan ke hampir setiap aspek proses analisis. Ini adalah harga yang Anda bayar untuk pembuatan versi dan anotasi, dan menurut saya tidak ada cara untuk menyiasatinya. Dengan Dropbox, saya hanya memasukkan sebuah file dan itu muncul di mana saja, terbarui, secara ajaib. Tidak repot, tidak repot. Jika Anda menggunakan kontrol versi, kontrol ini terus melakukan, mendorong, menarik, memperbarui, dan menambahkan catatan. Selain itu, jika Anda seperti saya, Anda akan mengacau di beberapa titik, yang mengarah ke beberapa masalah, yang berpotensi bencana, yang akan menghabiskan waktu berjam-jam untuk mencari tahu. Saya jelas tidak sendiri:

“Batalkan: kepala jarak jauh bercabang” siapa saja? 🙂 Pada saat itu, kita semua hanya memanggil satu orang di lab yang tahu bagaimana menangani semua omong kosong ini dan berharap yang terbaik. Dan lihat, saya relatif paham komputer, jadi saya hanya bisa membayangkan betapa mengintimidasi semua ini bagi orang yang kurang paham komputer. Intinya adalah bahwa kontrol versi itu rumit, misterius dan memakan waktu, dan yang terpenting, tidak benar-benar berkontribusi banyak pada analisis komputasi yang dapat direproduksi. Jika intinya adalah untuk mendorong orang yang relatif baru dalam komputasi untuk membuat skrip dan mengatur hasil komputasi mereka, saya pikir mengarahkan mereka untuk mengadopsi kontrol versi adalah ide yang sangat buruk. Memang, untuk sementara waktu saya membuat semua orang di lab kami menggunakan kontrol versi untuk proyek mereka, dan secara keseluruhan, itu menjadi negatif bersih dalam hal waktu. Kami beralih ke Dropbox untuk beberapa proyek baru-baru ini dan kehidupannya JAUH lebih baik – dan sama dapat direproduksi.

Oh, dan saya pikir ada beberapa orang yang menggunakan kontrol versi untuk teks makalah mereka (hampir pasti merupakan subset yang tepat dari mereka yang karena alasan tertentu menulis makalah mereka di Markdown atau LaTeX). Kecuali jika makalah Anda memuat banyak matematika di dalamnya, saya tidak tahu mengapa ada orang yang tunduk pada bentuk penyiksaan ini. Biar saya yang memberitahu Anda bahwa Anda tidak kalah pintar atau tangguh jika Anda menggunakan Google Docs. Faktanya, beberapa orang mungkin mengatakan Anda lebih pintar, karena Anda tidak membiarkan etos / ideologi baris perintah menghalangi menyelesaikan sesuatu…:)

Yang membawa saya ke contoh skrip gambar. Pembuatan skrip gambar merupakan proses pembuatan gambar secara lengkap dari suatu naskah. Script semacam itu akan membuat semua subpanel, menyesuaikan semua ukuran font, menangani semua warna, dan lain sebagainya. Di dunia ideal dengan waktu tak terbatas, ini akan menjadi hebat – siapa yang tidak ingin membuat semua sosok mereka muncul secara ajaib dengan mengetikkan figur? Dalam praktiknya, pasti ada beberapa hasil yang berkurang, dan terserah Anda di mana batas antara membuatnya dapat direproduksi dan menyelesaikannya. Bagi saya, garis kerasnya adalah bahwa semua elemen grafis yang mewakili nilai data harus diberi kode. Seperti, jika saya membuat sebar, maka lokasi titik yang relatif ke sumbu harus diberi kode keras. Di luar itu, waktunya Illustrator! Illustrator akan membiarkan Anda mengatur ukuran font, bobot garis, warna penanda, dan hampir semua hal lain yang dapat Anda pikirkan secara sederhana dan relatif intuitif, dengan umpan balik langsung. Jika Anda dapat mengatur ukuran font Anda dan sebagainya secara terprogram, lebih banyak kekuatan untuk Anda. Tetapi perlu diingat bahwa waktu yang Anda habiskan untuk memprogram hal-hal ini adalah waktu yang dapat Anda habiskan untuk hal lain. Kali ini bisa sangat besar: lihat kode panjang ini yang ditulis untuk menghindari perjalanan ke Illustrator. Juga, karena kerumitan dari apa yang Anda coba lakukan semakin besar, semakin sedikit paket yang ada untuk membantu Anda membuat gambaran. Misalnya, pertimbangkan gambar ini dari salah satu makalah Marshall:

Membuat bilah gradien dan semua garis serta anotasi akan menjadi mimpi buruk untuk dilakukan melalui skrip (dan ini bahkan tidak terlalu rumit). Ya, jika Anda memutuskan untuk membuat perubahan, Anda harus mengulang beberapa pekerjaan manual di Illustrator, oleh karena itu kebijaksanaan umum untuk membuat semuanya dalam skrip untuk “menghemat waktu mengulang sesuatu”. Tetapi mengingat jumlah upaya yang diperlukan untuk mengetahui cara membuat kode hal itu, sembilan dari sepuluh, jumlah total waktu yang dihabiskan untuk mengulanginya akan lebih sedikit. Dan saat tidak ada orang yang membaca dengan cermat, menambahkan semua elemen visual ini ke makalah Anda agar lebih mudah menjelaskan pekerjaan Anda dengan cepat adalah keharusan yang kuat – lebih kuat daripada memastikan semuanya berasal dari skrip, menurut saya.

Bagaimanapun, semua yang dikatakan, apa yang sebenarnya kita lakukan di lab? Setelah melalui beberapa pengulangan, pada dasarnya kami telah menetapkan hal-hal berikut. Kami membuat folder Dropbox untuk kertas, dan di dalam folder tersebut, kami memiliki subfolder, satu untuk data mentah (ish), satu untuk skrip, satu untuk grafik dan satu untuk gambar (mungkin dengan beberapa elaborasi tergantung pada keadaan). Dalam folder skrip adalah sekumpulan, eh, skrip yang, ketika dijalankan, mengambil data mentah (ish) dan mengubahnya menjadi elemen grafis. Kami kemudian mengumpulkan elemen grafis tersebut menjadi gambar, bersama dengan file readme untuk mendokumentasikan file mana yang menjadi gambar. Gambar-gambar itu dapat berisi versi elemen grafis yang sangat diubah, dan kami biasanya akan menyesuaikan ukuran font, tanda centang, warna, apa saja, tetapi jika Anda ingin mencari tahu mengapa beberapa titik data berada di tempatnya, rantai dapat diakses sepenuhnya. Kemudian, setelah selesai, kami memasukkan semua file ke bitbucket untuk diakses siapa saja.

Oh, dan satu hal lagi tentang keabadian: skrip kami menggunakan beberapa kombinasi R dan MATLAB, dan mereka berfungsi untuk saat ini. Mereka mungkin tidak bekerja selamanya. Tidak apa-apa. Hidup terus berjalan, dan kebanyakan surat kabar tidak. Mereka yang melakukannya karena kesimpulan ilmiah mereka, bukan data atau analisis mereka per se . Jadi saya tidak khawatir tentang itu.

Pembaruan, 3/1/2016: Pushback yang cukup dapat diprediksi dari banyak orang, terutama tentang kontrol versi. Pertama, hanya untuk mengulangi, kami menggunakan kontrol versi untuk alat tujuan umum kami, yang diedit dan digunakan oleh banyak orang, sehingga membuat kontrol versi menjadi alat yang tepat untuk pekerjaan itu. Namun, saya belum mendengar argumen yang benar-benar menarik untuk menggunakan kontrol versi yang akan mengurangi kerumitan terkait substansial untuk kasus penggunaan yang saya diskusikan di sini, yaitu membuat analisis dalam makalah dapat direproduksi . Ada banyak botak pernyataan manfaat kontrol versi di luar sana tanpa bukti nyata untuk validitasnya selain “baik, saya pikir ini harus lebih baik” , juga dengan sedikit diskusi jujur ​​tentang kerumitan kontrol versi. Ini menurut saya mirip dengan pushback terhadap LaTeX vs. kertas Word . Bukti terkutuk! 🙂

Read More

RELATED ARTICLES

LEAVE A REPLY

Please enter your comment!
Please enter your name here

Most Popular

Recent Comments