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());
