Meningkatkan panjang umur arsip kode


11

Apakah ada daftar praktik terbaik yang dipublikasikan untuk memastikan umur kode yang panjang, dengan pandangan terhadap hasil ilmiah yang dapat direproduksi? (mis. open source, praktik dokumentasi, memilih dependensi, memilih bahasa, mesin virtual, dll).

Tahu ada studi (atau kurang itu, contoh / anekdot) yang telah mencoba memperkirakan paruh waktu kode ilmiah khas atau perangkat lunak lain (jika itu bahkan pertanyaan yang masuk akal?)


Jawaban:


8

umur panjang yang direncanakan dari TeX muncul dalam pikiran:

“Sejak permulaan tahun 1977, proyek penelitian TeX yang saya jalankan didorong oleh dua tujuan utama. Tujuan pertama adalah kualitas: kami ingin menghasilkan dokumen yang tidak hanya bagus, tetapi sebenarnya yang terbaik. (...) Tujuan utama kedua adalah pengarsipan: untuk menciptakan sistem yang independen terhadap perubahan dalam teknologi cetak sebanyak mungkin. Ketika generasi berikutnya dari perangkat pencetakan datang, saya ingin dapat mempertahankan kualitas yang sama yang telah dicapai, daripada harus menyelesaikan semua masalah baru. Saya ingin merancang sesuatu yang masih dapat digunakan dalam 100 tahun. ”- Donald E. Knuth: Digital Typography, hlm. 559 (dikutip dari http://de.wikipedia.org/wiki/TeX )

Berdasarkan buku-buku Knuth tentang tipografi digital, bahkan implementasi ulang lengkap TeX dan METAFONT harus dimungkinkan. Mereka menyertakan anotasi dan penjelasan untuk semua kode.

Dengan menuntut bahwa hasil Anda harus stabil selama beberapa dekade, Anda mengalami semacam dilema pembekuan. Di satu sisi, Anda ingin membuatnya mudah mereproduksi hasil Anda 100%, sehingga Anda membekukan perangkat lunak / lingkungan Anda. Di sisi lain, seseorang yang tertarik untuk mereproduksi hasil Anda di masa depan pasti ingin membangun di atasnya. Orang ini akan terjebak dengan perangkat lunak yang sangat lama, sehingga sangat sulit untuk mengubah apa pun. Untuk apa pun yang dibangun di atas beberapa paket eksternal, sudah beberapa tahun sudah cukup untuk membuat hal-hal praktis tidak berubah.

Untuk TeX, pembekuan diumumkan pada artikel 1990

Masa depan TEX dan METAFONT http://www.ntg.nl/maps/05/34.pdf

"Saya sangat percaya bahwa sistem yang tidak berubah memiliki nilai yang besar, meskipun itu adalah aksiomatis bahwa setiap sistem yang kompleks dapat ditingkatkan. Oleh karena itu saya percaya bahwa tidak bijaksana untuk melakukan" perbaikan "lebih lanjut pada sistem yang disebut TEX dan METAFONT. Mari kita perhatikan ini sistem sebagai titik tetap, yang akan memberikan hasil yang sama 100 tahun dari sekarang yang mereka hasilkan hari ini. "

Sistem yang ideal akan menggabungkan reproduktifitas dengan perubahan. Mencoba menjadi mandiri, sesederhana dan teruji sebaik mungkin tentu membantu.

Maafkan saya jika saya terlalu banyak menyimpang dari pertanyaan awal. [cross diposting dari 'Scientists for Reproducible Research', reproducible-research@googlegroups.com]


Terima kasih telah membawa ini pada Matthias. Dan selamat datang di scicomp!
Aron Ahmadia

2
Saya berpikir bahwa contoh TeX sebenarnya bukan yang sangat baik meskipun itu umumnya dianggap sebagai kasus klasik untuk sistem beku. Alasan saya pikir begitu adalah karena tidak ada yang menggunakan TeX secara langsung lagi. Orang-orang menggunakan lateks bersama-sama dengan paket yang tak terbatas dan mereka sangat tidak beku. Sebagai konsekuensinya, saya berpikir bahwa (La) dokumen TeX dapat berubah sama seperti yang lainnya. Bagi saya, TeX seperti mesin virtual - Anda dapat tetap membeku tetapi selama kode yang dibangun di atasnya terus berubah, tidak ada yang dimenangkan.
Wolfgang Bangerth

Terima kasih, saya pikir ini adalah studi kasus yang sangat baik dari sudut pandang pengembangan perangkat lunak, yang mungkin agak berbeda dari sudut pandang ilmiah. Fakta bahwa setiap orang perlu membangun TeX secara tidak langsung mungkin tidak ideal untuk perangkat lunak yang digunakan secara luas, tetapi mungkin merupakan demonstrasi ideal bahwa kode ilmiah masih dapat berjalan dengan sukses dan dibangun berdasarkan dekade kemudian. Tapi tentu saja Knuth lebih mudah menghindari perubahan & pembaruan untuk mencapai stabilitas 100 tahun?
cboettig

4

Ada banyak tantangan teknis yang membuat reproduktifitas bit-for-bit hasil komputasi yang tepat sangat sulit untuk dicapai.

Pada tingkat perangkat lunak, perubahan pada kode atau perpustakaan apa pun yang digunakan oleh kode jelas dapat menyebabkan hasil yang berbeda. Anda akan terkejut dengan jumlah pustaka dukungan yang akhirnya dapat dihubungkan dengan kode ilmiah tipikal.

Pada tingkat yang lebih rendah, kompilasi ulang salah satu kode atau perpustakaan yang digunakan oleh kode dengan kompiler baru atau dengan optimisasi kompiler yang berbeda dihidupkan juga dapat menyebabkan masalah. Salah satu alasannya adalah bahwa berbagai operasi dalam kode dapat dilakukan dalam urutan yang berbeda ketika kode tersebut dikompilasi ulang. Karena penambahan floating point tidak asosiatif (a + b) + c <> a + (b + c), ini dapat memberikan hasil yang berbeda.

OK, jadi bagaimana jika kita menjaga seluruh lingkungan perangkat lunak (OS, perpustakaan, dan kode yang dikompilasi) dengan (misalnya) membakarnya ke CD-Rom bootable yang akan menjalankan kode. Sekarang bisakah kita memastikan bahwa kita akan mendapatkan hasil yang sama jika kita menjalankan kode ini di komputer lain?

Anehnya, beberapa kode sebenarnya memvariasikan urutan perhitungan berdasarkan aspek-aspek model prosesor tertentu yang mereka jalankan. Misalnya, pustaka aljabar linier yang dioptimalkan biasanya memecah perkalian matriks untuk bekerja pada blok yang akan masuk ke dalam cache. Ketika Intel merilis mikroprosesor baru dengan cache yang lebih besar, kode mungkin secara dinamis menyesuaikan ukuran blok, menghasilkan aritmatika yang dilakukan dalam urutan yang berbeda dan memberikan hasil yang berbeda. Kode lain secara dinamis menyesuaikan urutan perhitungan berdasarkan jumlah memori yang tersedia - jika Anda menjalankan kode pada komputer dengan lebih banyak memori yang dapat menyebabkan aritmatika dilakukan dalam urutan yang berbeda dan dengan demikian memberikan hasil yang berbeda.

Banyak hal menjadi lebih rumit ketika Anda memasukkan kode multithreaded, karena riwayat eksekusi yang tepat dari utas yang berbeda sering kali tidak deterministik dan ini lagi-lagi dapat menyebabkan operasi aritmatika dilakukan dalam urutan yang berbeda dari satu putaran ke putaran berikutnya.

Dalam praktiknya, yang paling bisa Anda harapkan adalah hasil yang serupa dari satu mesin ke mesin lain, hingga toleransi akurasi dari algoritma yang digunakan. misalnya jika saya memiliki masalah pencarian root dan menggunakan pembagian dua untuk mendapatkan root dalam + -1.0e-10, maka saya harus senang selama mesin yang berbeda menghasilkan jawaban yang setuju dalam toleransi itu.


Omong-omong, masalah dengan versi kompiler yang berbeda menjelaskan mengapa sebenarnya tidak cukup untuk mendistribusikan versi "beku" dari kode sumber - kode kompilasi yang dihasilkan dapat bervariasi tergantung pada versi kompiler yang digunakan dan ini dapat mengarah pada hasil yang berbeda.
Brian Borchers

2

Ada banyak upaya untuk mewujudkan reproduktifitas dan ada banyak literatur tentang topik ini. Pendapat pribadi saya dari 15 tahun perangkat lunak ilmiah adalah bahwa itu tidak realistis, tidak memuaskan ketika saya menemukan jawaban itu. Masalahnya adalah (i) perangkat lunak kompleks memiliki bug sehingga tidak dapat dibekukan; (ii) perangkat lunak tidak pernah fitur lengkap dan pengembangan terus berlanjut; (iii) apa nilai pengiriman dengan kertas beberapa ratus ribu baris kode?

Seperti yang saya katakan, saya menemukan jawaban ini tidak memuaskan. Saya percaya bahwa sebagai sebuah bidang, ilmu komputasi belum terlalu berhasil dalam menghasilkan literatur yang menanamkan kepercayaan bahwa hasil yang kami terbitkan adalah benar dan dapat direproduksi. Pada saat yang sama, saya tidak dapat menemukan cara untuk melakukan hal-hal dengan lebih baik. Yang pasti, merilis kode sumber yang sesuai dengan kertas berguna. Pada saat yang sama, setiap orang yang jujur ​​akan setuju bahwa hasil dalam makalah biasanya akan diproduksi oleh versi berbeda dari kode yang, dalam banyak kasus berisi peretasan yang menggambarkan kondisi batas yang berbeda, sisi kanan yang berbeda, dll. Makalah kemudian akan datang dengan versi berbeda dari kode yang sama. Ini aneh bagi pembaca untuk memulai, tetapi sama sekali tidak produktif jika kodenya besar seperti yang sering terjadi hari ini - dua makalah saya yang terakhir menggunakan kode yang sekitar 20.000 baris kode dan yang dibuat berdasarkan kesepakatan. II (600.000 baris kode) dan Trilinos (1,5M baris) kode). Informasi apa yang diberikan kepada pembaca potensial? (Saya harus mengatakan bahwa kode saya tetap tersedia.)


