fix typos. Change-Id: I9255d3c6cc0604b227ddfe065c2cdb770dceaf5c

diff --git a/internal/ceres/canonical_views_clustering.h b/internal/ceres/canonical_views_clustering.h
index e7d2472..630adfe 100644
--- a/internal/ceres/canonical_views_clustering.h
+++ b/internal/ceres/canonical_views_clustering.h

@@ -55,8 +55,8 @@
 // canonical views clustering algorithm.
 //
 // In the following we will use the terms vertices and views
-// interchangably.  Given a weighted Graph G(V,E), the canonical views
-// of G are the the set of vertices that best "summarize" the content
+// interchangeably.  Given a weighted Graph G(V,E), the canonical views
+// of G are the set of vertices that best "summarize" the content
 // of the graph. If w_ij i s the weight connecting the vertex i to
 // vertex j, and C is the set of canonical views. Then the objective
 // of the canonical views algorithm is

diff --git a/internal/ceres/corrector.cc b/internal/ceres/corrector.cc
index 7201828..4ac0dc3 100644
--- a/internal/ceres/corrector.cc
+++ b/internal/ceres/corrector.cc

@@ -43,7 +43,7 @@
   sqrt_rho1_ = sqrt(rho[1]);
 
   // If sq_norm = 0.0, the correction becomes trivial, the residual
-  // and the jacobian are scaled by the squareroot of the derivative
+  // and the jacobian are scaled by the square root of the derivative
   // of rho. Handling this case explicitly avoids the divide by zero
   // error that would occur below.
   //
@@ -59,7 +59,7 @@
   // correction which re-wights the gradient of the function by the
   // square root of the derivative of rho, and the Gauss-Newton
   // Hessian gets both the scaling and the rank-1 curvature
-  // correction. Normaly, alpha is upper bounded by one, but with this
+  // correction. Normally, alpha is upper bounded by one, but with this
   // change, alpha is bounded above by zero.
   //
   // Empirically we have observed that the full Triggs correction and

diff --git a/internal/ceres/corrector.h b/internal/ceres/corrector.h
index 315f012..a5b03dd 100644
--- a/internal/ceres/corrector.h
+++ b/internal/ceres/corrector.h

@@ -43,7 +43,7 @@
 // radial robust loss.
 //
 // The key idea here is to look at the expressions for the robustified
