Prev Next CompareChange

@(@\newcommand{\W}[1]{ \; #1 \; } \newcommand{\R}[1]{ {\rm #1} } \newcommand{\B}[1]{ {\bf #1} } \newcommand{\D}[2]{ \frac{\partial #1}{\partial #2} } \newcommand{\DD}[3]{ \frac{\partial^2 #1}{\partial #2 \partial #3} } \newcommand{\Dpow}[2]{ \frac{\partial^{#1}}{\partial {#2}^{#1}} } \newcommand{\dpow}[2]{ \frac{ {\rm d}^{#1}}{{\rm d}\, {#2}^{#1}} }@)@
Comparison Changes During Zero Order Forward Mode

c = f.CompareChange()
See Also FunCheck

Deprecated 2015-01-20
This routine has been deprecated, use compare_change instead.

We use @(@ F : B^n \rightarrow B^m @)@ to denote the AD function corresponding to f . This function may be not agree with the algorithm that was used to create the corresponding AD of Base operation sequence because of changes in AD comparison results. The CompareChange function can be used to detect these changes.

The object f has prototype
     const ADFun<

The result c has prototype
It is the number of AD<Base> comparison operations, corresponding to the previous call to Forward
f.Forward(0, x)
that have a different result from when F was created by taping an algorithm.

If c is not zero, the boolean values resulting from some of the comparison operations corresponding to x are different from when the AD of Base operation sequence was created. In this case, you may want to re-tape the algorithm with the independent variables equal to the values in x (so AD operation sequence properly represents the algorithm for this value of independent variables). On the other hand, re-taping the AD operation sequence usually takes significantly more time than evaluation using forward_zero . If the functions values have not changed (see FunCheck ) it may not be worth re-taping a new AD operation sequence.
Input File: omh/appendix/deprecated/compare_change.omh