Run this notebook online:\ |Binder| or Colab: |Colab| .. |Binder| image:: https://mybinder.org/badge_logo.svg :target: https://mybinder.org/v2/gh/deepjavalibrary/d2l-java/master?filepath=chapter_optimization/gd.ipynb .. |Colab| image:: https://colab.research.google.com/assets/colab-badge.svg :target: https://colab.research.google.com/github/deepjavalibrary/d2l-java/blob/colab/chapter_optimization/gd.ipynb .. _sec_gd: Gradient Descent ================ In this section we are going to introduce the basic concepts underlying gradient descent. This is brief by necessity. See e.g., :cite:`Boyd.Vandenberghe.2004` for an in-depth introduction to convex optimization. Although the latter is rarely used directly in deep learning, an understanding of gradient descent is key to understanding stochastic gradient descent algorithms. For instance, the optimization problem might diverge due to an overly large learning rate. This phenomenon can already be seen in gradient descent. Likewise, preconditioning is a common technique in gradient descent and carries over to more advanced algorithms. Let us start with a simple special case. Gradient Descent in One Dimension --------------------------------- Gradient descent in one dimension is an excellent example to explain why the gradient descent algorithm may reduce the value of the objective function. Consider some continuously differentiable real-valued function :math:`f: \mathbb{R} \rightarrow \mathbb{R}`. Using a Taylor expansion (:numref:`sec_single_variable_calculus`) we obtain that .. math:: f(x + \epsilon) = f(x) + \epsilon f'(x) + \mathcal{O}(\epsilon^2). :label: gd-taylor That is, in first approximation :math:`f(x+\epsilon)` is given by the function value :math:`f(x)` and the first derivative :math:`f'(x)` at :math:`x`. It is not unreasonable to assume that for small :math:`\epsilon` moving in the direction of the negative gradient will decrease :math:`f`. To keep things simple we pick a fixed step size :math:`\eta > 0` and choose :math:`\epsilon = -\eta f'(x)`. Plugging this into the Taylor expansion above we get .. math:: f(x - \eta f'(x)) = f(x) - \eta f'^2(x) + \mathcal{O}(\eta^2 f'^2(x)). If the derivative :math:`f'(x) \neq 0` does not vanish we make progress since :math:`\eta f'^2(x)>0`. Moreover, we can always choose :math:`\eta` small enough for the higher order terms to become irrelevant. Hence we arrive at .. math:: f(x - \eta f'(x)) \lessapprox f(x). This means that, if we use .. math:: x \leftarrow x - \eta f'(x) to iterate :math:`x`, the value of function :math:`f(x)` might decline. Therefore, in gradient descent we first choose an initial value :math:`x` and a constant :math:`\eta > 0` and then use them to continuously iterate :math:`x` until the stop condition is reached, for example, when the magnitude of the gradient :math:`|f'(x)|` is small enough or the number of iterations has reached a certain value. For simplicity we choose the objective function :math:`f(x)=x^2` to illustrate how to implement gradient descent. Although we know that :math:`x=0` is the solution to minimize :math:`f(x)`, we still use this simple function to observe how :math:`x` changes. As always, we begin by importing all required modules. .. code:: java %load ../utils/djl-imports %load ../utils/plot-utils %load ../utils/Functions.java .. code:: java Function f = x -> x * x; // Objective Function Function gradf = x -> 2 * x; // Its Derivative NDManager manager = NDManager.newBaseManager(); Next, we use :math:`x=10` as the initial value and assume :math:`\eta=0.2`. Using gradient descent to iterate :math:`x` for 10 times we can see that, eventually, the value of :math:`x` approaches the optimal solution. .. code:: java public float[] gd(float eta) { float x = 10f; float[] results = new float[11]; results[0] = x; for (int i = 0; i < 10; i++) { x -= eta * gradf.apply(x); results[i + 1] = x; } System.out.printf("epoch 10, x: %f\n", x); return results; } float[] res = gd(0.2f); .. parsed-literal:: :class: output epoch 10, x: 0.060466 The progress of optimizing over :math:`x` can be plotted as follows. .. code:: java /* Saved in GradDescUtils.java */ public void plotGD(float[] x, float[] y, float[] segment, Function func, int width, int height) { // Function Line ScatterTrace trace = ScatterTrace.builder(Functions.floatToDoubleArray(x), Functions.floatToDoubleArray(y)) .mode(ScatterTrace.Mode.LINE) .build(); // GD Line ScatterTrace trace2 = ScatterTrace.builder(Functions.floatToDoubleArray(segment), Functions.floatToDoubleArray(Functions.callFunc(segment, func))) .mode(ScatterTrace.Mode.LINE) .build(); // GD Points ScatterTrace trace3 = ScatterTrace.builder(Functions.floatToDoubleArray(segment), Functions.floatToDoubleArray(Functions.callFunc(segment, func))) .build(); Layout layout = Layout.builder() .height(height) .width(width) .showLegend(false) .build(); display(new Figure(layout, trace, trace2, trace3)); } .. code:: java /* Saved in GradDescUtils.java */ public void showTrace(float[] res) { float n = 0; for (int i = 0; i < res.length; i++) { if (Math.abs(res[i]) > n) { n = Math.abs(res[i]); } } NDArray fLineND = manager.arange(-n, n, 0.01f); float[] fLine = fLineND.toFloatArray(); plotGD(fLine, Functions.callFunc(fLine, f), res, f, 500, 400); } showTrace(res); .. raw:: html
.. _section_gd-learningrate: Learning Rate ~~~~~~~~~~~~~ The learning rate :math:`\eta` can be set by the algorithm designer. If we use a learning rate that is too small, it will cause :math:`x` to update very slowly, requiring more iterations to get a better solution. To show what happens in such a case, consider the progress in the same optimization problem for :math:`\eta = 0.05`. As we can see, even after 10 steps we are still very far from the optimal solution. .. code:: java showTrace(gd(0.05f)); .. parsed-literal:: :class: output epoch 10, x: 3.486785 .. raw:: html
Conversely, if we use an excessively high learning rate, :math:`\left|\eta f'(x)\right|` might be too large for the first-order Taylor expansion formula. That is, the term :math:`\mathcal{O}(\eta^2 f'^2(x))` in :eq:`gd-taylor` might become significant. In this case, we cannot guarantee that the iteration of :math:`x` will be able to lower the value of :math:`f(x)`. For example, when we set the learning rate to :math:`\eta=1.1`, :math:`x` overshoots the optimal solution :math:`x=0` and gradually diverges. .. code:: java showTrace(gd(1.1f)); .. parsed-literal:: :class: output epoch 10, x: 61.917389 .. raw:: html
Local Minima ~~~~~~~~~~~~ To illustrate what happens for nonconvex functions consider the case of :math:`f(x) = x \cdot \cos c x`. This function has infinitely many local minima. Depending on our choice of learning rate and depending on how well conditioned the problem is, we may end up with one of many solutions. The example below illustrates how an (unrealistically) high learning rate will lead to a poor local minimum. .. code:: java float c = (float)(0.15f * Math.PI); Function f = x -> x * (float)Math.cos(c * x); Function gradf = x -> (float)(Math.cos(c * x) - c * x * Math.sin(c * x)); showTrace(gd(2)); .. parsed-literal:: :class: output epoch 10, x: -1.528166 .. raw:: html
Multivariate Gradient Descent ----------------------------- Now that we have a better intuition of the univariate case, let us consider the situation where :math:`\mathbf{x} \in \mathbb{R}^d`. That is, the objective function :math:`f: \mathbb{R}^d \to \mathbb{R}` maps vectors into scalars. Correspondingly its gradient is multivariate, too. It is a vector consisting of :math:`d` partial derivatives: .. math:: \nabla f(\mathbf{x}) = \bigg[\frac{\partial f(\mathbf{x})}{\partial x_1}, \frac{\partial f(\mathbf{x})}{\partial x_2}, \ldots, \frac{\partial f(\mathbf{x})}{\partial x_d}\bigg]^\top. Each partial derivative element :math:`\partial f(\mathbf{x})/\partial x_i` in the gradient indicates the rate of change of :math:`f` at :math:`\mathbf{x}` with respect to the input :math:`x_i`. As before in the univariate case we can use the corresponding Taylor approximation for multivariate functions to get some idea of what we should do. In particular, we have that .. math:: f(\mathbf{x} + \mathbf{\epsilon}) = f(\mathbf{x}) + \mathbf{\epsilon}^\top \nabla f(\mathbf{x}) + \mathcal{O}(\|\mathbf{\epsilon}\|^2). :label: gd-multi-taylor In other words, up to second order terms in :math:`\mathbf{\epsilon}` the direction of steepest descent is given by the negative gradient :math:`-\nabla f(\mathbf{x})`. Choosing a suitable learning rate :math:`\eta > 0` yields the prototypical gradient descent algorithm: :math:`\mathbf{x} \leftarrow \mathbf{x} - \eta \nabla f(\mathbf{x}).` To see how the algorithm behaves in practice let us construct an objective function :math:`f(\mathbf{x})=x_1^2+2x_2^2` with a two-dimensional vector :math:`\mathbf{x} = [x_1, x_2]^\top` as input and a scalar as output. The gradient is given by :math:`\nabla f(\mathbf{x}) = [2x_1, 4x_2]^\top`. We will observe the trajectory of :math:`\mathbf{x}` by gradient descent from the initial position :math:`[-5, -2]`. We need two more helper functions. The first uses an update function and applies it :math:`20` times to the initial value. The second helper visualizes the trajectory of :math:`\mathbf{x}`. We also create a ``Weights`` class to make it easier to store the weight parameters and return them in functions. .. code:: java /* Saved in GradDescUtils.java */ public class Weights { public float x1, x2; public Weights(float x1, float x2) { this.x1 = x1; this.x2 = x2; } } /* Saved in GradDescUtils.java */ /* Optimize a 2D objective function with a customized trainer. */ public ArrayList train2d(Function trainer, int steps) { // s1 and s2 are internal state variables and will // be used later in the chapter float x1 = -5f, x2 = -2f, s1 = 0f, s2 = 0f; ArrayList results = new ArrayList<>(); results.add(new Weights(x1, x2)); for (int i = 1; i < steps + 1; i++) { Float[] step = trainer.apply(new Float[]{x1, x2, s1, s2}); x1 = step[0]; x2 = step[1]; s1 = step[2]; s2 = step[3]; results.add(new Weights(x1, x2)); System.out.printf("epoch %d, x1 %f, x2 %f\n", i, x1, x2); } return results; } import java.util.function.BiFunction; /* Saved in GradDescUtils.java */ /* Show the trace of 2D variables during optimization. */ public void showTrace2d(BiFunction f, ArrayList results) { // TODO: add when tablesaw adds support for contour and meshgrids } Next, we observe the trajectory of the optimization variable :math:`\mathbf{x}` for learning rate :math:`\eta = 0.1`. We can see that after 20 steps the value of :math:`\mathbf{x}` approaches its minimum at :math:`[0, 0]`. Progress is fairly well-behaved albeit rather slow. .. code:: java float eta = 0.1f; BiFunction f = (x1, x2) -> x1 * x1 + 2 * x2 * x2; // Objective BiFunction gradf = (x1, x2) -> new Float[]{2 * x1, 4 * x2}; // Gradient Function gd = (state) -> { Float x1 = state[0]; Float x2 = state[1]; Float[] g = gradf.apply(x1, x2); // Compute Gradient Float g1 = g[0]; Float g2 = g[1]; return new Float[]{x1 - eta * g1, x2 - eta * g2, 0f, 0f}; // Update Variables }; showTrace2d(f, train2d(gd, 20)); .. parsed-literal:: :class: output epoch 1, x1 -4.000000, x2 -1.200000 epoch 2, x1 -3.200000, x2 -0.720000 epoch 3, x1 -2.560000, x2 -0.432000 epoch 4, x1 -2.048000, x2 -0.259200 epoch 5, x1 -1.638400, x2 -0.155520 epoch 6, x1 -1.310720, x2 -0.093312 epoch 7, x1 -1.048576, x2 -0.055987 epoch 8, x1 -0.838861, x2 -0.033592 epoch 9, x1 -0.671089, x2 -0.020155 epoch 10, x1 -0.536871, x2 -0.012093 epoch 11, x1 -0.429497, x2 -0.007256 epoch 12, x1 -0.343597, x2 -0.004354 epoch 13, x1 -0.274878, x2 -0.002612 epoch 14, x1 -0.219902, x2 -0.001567 epoch 15, x1 -0.175922, x2 -0.000940 epoch 16, x1 -0.140737, x2 -0.000564 epoch 17, x1 -0.112590, x2 -0.000339 epoch 18, x1 -0.090072, x2 -0.000203 epoch 19, x1 -0.072058, x2 -0.000122 epoch 20, x1 -0.057646, x2 -0.000073 .. figure:: https://d2l-java-resources.s3.amazonaws.com/img/contour_gd.svg Contour Gradient Descent. Adaptive Methods ---------------- As we could see in :numref:`section_gd-learningrate`, getting the learning rate :math:`\eta` "just right" is tricky. If we pick it too small, we make no progress. If we pick it too large, the solution oscillates and in the worst case it might even diverge. What if we could determine :math:`\eta` automatically or get rid of having to select a step size at all? Second order methods that look not only at the value and gradient of the objective but also at its *curvature* can help in this case. While these methods cannot be applied to deep learning directly due to the computational cost, they provide useful intuition into how to design advanced optimization algorithms that mimic many of the desirable properties of the algorithms outlined below. Newton's Method ~~~~~~~~~~~~~~~ Reviewing the Taylor expansion of :math:`f` there is no need to stop after the first term. In fact, we can write it as .. math:: f(\mathbf{x} + \mathbf{\epsilon}) = f(\mathbf{x}) + \mathbf{\epsilon}^\top \nabla f(\mathbf{x}) + \frac{1}{2} \mathbf{\epsilon}^\top \nabla \nabla^\top f(\mathbf{x}) \mathbf{\epsilon} + \mathcal{O}(\|\mathbf{\epsilon}\|^3). :label: gd-hot-taylor To avoid cumbersome notation we define :math:`H_f := \nabla \nabla^\top f(\mathbf{x})` to be the *Hessian* of :math:`f`. This is a :math:`d \times d` matrix. For small :math:`d` and simple problems :math:`H_f` is easy to compute. For deep networks, on the other hand, :math:`H_f` may be prohibitively large, due to the cost of storing :math:`\mathcal{O}(d^2)` entries. Furthermore it may be too expensive to compute via backprop as we would need to apply backprop to the backpropagation call graph. For now let us ignore such considerations and look at what algorithm we'd get. After all, the minimum of :math:`f` satisfies :math:`\nabla f(\mathbf{x}) = 0`. Taking derivatives of :eq:`gd-hot-taylor` with regard to :math:`\mathbf{\epsilon}` and ignoring higher order terms we arrive at .. math:: \nabla f(\mathbf{x}) + H_f \mathbf{\epsilon} = 0 \text{ and hence } \mathbf{\epsilon} = -H_f^{-1} \nabla f(\mathbf{x}). That is, we need to invert the Hessian :math:`H_f` as part of the optimization problem. For :math:`f(x) = \frac{1}{2} x^2` we have :math:`\nabla f(x) = x` and :math:`H_f = 1`. Hence for any :math:`x` we obtain :math:`\epsilon = -x`. In other words, a single step is sufficient to converge perfectly without the need for any adjustment! Alas, we got a bit lucky here since the Taylor expansion was exact. Let us see what happens in other problems. .. code:: java float c = 0.5f; Function f = x -> (float)Math.cosh(c * x); // Objective Function gradf = x -> c * (float)Math.sinh(c * x); // Derivative Function hessf = x -> c * c * (float)Math.cosh(c * x); // Hessian // Hide learning rate for now public float[] newton(float eta) { float x = 10f; float[] results = new float[11]; results[0] = x; for (int i = 0; i < 10; i++) { x -= eta * gradf.apply(x) / hessf.apply(x); results[i + 1] = x; } System.out.printf("epoch 10, x: %f\n", x); return results; } showTrace(newton(1)); .. parsed-literal:: :class: output epoch 10, x: 0.000000 .. raw:: html
Now let us see what happens when we have a *nonconvex* function, such as :math:`f(x) = x \cos(c x)`. After all, note that in Newton's method we end up dividing by the Hessian. This means that if the second derivative is *negative* we would walk into the direction of *increasing* :math:`f`. That is a fatal flaw of the algorithm. Let us see what happens in practice. .. code:: java c = 0.15f * (float)Math.PI; Function f = x -> x * (float)Math.cos(c * x); Function gradf = x -> (float)(Math.cos(c * x) - c * x * Math.sin(c * x)); Function hessf = x -> (float)(-2 * c * Math.sin(c * x) - x * c * c * Math.cos(c * x)); showTrace(newton(1)); .. parsed-literal:: :class: output epoch 10, x: 26.834131 .. raw:: html
This went spectacularly wrong. How can we fix it? One way would be to "fix" the Hessian by taking its absolute value instead. Another strategy is to bring back the learning rate. This seems to defeat the purpose, but not quite. Having second order information allows us to be cautious whenever the curvature is large and to take longer steps whenever the objective is flat. Let us see how this works with a slightly smaller learning rate, say :math:`\eta = 0.5`. As we can see, we have quite an efficient algorithm. .. code:: java showTrace(newton(0.5f)); .. parsed-literal:: :class: output epoch 10, x: 7.269859 .. raw:: html
Convergence Analysis ~~~~~~~~~~~~~~~~~~~~ We only analyze the convergence rate for convex and three times differentiable :math:`f`, where at its minimum :math:`x^*` the second derivative is nonzero, i.e., where :math:`f''(x^*) > 0`. The multivariate proof is a straightforward extension of the argument below and omitted since it doesn't help us much in terms of intuition. Denote by :math:`x_k` the value of :math:`x` at the :math:`k`-th iteration and let :math:`e_k := x_k - x^*` be the distance from optimality. By Taylor series expansion we have that the condition :math:`f'(x^*) = 0` can be written as .. math:: 0 = f'(x_k - e_k) = f'(x_k) - e_k f''(x_k) + \frac{1}{2} e_k^2 f'''(\xi_k). This holds for some :math:`\xi_k \in [x_k - e_k, x_k]`. Recall that we have the update :math:`x_{k+1} = x_k - f'(x_k) / f''(x_k)`. Dividing the above expansion by :math:`f''(x_k)` yields .. math:: e_k - f'(x_k) / f''(x_k) = \frac{1}{2} e_k^2 f'''(\xi_k) / f''(x_k). Plugging in the update equations leads to the following bound :math:`e_{k+1} \leq e_k^2 f'''(\xi_k) / f'(x_k)`. Consequently, whenever we are in a region of bounded :math:`f'''(\xi_k) / f''(x_k) \leq c`, we have a quadratically decreasing error :math:`e_{k+1} \leq c e_k^2`. As an aside, optimization researchers call this *linear* convergence, whereas a condition such as :math:`e_{k+1} \leq \alpha e_k` would be called a *constant* rate of convergence. Note that this analysis comes with a number of caveats: We do not really have much of a guarantee when we will reach the region of rapid convergence. Instead, we only know that once we reach it, convergence will be very quick. Second, this requires that :math:`f` is well-behaved up to higher order derivatives. It comes down to ensuring that :math:`f` does not have any "surprising" properties in terms of how it might change its values. Preconditioning ~~~~~~~~~~~~~~~ Quite unsurprisingly computing and storing the full Hessian is very expensive. It is thus desirable to find alternatives. One way to improve matters is by avoiding to compute the Hessian in its entirety but only compute the *diagonal* entries. While this is not quite as good as the full Newton method, it is still much better than not using it. Moreover, estimates for the main diagonal elements are what drives some of the innovation in stochastic gradient descent optimization algorithms. This leads to update algorithms of the form .. math:: \mathbf{x} \leftarrow \mathbf{x} - \eta \mathrm{diag}(H_f)^{-1} \nabla \mathbf{x}. To see why this might be a good idea consider a situation where one variable denotes height in millimeters and the other one denotes height in kilometers. Assuming that for both the natural scale is in meters we have a terrible mismatch in parameterizations. Using preconditioning removes this. Effectively preconditioning with gradient descent amounts to selecting a different learning rate for each coordinate. Gradient Descent with Line Search ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ One of the key problems in gradient descent was that we might overshoot the goal or make insufficient progress. A simple fix for the problem is to use line search in conjunction with gradient descent. That is, we use the direction given by :math:`\nabla f(\mathbf{x})` and then perform binary search as to which step length :math:`\eta` minimizes :math:`f(\mathbf{x} - \eta \nabla f(\mathbf{x}))`. This algorithm converges rapidly (for an analysis and proof see e.g., :cite:`Boyd.Vandenberghe.2004`). However, for the purpose of deep learning this is not quite so feasible, since each step of the line search would require us to evaluate the objective function on the entire dataset. This is way too costly to accomplish. Summary ------- - Learning rates matter. Too large and we diverge, too small and we do not make progress. - Gradient descent can get stuck in local minima. - In high dimensions adjusting learning the learning rate is complicated. - Preconditioning can help with scale adjustment. - Newton's method is a lot faster *once* it has started working properly in convex problems. - Beware of using Newton's method without any adjustments for nonconvex problems. Exercises --------- 1. Experiment with different learning rates and objective functions for gradient descent. 2. Implement line search to minimize a convex function in the interval :math:`[a, b]`. - Do you need derivatives for binary search, i.e., to decide whether to pick :math:`[a, (a+b)/2]` or :math:`[(a+b)/2, b]`. - How rapid is the rate of convergence for the algorithm? - Implement the algorithm and apply it to minimizing :math:`\log (\exp(x) + \exp(-2*x -3))`. 3. Design an objective function defined on :math:`\mathbb{R}^2` where gradient descent is exceedingly slow. Hint - scale different coordinates differently. 4. Implement the lightweight version of Newton's method using preconditioning: - Use diagonal Hessian as preconditioner. - Use the absolute values of that rather than the actual (possibly signed) values. - Apply this to the problem above. 5. Apply the algorithm above to a number of objective functions (convex or not). What happens if you rotate coordinates by :math:`45` degrees?