-// gauss newton approximation and then take its squareroot to get the
+// gauss newton approximation and then take its square root to get the
 // corresponding corrections to the residual and jacobian.  For the
 // full expressions see Eq. 10 and 11 in BANS by Triggs et al.
 class Corrector {

diff --git a/internal/ceres/cxsparse.h b/internal/ceres/cxsparse.h
index 1789afd..28238d5 100644
--- a/internal/ceres/cxsparse.h
+++ b/internal/ceres/cxsparse.h

@@ -52,7 +52,7 @@
 
 // This object provides access to solving linear systems using Cholesky
 // factorization with a known symbolic factorization. This features does not
-// explicity exist in CXSparse. The methods in the class are nonstatic because
+// explicitly exist in CXSparse. The methods in the class are nonstatic because
 // the class manages internal scratch space.
 class CXSparse {
  public:

diff --git a/internal/ceres/dogleg_strategy.h b/internal/ceres/dogleg_strategy.h
index 046b9d8..11a3bb0 100644
--- a/internal/ceres/dogleg_strategy.h
+++ b/internal/ceres/dogleg_strategy.h

@@ -103,7 +103,7 @@
 
   // mu is used to scale the diagonal matrix used to make the
   // Gauss-Newton solve full rank. In each solve, the strategy starts
-  // out with mu = min_mu, and tries values upto max_mu. If the user
+  // out with mu = min_mu, and tries values up to max_mu. If the user
   // reports an invalid step, the value of mu_ is increased so that
   // the next solve starts with a stronger regularization.
   //

diff --git a/internal/ceres/eigensparse.cc b/internal/ceres/eigensparse.cc
index 425cd8b..9847bfd 100644
--- a/internal/ceres/eigensparse.cc
+++ b/internal/ceres/eigensparse.cc

@@ -89,7 +89,7 @@
                       .template cast<typename Solver::Scalar>();
 
     // The two casts are needed if the Scalar in this class is not
-    // double. For code simplicitly we are going to assume that Eigen
+    // double. For code simplicity we are going to assume that Eigen
     // is smart enough to figure out that casting a double Vector to a
     // double Vector is a straight copy. If this turns into a
     // performance bottleneck (unlikely), we can revisit this.

diff --git a/internal/ceres/generate_bundle_adjustment_tests.py b/internal/ceres/generate_bundle_adjustment_tests.py
index 2f3375a..a3469eb 100644
--- a/internal/ceres/generate_bundle_adjustment_tests.py
+++ b/internal/ceres/generate_bundle_adjustment_tests.py

@@ -31,7 +31,7 @@
 # Generate bundle adjustment tests as separate binaries. Since the bundle
 # adjustment tests are fairly processing intensive, serializing them makes the
 # tests take forever to run. Splitting them into separate binaries makes it
-# easier to parallelize in continous integration systems, and makes local
+# easier to parallelize in continuous integration systems, and makes local
 # processing on multi-core workstations much faster.
 
 # Product of ORDERINGS, THREAD_CONFIGS, and SOLVER_CONFIGS is the full set of

diff --git a/internal/ceres/levenberg_marquardt_strategy.cc b/internal/ceres/levenberg_marquardt_strategy.cc
index e1a0454..9eec631 100644
--- a/internal/ceres/levenberg_marquardt_strategy.cc
+++ b/internal/ceres/levenberg_marquardt_strategy.cc

@@ -100,7 +100,7 @@
   // Invalidate the output array lm_step, so that we can detect if
   // the linear solver generated numerical garbage.  This is known
   // to happen for the DENSE_QR and then DENSE_SCHUR solver when
-  // the Jacobin is severly rank deficient and mu is too small.
+  // the Jacobin is severely rank deficient and mu is too small.
   InvalidateArray(num_parameters, step);
 
   // Instead of solving Jx = -r, solve Jy = r.

diff --git a/internal/ceres/line_search.h b/internal/ceres/line_search.h
index 1c849a0..a162979 100644
--- a/internal/ceres/line_search.h
+++ b/internal/ceres/line_search.h

@@ -51,7 +51,7 @@
 // dimensional optimization problems that arise as subproblems of
 // general multidimensional optimization problems.
 //
-// While finding the exact minimum of a one dimensionl function is
+// While finding the exact minimum of a one dimensional function is
 // hard, instances of LineSearch find a point that satisfies a
 // sufficient decrease condition. Depending on the particular
 // condition used, we get a variety of different line search

diff --git a/internal/ceres/preconditioner.h b/internal/ceres/preconditioner.h
index 47fcdaf..476697d 100644
--- a/internal/ceres/preconditioner.h
+++ b/internal/ceres/preconditioner.h

@@ -55,7 +55,7 @@
     // When using the subset preconditioner, all row blocks starting
     // from this row block are used to construct the preconditioner.
     //
-    // i.e., the Jacobian matrix A is horizonatally partitioned as
+    // i.e., the Jacobian matrix A is horizontally partitioned as
     //
     // A = [P]
     //     [Q]
@@ -157,7 +157,7 @@
   virtual bool UpdateImpl(const MatrixType& A, const double* D) = 0;
 };
 
-// Preconditioners that depend on acccess to the low level structure
+// Preconditioners that depend on access to the low level structure
 // of a SparseMatrix.
 typedef TypedPreconditioner<SparseMatrix>              SparseMatrixPreconditioner;               // NOLINT
 typedef TypedPreconditioner<BlockSparseMatrix>         BlockSparseMatrixPreconditioner;          // NOLINT

diff --git a/internal/ceres/residual_block.h b/internal/ceres/residual_block.h
index 8b8b8ae..6964c6d 100644
--- a/internal/ceres/residual_block.h
+++ b/internal/ceres/residual_block.h

@@ -87,7 +87,7 @@
   // space available.
   //
   // The return value indicates the success or failure. If the function returns
-  // false, the caller should expect the the output memory locations to have
+  // false, the caller should expect the output memory locations to have
   // been modified.
   //
   // The returned cost and jacobians have had robustification and local

diff --git a/internal/ceres/schur_complement_solver.cc b/internal/ceres/schur_complement_solver.cc
index cf6e46c..19f5b06 100644
--- a/internal/ceres/schur_complement_solver.cc
+++ b/internal/ceres/schur_complement_solver.cc

@@ -286,7 +286,7 @@
     }
   }
 
