Database hasil untuk kode numerik

Dalam literatur metode numerik, banyak makalah penelitian terdiri dari deskripsi variasi algoritme baru, diikuti oleh beberapa masalah tes membandingkan metode baru dengan satu atau dua metode yang ada. Ini membuatnya sulit untuk ditentukan

• Bagaimana metode baru akan dilakukan pada masalah lain yang menarik
• Bagaimana metode baru akan dibandingkan dengan metode lain yang sudah ada

Tentu saja, kedua pertanyaan ini biasanya penting untuk seseorang yang memutuskan apakah akan mengadopsi metode baru. Untuk memperbaiki situasi ini, tampaknya diinginkan, jika mungkin, membuat orang menjalankan serangkaian besar masalah pengujian ( lihat pertanyaan ini ) dengan metode mereka dan katalog hasilnya dalam database untuk perbandingan dengan metode lain. Seorang ilmuwan atau insinyur kemudian dapat meminta database, mungkin menunjukkan solusi / karakteristik masalah apa yang paling penting bagi mereka (akurasi, efisiensi, sifat kualitatif, dll.), Dan mendapatkan perbandingan kuantitatif dari kinerja semua metode dalam database.

Saya menyadari bahwa ada banyak kesulitan dalam mengimplementasikan ide ini (terutama: membuat orang untuk benar-benar menjalankan semua masalah itu, dan mengukur biaya komputasi). Tetapi pertanyaan saya adalah: Apakah ada database hasil seperti itu? (katakanlah di beberapa subbidang tertentu) atau apakah pendekatan seperti ini telah diterapkan di mana saja?

Kedua jawaban yang diposting sejauh ini adalah tentang database masalah. Saya bertanya tentang database hasil.

Dari kriteria yang Anda tentukan, saya pikir proyek terdekat yang saya tahu adalah koleksi matriks Universitas Florida . Orang-orang secara rutin menggunakan kumpulan data ini untuk membandingkan pemecah aljabar linier yang jarang, dan Anda dapat memfilter berdasarkan aplikasi, jumlah nonzeros, dimensi matriks, dan sebagainya dengan antarmuka web yang sangat bagus, antarmuka MATLAB, atau Java GUI. Saya telah melihat tabel dari masalah-masalah ini yang tercantum dalam makalah bersama dengan perbandingan waktu berjalan solver dengan 4 hingga 8 pemecah aljabar linier.

Saya setuju bahwa akan berguna untuk mengkompilasi database seperti itu, dan lebih jauh lagi, saya pikir pendekatan pengumpulan matriks UF jarang untuk mengkompilasi data adalah yang terbaik, dan akan membuat awal yang bagus bagi siapa pun yang berpikir untuk merealisasikan ide ini. Menjalankan semua masalah, dalam praktiknya, tidak tampak seperti kesulitan besar selama Anda bisa mendapatkan akses ke semua solver; jika Anda memiliki akses ke solver, dan mesin referensi standar yang dapat diandalkan dengan semua perangkat lunak yang diperlukan diinstal, maka itu harus menjadi masalah menjalankan skrip dan mengumpulkan data. Kesulitannya, dalam pikiran saya, akan membuat orang memberi Anda perangkat lunak mereka, jika itu bukan open source. Jika komersial, Anda dapat membelinya, atau bahkan mungkin membuat orang menyumbangkan perangkat lunaknya,Proyek COIN-ATAU . Tetapi jika itu adalah perangkat lunak riset yang tidak komersial atau open source, maka Anda perlu meyakinkan orang untuk membeli dalam upaya, dan mereka mungkin tidak mempercayai pihak ketiga untuk menilai perangkat lunak mereka secara adil.

Saya juga tahu bahwa dalam pengoptimalan, ada database masalah yang dapat diunduh ( CUTEr muncul di benak) dan buku-buku masalah pengujian untuk pengoptimalan. Saya telah melihat orang (misalnya, saya secara khusus memikirkan ceramah oleh Ruth Misener di AIChE 2011) membandingkan pemecah pengoptimalan mereka versus pemecah lain pada basis data masalah dalam presentasi; Saya tidak yakin apa yang akan dirilis ke publik. Saya tahu bahwa ada tradisi dalam optimasi untuk perbandingan dalam skala besar (banyak solver, banyak masalah); Saya hanya tidak berpikir ada database online yang tersedia.

