Belirttiğiniz kriterler arasında, bildiğim en yakın projenin Florida Üniversitesi seyrek matris koleksiyonu olacağını düşünüyorum . İnsanlar bu veri kümesini seyrek lineer cebir çözücüleri karşılaştırmak için rutin olarak kullanırlar ve uygulamaya, sıfır olmayan sayılara, matris boyutlarına ve benzerlerine göre gerçekten güzel bir web arayüzü, MATLAB arayüzü veya Java GUI ile filtreleyebilirsiniz. 4 - 8 doğrusal cebir çözücü ile çözücü çalışma süresi karşılaştırmaları ile birlikte kağıtlarda listelenen bu sorunların tablolarını gördüm.
Bu tür veritabanlarının derlenmesinin yararlı olacağına katılıyorum ve ayrıca, veri derlemek için UF seyrek matris toplama yaklaşımının mükemmel olduğunu ve bu fikri gerçekleştirmeyi düşünen herkes için harika bir başlangıç yapacağını düşünüyorum. Pratikte tüm problemleri yürütmek, tüm çözücülere erişebildiğiniz sürece büyük bir zorluk gibi görünmüyor; Çözücülere ve gerekli tüm yazılımların yüklü olduğu güvenilir bir standart referans makinesine erişiminiz varsa, bir komut dosyası çalıştırma ve veri toplama meselesi olmalıdır. Aklımdaki zorluk, insanların açık kaynaklı olmasa bile size yazılımlarını vermelerini sağlamak olacaktır. Ticari ise, satın alabilir, hatta insanların yazılımı bağışlamasını sağlayabilirsiniz,COIN-OR projesi. Ancak ticari veya açık kaynak olmayan bir araştırma yazılımı ise, insanları çabaya girmeye ikna etmeniz gerekir ve yazılımlarını adil bir şekilde değerlendirmek için üçüncü bir tarafa güvenmeyebilirler.
Ayrıca optimizasyonda indirilebilir problem veritabanları ( CUTEr
akla geliyor) ve optimizasyon için test problemleri kitapları olduğunu da biliyorum . İnsanları gördüm (örneğin, özellikle AIChE 2011'de Ruth Misener tarafından yapılan bir konuşmayı düşünüyorum), optimizasyon çözücülerini sunumlardaki sorun veritabanlarındaki diğer çözücülerle karşılaştırın; Nelerin herkese açık olarak yayınlandığından emin değilim. Büyük ölçekte karşılaştırma için bir optimizasyon geleneği olduğunu biliyorum (birçok çözücü, birçok sorun); Sadece çevrimiçi bir veritabanı olduğunu sanmıyorum.
Önemli olduğunu düşündüğüm bir diğer şey, burada yöntemler ve yazılım uygulamaları arasında ayrım yapmamız.. Bilimsel hesaplamada hepimiz, hesaplama karmaşıklığı metrikleri veya çeşitli sorunlarla ilgili deneyimlerimiz temelinde hangi yöntemlerin daha hızlı veya daha yavaş olduğu hakkında konuşuruz. Bununla birlikte, hesaplama zamanını nicel olarak ölçmeye gelince, belirli bir algoritmada FLOP sayısını saymadıkça, algoritmayı yazılımda uygulamak ve ardından performansı bir şekilde ölçmek gerekir (bellek kullanımı, duvar saati yürütme zamanı, vb.) .). Hesaplama karmaşıklığı veya FLOP sayılarına bakarken bir yöntemin performansını değerlendirmek mantıklıdır, çünkü bu tür şeyleri ölçmek için bir uygulamaya ihtiyacımız yoktur, ancak gerçek duvar saati çalışma süreleriyle ilgilendiğimiz an, yöntemler hakkında konuşmak sadece soyut, konuşma diline özgü bir araç olarak kullanışlıdır. (Örneğin,
Yöntemler ve yazılım arasındaki bu ayrımı gündeme getirdim çünkü böyle bir veritabanında, zaman içinde yazılımdaki gelişmeyi izleme olasılığını da görebiliyordum. Örneğin, örneğin, PETSc veya PyCLAW gibi bir şeyle veya hangi yazılım test ediliyorsa, yazılımdaki yükseltmelerden hangi sorunların olumlu (veya olumsuz!) Etkilendiğini görmek ilginç olacaktır. Bu, kodlarını yükseltmek için para ve insan gücü açısından herhangi bir potansiyel maliyete değip değmeyeceğine karar vermeye çalışan araştırmacılar için yararlı olabilir. Böyle bir ayrımın önemli olmasının bir başka nedeni, iyi bir yöntemin kötü bir şekilde uygulanabilmesidir; Bence bu olasılık insanların bazen araştırma kodlarını paylaşmalarına olan suskunluğa katkıda bulunuyor.
Sanırım bu fikir ne olursa olsun (ve umarım bir şey gelir ve doktora programımdan sonra katkıda bulunmaya istekli olur), yazılım ve yöntemler arasındaki bu ayrımı vurgulamak önemlidir, çünkü test problemleri yürütüyorsak, yazılım için sonuçlar yayınlayacak.