-  // Remaing rows do not contribute to the chunks and directly go
+  // Remaining rows do not contribute to the chunks and directly go
   // into the schur complement via an outer product.
   for (; r < num_row_blocks; ++r) {
     const CompressedRow& row = bs->rows[r];

diff --git a/internal/ceres/schur_eliminator.h b/internal/ceres/schur_eliminator.h
index 0baea93..11e6eba 100644
--- a/internal/ceres/schur_eliminator.h
+++ b/internal/ceres/schur_eliminator.h

@@ -51,7 +51,7 @@
 //
 //  E y + F z = b
 //
-// Where x = [y;z] is a partition of the variables.  The paritioning
+// Where x = [y;z] is a partition of the variables.  The partitioning
 // of the variables is such that, E'E is a block diagonal matrix. Or
 // in other words, the parameter blocks in E form an independent set
 // of the of the graph implied by the block matrix A'A. Then, this
@@ -148,7 +148,7 @@
 // Where the sum is over chunks and E_k'E_k is dense matrix of size y1
 // x y1.
 //
-// Advanced usage. Uptil now it has been assumed that the user would
+// Advanced usage. Until now it has been assumed that the user would
 // be interested in all of the Schur Complement S. However, it is also
 // possible to use this eliminator to obtain an arbitrary submatrix of
 // the full Schur complement. When the eliminator is generating the

diff --git a/internal/ceres/schur_eliminator_impl.h b/internal/ceres/schur_eliminator_impl.h
index bc74015..d754d9d 100644
--- a/internal/ceres/schur_eliminator_impl.h
+++ b/internal/ceres/schur_eliminator_impl.h

@@ -259,7 +259,7 @@
 
         // Compute the outer product of the e_blocks with themselves (ete
         // = E'E). Compute the product of the e_blocks with the
-        // corresonding f_blocks (buffer = E'F), the gradient of the terms
+        // corresponding f_blocks (buffer = E'F), the gradient of the terms
         // in this chunk (g) and add the outer product of the f_blocks to
         // Schur complement (S += F'F).
         ChunkDiagonalBlockAndGradient(
@@ -590,7 +590,7 @@
 // one difference. It does not use any of the template
 // parameters. This is because the algorithm used for detecting the
 // static structure of the matrix A only pays attention to rows with
-// e_blocks. This is becase rows without e_blocks are rare and
+// e_blocks. This is because rows without e_blocks are rare and
 // typically arise from regularization terms in the original
 // optimization problem, and have a very different structure than the
 // rows with e_blocks. Including them in the static structure
@@ -647,7 +647,7 @@
   }
 }
 
-// For a row with an e_block, compute the contribition S += F'F. This
+// For a row with an e_block, compute the contribution S += F'F. This
 // function has the same structure as NoEBlockRowOuterProduct, except
 // that this function uses the template parameters.
 template <int kRowBlockSize, int kEBlockSize, int kFBlockSize>

diff --git a/internal/ceres/schur_jacobi_preconditioner.cc b/internal/ceres/schur_jacobi_preconditioner.cc
index 3a3dffd..1500650 100644
--- a/internal/ceres/schur_jacobi_preconditioner.cc
+++ b/internal/ceres/schur_jacobi_preconditioner.cc

@@ -50,7 +50,7 @@
   CHECK_GT(options_.elimination_groups[0], 0);
   const int num_blocks = bs.cols.size() - options_.elimination_groups[0];
   CHECK_GT(num_blocks, 0)