Hal lain yang menurut saya penting adalah kita membedakan di sini antara metode dan implementasi perangkat lunak. Dalam komputasi ilmiah, kita semua berbicara tentang metode mana yang lebih cepat atau lebih lambat berdasarkan hal-hal seperti metrik kompleksitas komputasi, atau pengalaman kami dengan berbagai masalah. Ketika datang untuk mengukur waktu komputasi secara kuantitatif, bagaimanapun, kecuali jika seseorang menghitung jumlah FLOP dalam algoritma tertentu, seseorang harus mengimplementasikan algoritma dalam perangkat lunak dan kemudian mengukur kinerja dalam beberapa cara (penggunaan memori, waktu pelaksanaan jam dinding, dll. .). Masuk akal untuk menilai kinerja suatu metode ketika melihat kompleksitas komputasi atau penghitungan FLOP, karena kita tidak memerlukan implementasi untuk mengukur hal-hal seperti itu, tetapi saat kita tertarik pada waktu menjalankan jam dinding yang sebenarnya, berbicara tentang metode adalah hanya berguna sebagai perangkat abstrak dan sehari-hari. (Contohnya,

Saya mengemukakan perbedaan antara metode dan perangkat lunak karena dalam database seperti itu, saya juga bisa melihat kemungkinan melacak peningkatan perangkat lunak seiring waktu. Jadi, misalnya, dengan sesuatu seperti, katakanlah, PETSc, atau PyCLAW, atau perangkat lunak apa pun yang sedang diuji, akan menarik untuk melihat masalah apa yang dipengaruhi secara positif (atau negatif!) Dengan peningkatan dalam perangkat lunak. Ini bisa bermanfaat bagi para peneliti yang mencoba untuk memutuskan apakah sepadan dengan potensi biaya dalam bentuk uang dan tenaga untuk meningkatkan kode mereka. Alasan lain pembedaan seperti itu penting adalah karena metode yang baik dapat diimplementasikan dengan buruk; Saya pikir kemungkinan ini berkontribusi pada sikap diam yang terkadang dimiliki orang dalam membagikan kode penelitian mereka.

Saya pikir apa pun yang muncul dari ide ini (dan saya berharap sesuatu datang darinya, dan akan bersedia untuk berkontribusi setelah PhD saya), penting untuk menekankan perbedaan antara perangkat lunak dan metode, karena jika kita menjalankan masalah pengujian, kita akan memposting hasil untuk perangkat lunak.

Telah ada upaya untuk membuat daftar integral "sulit" untuk dihitung secara numerik (lihat makalah oleh Walter Gautschi, Robert Piessens dan lain-lain) tetapi tidak ada database formal.

Di bidang ODE, ada set uji IVP , set tes untuk Masalah Nilai Awal.

Saya tidak terbiasa dengan database seperti itu, tetapi saya pikir akan sangat sulit untuk mendefinisikannya dengan cara yang bermanfaat. Sistem yang lebih baik, menurut saya, adalah merilis kode dalam bentuk runnable sehingga pengguna dapat memperluas untuk menguji selengkap yang mereka mau. Dalam hal repositori komunitas, suite tes IVP yang GertVdE sebutkan juga mengandung kode driver untuk menjalankan beberapa pemecah ODE / DAE yang diterbitkan tentang masalah tes. Dalam publikasi saya, saya mencoba untuk merilis kode dan semua skrip yang digunakan untuk membuat analisis data output dan membuat plot dan tabel yang muncul di koran.

Workshop Aeroacoustics Computational tentang Masalah Benchmark memiliki tujuan yang sama dalam pikiran untuk masalah aeroacoustic. Mereka pertama kali menyajikan serangkaian masalah tolok ukur sebelumnya, dan meminta orang menyelesaikannya menggunakan metode mereka sendiri dan membandingkan hasilnya. Misalnya, inilah proses pertemuan keempat: http://www.archive.org/details/nasa_techdoc_20040182258

Meskipun, dari apa yang saya tahu mereka tidak membandingkan seberapa efisien kode mereka terhadap satu sama lain, mereka terutama melihat keakuratan.

Dalam pemodelan gempa ada beberapa upaya semacam ini. Yang muncul di pikiran adalah proyek simulasi pecah dinamis dan proyek inversi sumber (http://eqsource.webfactional.com/wiki/). Kedua hal ini memberikan masalah fisik untuk dipecahkan dan bersifat agnostik (pada tingkat tertentu) mengenai metode yang digunakan. Sungguh proyek-proyek ini adalah tentang mendapatkan pemodel spesifik domain untuk dibandingkan satu sama lain, bukan benar-benar serangkaian masalah pengujian umum untuk setiap metode numerik pdes. Tetapi Anda dapat membandingkan dengan hasil yang lain, dan ini telah mengungkapkan banyak masalah dengan banyak kode.

Satu kemungkinan untuk melihat adalah proyek madagaskar , yang telah dikembangkan dalam dunia pencitraan seismik tetapi mengklaim sebagai tujuan yang cukup umum.