Jeśli chodzi o automatyczne różnicowanie, czy transformacja kodu źródłowego (STC) jest bardziej wydajna niż przeciążenie operatora (OO)?

Pracujemy nad modelem Bayesian dla procesu czasoprzestrzennego i używamy samplera No-U-Turn (NUTS), który wymaga modelu prawdopodobieństwa logarytmicznego i jego gradientu w odniesieniu do parametrów modelu. Mówiąc bardziej zwięźle, mamy dość skomplikowaną funkcję logarytmu prawdopodobieństwa , obejmującą rozkłady statystyczne, produkty Kroneckera, wykładnicze, stosunki, instrukcje if-else itp., I musimy je podać i jego gradient do NUTS. Kilka pakietów ( MCMC Stana i Julii ) wykorzystuje przeciążenie operatora (o ile mi wiadomo), aby automatycznie uzyskać gradient.$f : \mathbb{R}^n \rightarrow \mathbb{R}$

Gdybyśmy byli w stanie stworzyć własną funkcję gradientu, być może przy użyciu narzędzia do automatycznego porównywania transformacji kodu źródłowego, czy uzyskalibyśmy lepszą wydajność, czy też OO jest tak samo dobre czy lepsze?

Transformacja typu źródło-źródło jest uważana za złoty standard pod względem wydajności. Podejścia OO wydają się być prawie tak dobre, ponieważ istnieje więcej pakietów OO, a wydajność nie jest wspomniana jako znacząca wada. Jeśli znajdziesz bibliotekę OO, którą lubisz dla języka, w którym pracujesz, najpierw jej użyję, a potem ustalę, czy absolutnie potrzebujesz transformacji typu źródło-źródło i czy istnieje takie narzędzie spełniające Twoje potrzeby. Typowy koszt pochodnej generowanej automatycznie na podstawie różnicowania jest około trzy do pięciu razy większy niż ocena funkcji, aby umieścić kontekst.

Dostępnych jest więcej pakietów OO, ponieważ łatwiej jest zaimplementować narzędzia do automatycznego różnicowania przy użyciu przeciążenia operatora niż przy użyciu tłumaczenia między źródłami. Wdrożenie translatora między źródłami jest równoznaczne z napisaniem kompilatora: kod źródłowy musi zostać przeanalizowany i tokenizowany, a następnie należy zastosować reguły transformacji do wynikowego drzewa wyrażeń. Książka Andreasa Griewank'a, „Ocena pochodnych: zasady i techniki różnicowania algorytmicznego”, wydanie drugie, zawiera bardziej szczegółowe informacje na temat kompromisów.

Do obliczania gradientu używasz odwrotnego trybu AD. Wymaga to w obu przypadkach zbudowania stosu operandów, wersja OO musi także zbudować stos operacji, który należy interpretować w odwrotnej wersji kodu. Kod transformowany źródłowy zapisuje operacje w kolejności odwróconej jako dodatkowy kod źródłowy, który jest kompilowany. Narzut związany z posiadaniem interpretera operacji w kodzie może być znaczny. Istnieją porównania kodu generowanego przez Tapenade i Adol-C, które wychodzą na korzyść Tapenade.