Бази даних результатів для числових кодів

У літературі про числові методи багато дослідницьких робіт складаються з опису нової алгоритмічної варіації з подальшими кількома тестовими проблемами порівняння нового методу з одним або двома існуючими методами. Це ускладнює визначення

• Як новий метод діятиме на інші цікаві проблеми
• Як новий метод порівнявся б із іншими існуючими методами

Звичайно, обидва ці питання, як правило, є критичними для того, хто вирішує, чи прийняти новий метод. Щоб покращити цю ситуацію, мабуть, бажано, якщо можливо, змусити людей запускати великий набір тестових проблем ( див. Це питання ) своїм методом та каталогізувати результати в базі даних для порівняння з іншими методами. Вчений або інженер може потім запитувати базу даних, можливо, вказуючи, які характеристики рішення / проблеми є найбільш важливими для них (точність, ефективність, якісні властивості тощо), і отримати кількісне порівняння ефективності всіх методів у базі даних.

Я розумію, що існує багато труднощів у здійсненні цієї ідеї (головне: змусити людей реально керувати усіма цими проблемами та вимірювати обчислювальні витрати). Але моє запитання: чи існує така база даних результатів? (скажімо, в якомусь конкретному підполі) чи такий підхід застосований де-небудь?

Обидва відповіді, опубліковані до цього часу, стосуються баз проблем. Я запитую про бази даних результатів.

З критеріїв, які ви вказали, я вважаю, що найближчим проектом, який я знаю, був би колекція розріджених матриць Університету Флориди . Люди регулярно використовують цей набір даних для порівняння рідких лінійних алгебр, і ви можете фільтрувати за додатком, кількістю ненульових значень, розмірами матриці тощо з дуже приємним веб-інтерфейсом, інтерфейсом MATLAB або інтерфейсом Java GUI. Я бачив таблиці цих проблем, перелічені в статтях, а також зіставленням часу виконання розв'язків на 4 - 8 лінійних розв'язках алгебри.

Я погоджуюся, що було б корисно скласти такі бази даних, і, крім того, я вважаю, що підхід до збору рідких матриць UF для збирання даних є чудовим, і це послужило б чудовим початком для тих, хто думає про реалізацію цієї ідеї. Виконання всіх проблем на практиці не здається головною складністю, якщо ви можете отримати доступ до всіх вирішувачів; якщо у вас є доступ до вирішувачів та надійного стандартного довідкового апарату з усім встановленим необхідним програмним забезпеченням, то це має бути справою запуску сценарію та збору даних. На мою думку, складність полягатиме в тому, щоб люди змусили передавати вам своє програмне забезпечення, якщо воно не є відкритим кодом. Якщо вона комерційна, ви можете придбати її або навіть, можливо, змусити людей здавати програмне забезпечення,Проект COIN-OR Але якщо це дослідницьке програмне забезпечення, яке не є ні комерційним, ні відкритим кодом, тоді вам потрібно переконати людей купувати зусилля, і вони можуть не довіряти сторонній стороні, щоб оцінити своє програмне забезпечення справедливо.

Я також знаю, що в оптимізації є завантажувані бази даних проблем ( CUTEr приходить на думку) та книги тестових проблем для оптимізації. Я бачив, як люди (наприклад, я конкретно думаю про розмову Рут Місенер на AIChE 2011) порівнюють їх вирішення для оптимізації порівняно з іншими рішеннями на базі даних проблем у презентаціях; Я не впевнений, що публічно звільняється. Я знаю, що існує традиція оптимізації для порівняння у великому масштабі (багато вирішувачів, багато проблем); Я просто не думаю, що є онлайн-база даних.

