Метод BFGS проти кон'югатного градієнта

Які міркування слід враховувати при виборі між BFGS та спряженим градієнтом для оптимізації? Функція, яку я намагаюся вмістити з цими змінними, - це експоненціальні функції; однак, фактична цільова функція передбачає інтеграцію, серед іншого, і дуже дорога, якщо це взагалі допомагає.

JM має рацію щодо зберігання. BFGS вимагає приблизного гессіана, але ви можете ініціалізувати його за допомогою матриці ідентифікації, а потім просто обчислити оновлення рангових позицій до приблизної гессіани, поки ви маєте доступну інформацію про градієнт, бажано аналітично, а не через кінцеві відмінності. BFGS - це метод квазі-Ньютона, який буде сходитись за менше кроків, ніж CG, і має трохи меншу тенденцію до «застрягання» та потребує невеликих алгоритмічних перетворень, щоб досягти значного спуску для кожної ітерації.

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

Щодо коефіцієнтів конвергенції, якщо - кількість змінних рішень у вашій проблемі, то ітерацій CG приблизно дорівнює одному кроці методу Ньютона. BFGS - це квазі-ньютонівський метод, але слід спостерігати такий самий вид спостереження; Ви, ймовірно, отримаєте конвергенцію за меншою кількістю ітерацій з BFGS, якщо не буде декількох напрямків CG, в яких багато спуску, а потім після декількох ітерацій CG ви перезапустите її. CG-подібні методи дешевші, якщо матричні векторні продукти дешеві, а ваша проблема настільки велика, що зберігати гессіанців важко або неможливо. BFGS передбачає ще кілька векторних векторних продуктів для оновлення свого приблизного гессіанського, тому кожна ітерація BFGS буде дорожчою, але вам буде потрібно менше їх для досягнення локального мінімуму.$n$$n$

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

Нарешті, слово про автоматичну диференціацію: маючи певний досвід роботи з функцією автоматичного розмежування будинку (AD) для Fortran ( DAEPACK ), я можу вам сказати, що інструменти AD часто хитрі. Вони не обов'язково зможуть диференціювати код, який вони створюють самі. Існує два типи інструментів AD:

• інструменти AD-джерела до джерела
• оператор перевантажує інструменти AD

Засоби джерела до джерела - це по суті модифіковані компілятори, які беруть написаний вихідний код, аналізують його та автоматично генерують новий вихідний код, який обчислює градієнт функцій у вихідному коді. Інструменти AD, що перевантажують AD, вимагають використовувати перевантажені оператори AD у вихідному коді, щоб можна було обчислити похідні, що вимагатиме додаткових зусиль з вашого боку для обчислення аналітичних похідних з AD.

Пов'язана вартість BFGS може бути приведена в більшу відповідність із CG, якщо ви використовуєте обмежені варіанти пам'яті, а не BFGS з повним зберіганням. Це обчислює оновлення BFGS для останніх оновлень ефективно за допомогою серії оновлень першої позиції, не потрібно зберігати більше, ніж останні рішення та градієнти.$m$$m$

На мій досвід, BFGS з великою кількістю оновлень зберігає інформацію занадто далеко від поточного рішення, щоб бути дійсно корисним для наближення не відстаючих якобійців, і ви можете фактично втратити конвергенцію, якщо зберігаєте занадто багато. Існують "безпам'ять" варіанти BFGS, які дуже схожі на нелінійні спряжені градієнти (див. Остаточне оновлення, описане для однієї з них) саме з цих причин. Тому, якщо ви готові робити L-BFGS, а не BFGS, проблеми з пам'яттю зникають і методи пов'язані між собою . Анекдотичні докази вказують на те, що перезапуск є складним питанням, оскільки це іноді непотрібно, а іноді дуже необхідно.

Ваш вибір між двома також сильно залежить від проблем, які вас цікавлять. Якщо у вас є ресурси, ви можете спробувати як свої проблеми, так і вирішити, що працює краще. Наприклад, я особисто не роблю оптимізації за допомогою цих алгоритмів, а натомість дбаю про рішення систем нелінійних рівнянь. Для цього я виявив, що NCG працює краще і простіше виконувати нелінійну попередню обстановку. BFGS є більш надійним.

Чесно кажучи, мій улюблений метод для таких видів речей - N-GMRES . Це особливо справедливо, якщо оцінка вашого градієнта дуже дорога, оскільки, на мій досвід, це дає вам найбільше зусиль за ваш долар, вирішивши невелику проблему мінімізації на останньому ітерації для побудови нового, нижнього залишкового рішення.$m$

У низьких розмірах добре реалізований метод BFGS, як правило, і швидший, і більш надійний, ніж CG, особливо якщо функція не дуже далеко від квадратичної.

Ні BFGS, ні CG не потребують припущення про опуклість; тільки початкове наближення Гессі (для BFGS), відповідно попередній кондиціонер (для КГ) повинен бути позитивним. Але їх завжди можна вибрати як матрицю ідентичності, в низьких розмірах без особливої ​​шкоди. Дивіться також /scicomp//a/3213/1117

За відсутності запрограмованого градієнта велика витрата зусиль на використання числових градієнтів, особливо коли значення функцій дорогі. Скоріше, слід використовувати алгоритм, що не містить похідних. Див. Http://archimedes.cheme.cmu.edu/?q=dfocomp для останнього опитування.