-      << "Jacobian should have atleast 1 f_block for "
+      << "Jacobian should have at least 1 f_block for "
       << "SCHUR_JACOBI preconditioner.";
   CHECK(options_.context != NULL);
 

diff --git a/internal/ceres/sparse_matrix.h b/internal/ceres/sparse_matrix.h
index b3af1d0..074d847 100644
--- a/internal/ceres/sparse_matrix.h
+++ b/internal/ceres/sparse_matrix.h

@@ -90,7 +90,7 @@
   virtual void ToTextFile(FILE* file) const = 0;
 
   // Accessors for the values array that stores the entries of the
-  // sparse matrix. The exact interpreptation of the values of this
+  // sparse matrix. The exact interpretation of the values of this
   // array depends on the particular kind of SparseMatrix being
   // accessed.
   virtual double* mutable_values() = 0;

diff --git a/internal/ceres/suitesparse.h b/internal/ceres/suitesparse.h
index 6fef0fd..7770d9e 100644
--- a/internal/ceres/suitesparse.h
+++ b/internal/ceres/suitesparse.h

@@ -202,12 +202,12 @@
   // doing sparse direct factorization of these matrices the
   // fill-reducing ordering algorithms (in particular AMD) can either
   // be run on the block or the scalar form of these matrices. The two
-  // SuiteSparse::AnalyzeCholesky methods allows the the client to
+  // SuiteSparse::AnalyzeCholesky methods allows the client to
   // compute the symbolic factorization of a matrix by either using
   // AMD on the matrix or a user provided ordering of the rows.
   //
   // But since the underlying matrices are block oriented, it is worth
-  // running AMD on just the block structre of these matrices and then
+  // running AMD on just the block structure of these matrices and then
   // lifting these block orderings to a full scalar ordering. This
   // preserves the block structure of the permuted matrix, and exposes
   // more of the super-nodal structure of the matrix to the numerical
@@ -321,7 +321,7 @@
   // without checking for the absence of the CERES_NO_CAMD symbol.
   //
   // This is safer because the symbol maybe missing due to a user
