Що стосується автоматичної диференціації, чи є перетворення вихідного коду (STC) більш ефективним, ніж перевантаження оператора (OO)?

Ми працюємо над баєсовою моделлю для просторово-часового процесу і використовуємо семплер без повороту (NUTS), який потребує моделі для ймовірності журналу та його градієнта щодо параметрів моделі. Більш коротко, у нас є досить складна функція вірогідності логарифми , що включає статистичні розподіли, продукти кронекера, експоненціали, співвідношення, твердження про інше тощо, і нам потрібно надати його і це градієнт до NUTS. Кілька пакетів ( Стен і Джулія MCMC ) використовують перевантаження оператора (наскільки мені відомо) для автоматичного отримання градієнта.$f : \mathbb{R}^n \rightarrow \mathbb{R}$

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

Перетворення від джерела до джерела вважається золотим стандартом з точки зору продуктивності. Підходи до OO здаються майже такими ж хорошими, оскільки там є більше пакетів OO, а продуктивність не згадується як істотний недолік. Якщо ви знайдете вподобану бібліотеку ОО для мови, якою ви працюєте, я б спочатку скористався нею, а потім з’ясував, чи потрібно абсолютно перетворення від джерела до джерела, і якщо такий інструмент, що відповідає вашим потребам, існує. Типова вартість похідної, створеної автоматичною диференціацією, приблизно в три-п’ять разів перевищує оцінку функції, щоб поставити речі в контекст.

Там є більше пакетів OO, тому що простіше реалізувати автоматичні інструменти диференціації за допомогою перевантаження оператора, ніж використовувати переклад від джерела до джерела. Реалізація перекладача з джерела на джерело рівнозначна написанню компілятора: вихідний код повинен бути проаналізований та токенізований, тоді до перетворюваного дерева виразів слід застосувати правила перетворення. У книзі Андреаса Гриванка "Оцінка похідних: принципи та методи алгоритмічної диференціації", друге видання, детальніше йдеться про компроміси.

Для розрахунку градієнта використовується зворотний режим AD. Це вимагає в обох випадках для складання стека операндів, версія OO також потребує створення операційного стеку, який повинен інтерпретуватися у зворотному переході коду. Джерело трансформований код записує зворотно упорядковані операції як додатковий вихідний код, який складається. Накладні витрати, що мають інтерпретатор операцій у коді, можуть бути значними. Існують порівняння згенерованого кодом Tapenade та Adol-C, які виходять на користь Tapenade.