2
Saya kurang pesimis tetapi masih tidak puas. Anda dapat dengan mudah melaporkan tag kontrol revisi atau nomor revisi yang terkait dengan kode yang menghasilkan hasil di setiap makalah yang diberikan, dan penulis yang benar-benar teliti akan menjalankan kembali semua hasil yang penting untuk artikel tertentu dengan satu basis kode. Saya tidak berpikir Anda perlu mengirimkan kode itu sendiri jika ada sistem kontrol revisi, dapat diakses secara publik, dan tag diterbitkan.
Bill Barth

Tentu, Anda bisa melakukannya. Pertanyaannya hanyalah apa yang akan dilakukan pembaca dengan banyak kode yang Anda berikan padanya. Ya, Anda dapat menjalankannya dan memverifikasi bahwa hasilnya sama dengan yang ditunjukkan. Tapi apa yang diperlihatkan itu? Bagaimana orang akan memverifikasi - dalam praktik nyata, bukan dalam teori - bahwa hasilnya benar?
Wolfgang Bangerth

Tidak, itu bagian yang saya setujui sepenuhnya. Kecuali saya pikir Anda adalah orang yang tidak bermoral, saya tidak perlu menjalankan kembali kode Anda untuk mereproduksi jawaban dengan tepat. Saya pikir pertanyaan yang lebih besar adalah apakah Anda telah cukup menunjukkan bahwa Anda telah memverifikasi implementasi Anda dan apakah itu dapat divalidasi terhadap eksperimen.
Bill Barth