Ще одна річ, яка мені здається важливою, - це те, що ми тут розрізняємо методи та реалізацію програмного забезпечення. У наукових обчисленнях ми всі говоримо про те, які методи швидші чи повільніші на основі таких речей, як показники складності обчислювальної техніки або наш досвід із різними проблемами. Що стосується кількісного вимірювання обчислювального часу, однак, якщо не підраховувати кількість FLOP в конкретному алгоритмі, потрібно реалізувати алгоритм у програмному забезпеченні, а потім певним чином виміряти продуктивність (використання пам'яті, час виконання настінного годинника тощо). .). Має сенс оцінювати ефективність методу, дивлячись на складність обчислень або підрахунки FLOP, оскільки нам не потрібна реалізація для вимірювання таких речей, але момент, коли нас цікавлять фактичні тривалість роботи настінного годинника, говорити про методи корисний лише як абстрактний, розмовний пристрій. (Наприклад,

Я розкриваю цю різницю між методами та програмним забезпеченням, оскільки в такій базі даних я також міг бачити можливість відстеження вдосконалення програмного забезпечення з часом. Так, наприклад, з чимось на кшталт, скажімо, PETSc або PyCLAW, або будь-яким іншим програмним забезпеченням тестується, було б цікаво подивитися, на які проблеми впливає позитивний (чи негативно!) Оновлення програмного забезпечення. Це може бути корисним для дослідників, які намагаються вирішити, чи варто потенційних витрат у грошах та робочій силі для оновлення своїх кодів. Ще одна причина такого розмежування є важливою, оскільки хороший метод може бути реалізований погано; Я думаю, що ця можливість сприяє тому, що люди іноді мають спільний доступ до своїх дослідницьких кодів.

Я думаю, що все, що випливає з цієї ідеї (і я сподіваюся, що щось з неї вийде, і я був би готовий внести свій внесок після мого доктора наук), важливо підкреслити цю різницю між програмним забезпеченням та методами, тому що якщо у нас є проблеми з тестом, ми збирається публікувати результати для програмного забезпечення.

Була зроблена спроба створити список "складних" інтегралів для обчислення чисельно (див. Документи Вальтера Гаучі, Роберта Піссенса та інших), але формальної бази даних немає.

У полі ODE є тестовий набір IVP , тестовий набір для початкових проблем.

Я не знайомий з такою базою даних, але думаю, що було б дуже важко визначити корисний спосіб. Кращою системою, на мою думку, є звільнення коду в запущеній формі, щоб користувач міг продовжити тестування настільки всебічно, як їм подобається. Що стосується сховищ спільноти, тестовий набір IVP, який згадує GertVdE, також містить код драйвера для запуску декількох опублікованих вирішувачів ODE / DAE на тестові проблеми. У своїх публікаціях я намагаюся випустити код та всі скрипти, які використовуються для створення аналізу вихідних даних та створення графіків та таблиць, що з’являються у статті.

Аналогічна мета в галузі аероакустичних проблем з аероакустичними проблемами має семінар з обчислювальної аероакустики. Вони спочатку представляють набір задач, орієнтованих заздалегідь, і змушують людей вирішувати їх за допомогою власних методів та порівнювати результати. Наприклад, ось розгляд четвертого засідання: http://www.archive.org/details/nasa_techdoc_20040182258

Хоча, з того, що я можу сказати, вони не порівнюють, наскільки ефективні їх коди один проти одного, вони в основному дивляться на точність.

У рамках моделювання землетрусів було здійснено декілька подібних зусиль. Ті, що спадають на думку, - це проект динамічного моделювання розриву та проект інверсії джерела (http://eqsource.webfactional.com/wiki/). Обидва ці проблеми надають фізичні проблеми для вирішення та є агностичними (на певному рівні) щодо застосованих методів. Дійсно, ці проекти полягають у тому, щоб змоделювати конкретні доменні моделери для порівняння один з одним, а не насправді загальним набором тестових проблем для кожного методу числових pdes. Але ви можете порівняти з іншими результатами, і це виявило багато проблем з багатьма кодами.

Однією з можливих можливостей був би проект "Мадагаскар" , який був розроблений у світі сейсмічних зображень, але, як стверджується, має цілком загальне призначення.