-  // accidently not including suitesparse.h in their code when
+  // accidentally not including suitesparse.h in their code when
   // checking for the symbol.
   static bool IsConstrainedApproximateMinimumDegreeOrderingAvailable() {
     return false;

diff --git a/internal/ceres/trust_region_minimizer.cc b/internal/ceres/trust_region_minimizer.cc
index e3d70b0..5505cbb 100644
--- a/internal/ceres/trust_region_minimizer.cc
+++ b/internal/ceres/trust_region_minimizer.cc

@@ -754,7 +754,7 @@
   // small.
   //
   // This can cause the trust region loop to reject this step. To
-  // get around this, we expicitly check if the inner iterations
+  // get around this, we explicitly check if the inner iterations
   // led to a net decrease in the objective function value. If
   // they did, we accept the step even if the trust region ratio
   // is small.

diff --git a/internal/ceres/trust_region_step_evaluator.h b/internal/ceres/trust_region_step_evaluator.h
index 06df102..03c0036 100644
--- a/internal/ceres/trust_region_step_evaluator.h
+++ b/internal/ceres/trust_region_step_evaluator.h

@@ -56,7 +56,7 @@
 // The parameter max_consecutive_nonmonotonic_steps controls the
 // window size used by the step selection algorithm to accept
 // non-monotonic steps. Setting this parameter to zero, recovers the
-// classic montonic descent algorithm.
+// classic monotonic descent algorithm.
 //
 // Based on algorithm 10.1.2 (page 357) of "Trust Region
 // Methods" by Conn Gould & Toint, or equations 33-40 of
@@ -82,7 +82,7 @@
   // max_consecutive_nonmonotonic_steps controls the window size used
   // by the step selection algorithm to accept non-monotonic
   // steps. Setting this parameter to zero, recovers the classic
-  // montonic descent algorithm.
+  // monotonic descent algorithm.
   TrustRegionStepEvaluator(double initial_cost,
                            int max_consecutive_nonmonotonic_steps);
 

diff --git a/internal/ceres/visibility.h b/internal/ceres/visibility.h
index e443766..115d45f 100644
--- a/internal/ceres/visibility.h
+++ b/internal/ceres/visibility.h

@@ -58,7 +58,7 @@
 
 // Given f_block visibility as computed by the ComputeVisibility
 // function above, construct and return a graph whose vertices are
-// f_blocks and an edge connects two vertices if they have atleast one
+// f_blocks and an edge connects two vertices if they have at least one
 // e_block in common. The weight of this edge is normalized dot
 // product between the visibility vectors of the two
 // vertices/f_blocks.

diff --git a/internal/ceres/visibility_based_preconditioner.cc b/internal/ceres/visibility_based_preconditioner.cc
index 41079ab..ed4afb6 100644
--- a/internal/ceres/visibility_based_preconditioner.cc
+++ b/internal/ceres/visibility_based_preconditioner.cc

@@ -78,7 +78,7 @@
   CHECK(options_.type == CLUSTER_JACOBI || options_.type == CLUSTER_TRIDIAGONAL)
       << "Unknown preconditioner type: " << options_.type;
   num_blocks_ = bs.cols.size() - options_.elimination_groups[0];
-  CHECK_GT(num_blocks_, 0) << "Jacobian should have atleast 1 f_block for "
+  CHECK_GT(num_blocks_, 0) << "Jacobian should have at least 1 f_block for "
                            << "visibility based preconditioning.";
   CHECK(options_.context != NULL);
 
@@ -113,7 +113,7 @@
   // preprocessor, so the columns of the Jacobian have not been
   // reordered to minimize fill in when computing its sparse Cholesky
   // factorization. So we must tell the SparseCholesky object to
-  // perform approximiate minimum-degree reordering, which is done by
+  // perform approximate minimum-degree reordering, which is done by
   // setting use_postordering to true.
   sparse_cholesky_options.use_postordering = true;
   sparse_cholesky_ = SparseCholesky::Create(sparse_cholesky_options);
@@ -221,11 +221,11 @@
 // preconditioner or not.
 //
 // A pair of cameras contribute a cell to the preconditioner if they
-// are part of the same cluster or if the the two clusters that they
+// are part of the same cluster or if the two clusters that they
 // belong have an edge connecting them in the degree-2 maximum
 // spanning forest.
 //
-// For example, a camera pair (i,j) where i belonges to cluster1 and
+// For example, a camera pair (i,j) where i belongs to cluster1 and
 // j belongs to cluster2 (assume that cluster1 < cluster2).
 //
 // The cell corresponding to (i,j) is present in the preconditioner
@@ -255,7 +255,7 @@
   //
   // For each e_block/point block we identify the set of cameras
   // seeing it. The cross product of this set with itself is the set
-  // of non-zero cells contibuted by this e_block.
+  // of non-zero cells contributed by this e_block.
   //
   // The time complexity of this is O(nm^2) where, n is the number of
   // 3d points and m is the maximum number of cameras seeing any
@@ -363,7 +363,7 @@
   }
 
   // The scaling only affects the tri-diagonal case, since
-  // ScaleOffDiagonalBlocks only pays attenion to the cells that
+  // ScaleOffDiagonalBlocks only pays attention to the cells that
   // belong to the edges of the degree-2 forest. In the CLUSTER_JACOBI
   // case, the preconditioner is guaranteed to be positive
   // semidefinite.
@@ -483,7 +483,7 @@
   }
 }
 
-// The visibilty set of a cluster is the union of the visibilty sets
+// The visibility set of a cluster is the union of the visibility sets
 // of all its cameras. In other words, the set of points visible to
 // any camera in the cluster.
 void VisibilityBasedPreconditioner::ComputeClusterVisibility(
@@ -524,7 +524,7 @@
       if (intersection.size() > 0) {
         // Clusters interact strongly when they share a large number
         // of 3D points. The degree-2 maximum spanning forest
-        // alorithm, iterates on the edges in decreasing order of
+        // algorithm, iterates on the edges in decreasing order of
         // their weight, which is the number of points shared by the
         // two cameras that it connects.
         cluster_graph->AddEdge(i, j, intersection.size());