Terima kasih, tetapi saya merasa ini tidak menjawab pertanyaan. Tentu saja ada banyak ruang untuk diperdebatkan mengapa memiliki kode tersedia 15 tahun kemudian berguna , tetapi dalam pertanyaan ini saya hanya bertanya apakah kode itu masih akan berjalan untuk kebanyakan orang, mengingat Anda memang mengarsipkannya. Saya akrab dengan literatur yang mendorong pengarsipan kode, tetapi tidak ada yang mendorong arsip global untuk kartu punch 40 tahun yang lalu. Apakah teknologi meningkatkan atau mengurangi waktu paruh perangkat lunak? Jika kode yang diarsipkan melewati telegraf dalam waktu 5 tahun, masalah lainnya tetap bisu.
cboettig

Saya cukup yakin Anda bisa mendapatkan kode yang ditulis 15 tahun yang lalu untuk dijalankan hari ini, jika dengan jumlah pekerjaan yang baik. Saya yakin Anda bisa mendapatkan kode yang ditulis dengan baik mulai hari ini untuk berjalan dalam 15 tahun.
Wolfgang Bangerth

2

Untuk solusi yang mungkin untuk masalah ini, lihat proyek ActivePapers saya . Singkatnya, ini menjelaskan bagaimana data dan kode dapat dikemas bersama dengan dependensi eksplisit pada versi spesifik dari setiap komponen perangkat lunak. Ini memungkinkan untuk mereproduksi perhitungan dengan tepat, sementara juga mengizinkan untuk menjalankan perangkat lunak yang diperbarui pada data yang sama.

Saya harus menambahkan bahwa ActivePapers tidak lebih dari bukti konsep dan tidak mungkin menjadi penggunaan praktis dalam waktu dekat. Alasannya adalah bahwa hal itu didasarkan pada prinsip bahwa semua kode yang dapat dieksekusi harus ada sebagai bytecode JVM. Saat ini, ini tidak termasuk terlalu banyak perpustakaan ilmiah populer. Namun, setelah reproduktifitas diakui sebagai hal yang penting, prioritas dalam alat pemrograman dapat berubah juga.


1

Saya percaya bahwa sejauh pilihan bahasa berjalan, menggunakan bahasa standar (misalnya C / Fortran / C ++) akan memenuhi syarat sebagai "praktik terbaik". Jika sebuah paket tergantung pada 10 lib / paket lain, terutama yang ditulis dalam bahasa yang tidak jelas maka itu jelas buruk untuk umur panjang. Banyak proyek yang akhirnya menjadi yatim setelah beberapa waktu. Saya tidak berpikir lib / api besar seperti BLAS / LAPACK, PETSc, FFTW, MPI dll akan menghilang dalam waktu dekat. BLAS sudah cukup tua.

Sepotong kode berikut (dicuri dari http://www.math.utah.edu/software/c-with-fortran.html ) sebelum Fortran 77, menggunakan konstanta Hollerith untuk manipulasi arang tetapi mengkompilasi dengan baik 40-50 tahun kemudian dengan GNU Fortran Compiler:

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

Buka sumber / menaruhnya di suatu tempat seperti googlecode yang kecil kemungkinannya akan segera hilang (meskipun mereka mematikan pencarian kode) adalah sesuatu yang sulit.


Terima kasih untuk contohnya! Saya ingin tahu melihat perbandingan dalam bahasa lain, termasuk bahasa scripting - apakah kode pertama yang pernah ditulis dalam perl, python, atau R masih berjalan dengan hasil yang sama? Apakah mereka lebih cenderung melakukannya atau lebih kecil daripada C atau Fortran?
cboettig
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.