Fix spelling mistakes.

NEWS.md

@@ -79,7 +79,7 @@ gradient update suggested by Gilbert and Nocedal.
 * Error occurred when checking if a step size was finite during line search.
 * DBD method didn't use momentum when asked to.
 * Fix incorrectly specified conjugate gradient descent methods: 
-Hestenes-Steifel (`cg_udpate = "hs"`), Conjugate Descent (`cg_udpate = "cd"`), 
+Hestenes-Stiefel (`cg_udpate = "hs"`), Conjugate Descent (`cg_udpate = "cd"`), 
 Dai-Yuan (`cg_udpate = "dy"`) and Liu-Storey (`cg_udpate = "ls"`).
 
 # mize 0.1.1

vignettes/mize.Rmd

@@ -563,7 +563,7 @@ res <- mize(rb0, rb_fg, max_iter = 10, method = "CG", cg_update = "HZ+",
 
 Another important choice is what step size to start each iteration from. Nocedal
 and Wright suggest two methods based on the result achieved for the previous 
-iteration, one involving the ratio of the slopes at consecutive iteratons, and 
+iteration, one involving the ratio of the slopes at consecutive iterations, and 
 one involving a quadratic interpolation. By default, for Wolfe line searches
 other than `"Hager-Zhang"`, the quadratic interpolation method is tried.
 
@@ -646,9 +646,9 @@ to determine when to terminate the line search. The Hager-Zhang line search uses
 the standard curvature conditions by default. It also uses an approximation to 
 the Armijo sufficient descent conditions which may prevent premature termination
 of a line search when the minimizer lies close to the initial step size under
-some circumstances. Use of these variations on the Wolfe conditons can be applied
-to any of the Wolfe line searches by supplying the `strong_curvature` and 
-`approx_armijo` options:
+some circumstances. Use of these variations on the Wolfe conditions can be
+applied to any of the Wolfe line searches by supplying the `strong_curvature`
+and `approx_armijo` options:
 
 ```{r alternative Wolfe conditions}
 # Rasmussen line search with standard Wolfe conditions

vignettes/mmds.Rmd

@@ -92,7 +92,7 @@ eurodist_mat <- as.matrix(eurodist)
 Writing out the cost function with respect to distances only makes it pretty
 straightforward. However, we need the gradient with respect to the parameters
 we are optimizing, which is the coordinates of each city. Indicating the 
-(two-dimensional) vector that represents the coordintes of city $i$ as 
+(two-dimensional) vector that represents the coordinates of city $i$ as 
 $\mathbf{y_i}$, the gradient of the cost function above is:
 
 $$\frac{\partial C}{\partial \mathbf{y_i}} = 

vignettes/stateful.Rmd

@@ -14,7 +14,7 @@ knitr::opts_chunk$set(echo = TRUE, collapse = TRUE, comment = "#>")
 library(mize)
 ```
 
-By "Stateful" I mean what if we could create an optimizer indepedently of
+By "Stateful" I mean what if we could create an optimizer independently of
 the function it was operating on and be able to pass it around, store it, and
 get full control over when we pass it data to continue the optimization.
 
@@ -117,7 +117,7 @@ for (batch in 1:3) {
 ```
 
 The difference here is that you have to do the iterating in batches of 10 
-manualy yourself, remembering to increment the iteration counter and pass it
+manually yourself, remembering to increment the iteration counter and pass it
 to `mize_step`. Plus, the optimizer needs to be updated with the version that
 was returned from the function.
 
@@ -319,7 +319,7 @@ Apart from just maximum number of iterations, there are a variety of options
 that relate to convergence. There is a separate vignette which covers these
 [convergence options](convergence.html), and all the parameters mentioned there
 can be passed to `make_mize` and `mize_init`. Whatever options you use, 
-setting `max_iter` is a good idea to avoid an infinte loop.
+setting `max_iter` is a good idea to avoid an infinite loop.
 
 Here's the example repeated again, this time using `check_mize_convergence`
 to control the number of iterations, rather than a `for` loop: