Cleanup based on comments by William Rucklidge
Change-Id: If269ba8e388965a8ea32260fd6f17a133a19ab9b
diff --git a/internal/ceres/line_search_direction.cc b/internal/ceres/line_search_direction.cc
index 2f27a78..1fc4de5 100644
--- a/internal/ceres/line_search_direction.cc
+++ b/internal/ceres/line_search_direction.cc
@@ -81,7 +81,7 @@
*search_direction = -current.gradient + beta * previous.search_direction;
const double directional_derivative =
- current. gradient.dot(*search_direction);
+ current.gradient.dot(*search_direction);
if (directional_derivative > -function_tolerance_) {
LOG(WARNING) << "Restarting non-linear conjugate gradients: "
<< directional_derivative;
diff --git a/internal/ceres/linear_solver.h b/internal/ceres/linear_solver.h
index a980514..5aeedcd 100644
--- a/internal/ceres/linear_solver.h
+++ b/internal/ceres/linear_solver.h
@@ -106,11 +106,11 @@
//
// For example if elimination_groups is a vector of size k, then
// the linear solver is informed that it should eliminate the
- // parameter blocks 0 - elimination_groups[0] - 1 first, and then
- // elimination_groups[0] - elimination_groups[1] and so on. Within
- // each elimination group, the linear solver is free to choose how
- // the parameter blocks are ordered. Different linear solvers have
- // differing requirements on elimination_groups.
+ // parameter blocks 0 ... elimination_groups[0] - 1 first, and
+ // then elimination_groups[0] ... elimination_groups[1] - 1 and so
+ // on. Within each elimination group, the linear solver is free to
+ // choose how the parameter blocks are ordered. Different linear
+ // solvers have differing requirements on elimination_groups.
//
// The most common use is for Schur type solvers, where there
// should be at least two elimination groups and the first
diff --git a/internal/ceres/mutex.h b/internal/ceres/mutex.h
index 410748f..0c48ed3 100644
--- a/internal/ceres/mutex.h
+++ b/internal/ceres/mutex.h
@@ -275,7 +275,8 @@
// "MutexLock(x) COMPILE_ASSERT(false)". To work around this, "Ceres" is
// prefixed to the class names; this permits defining the classes.
-// CeresMutexLock(mu) acquires mu when constructed and releases it when destroyed.
+// CeresMutexLock(mu) acquires mu when constructed and releases it
+// when destroyed.
class CeresMutexLock {
public:
explicit CeresMutexLock(Mutex *mu) : mu_(mu) { mu_->Lock(); }
diff --git a/internal/ceres/preconditioner.h b/internal/ceres/preconditioner.h
index 5bb077e..894a2e6 100644
--- a/internal/ceres/preconditioner.h
+++ b/internal/ceres/preconditioner.h
@@ -70,7 +70,7 @@
// For example if elimination_groups is a vector of size k, then
// the linear solver is informed that it should eliminate the
// parameter blocks 0 ... elimination_groups[0] - 1 first, and
- // then elimination_groups[0] ... elimination_groups[1] and so
+ // then elimination_groups[0] ... elimination_groups[1] - 1 and so
// on. Within each elimination group, the linear solver is free to
// choose how the parameter blocks are ordered. Different linear
// solvers have differing requirements on elimination_groups.
diff --git a/internal/ceres/problem_impl.cc b/internal/ceres/problem_impl.cc
index bc378aa..1fb9e39 100644
--- a/internal/ceres/problem_impl.cc
+++ b/internal/ceres/problem_impl.cc
@@ -657,8 +657,8 @@
gradient != NULL ? &(*gradient)[0] : NULL,
tmp_jacobian.get());
- // Make the parameter blocks that were temporarirly marked
- // constant, variable again.
+ // Make the parameter blocks that were temporarily marked constant,
+ // variable again.
for (int i = 0; i < variable_parameter_blocks.size(); ++i) {
variable_parameter_blocks[i]->SetVarying();
}
diff --git a/internal/ceres/problem_test.cc b/internal/ceres/problem_test.cc
index 130148d..888eb7c 100644
--- a/internal/ceres/problem_test.cc
+++ b/internal/ceres/problem_test.cc
@@ -769,7 +769,7 @@
// Simple cost function used for testing Problem::Evaluate.
//
// r_i = i - (j + 1) * x_ij^2
-template <int kNumResiduals, int kNumParameterBlocks >
+template <int kNumResiduals, int kNumParameterBlocks>
class QuadraticCostFunction : public CostFunction {
public:
QuadraticCostFunction() {
diff --git a/internal/ceres/solver.cc b/internal/ceres/solver.cc
index 6436d2d..45e6865 100644
--- a/internal/ceres/solver.cc
+++ b/internal/ceres/solver.cc
@@ -204,7 +204,7 @@
StringAppendF(&report, "\n");
StringAppendF(&report, "\n");
- StringAppendF(&report, "%45s %21s\n", "Given", "Used");
+ StringAppendF(&report, "%45s %21s\n", "Given", "Used");
StringAppendF(&report, "Linear solver %25s%25s\n",
LinearSolverTypeToString(linear_solver_type_given),
LinearSolverTypeToString(linear_solver_type_used));
@@ -299,15 +299,15 @@
// LINE_SEARCH
StringAppendF(&report, "\nMinimizer %19s\n", "LINE_SEARCH");
if (line_search_direction_type == LBFGS) {
- StringAppendF(&report, "Line search direction %19s(%d)\n",
+ StringAppendF(&report, "Line search direction %19s(%d)\n",
LineSearchDirectionTypeToString(line_search_direction_type),
max_lbfgs_rank);
} else {
- StringAppendF(&report, "Line search direction %19s\n",
+ StringAppendF(&report, "Line search direction %19s\n",
LineSearchDirectionTypeToString(
line_search_direction_type));
}
- StringAppendF(&report, "Line search type %19s\n",
+ StringAppendF(&report, "Line search type %19s\n",
LineSearchTypeToString(line_search_type));
StringAppendF(&report, "\n");
diff --git a/internal/ceres/visibility.cc b/internal/ceres/visibility.cc
index 8e80fd1..371bdfa 100644
--- a/internal/ceres/visibility.cc
+++ b/internal/ceres/visibility.cc
@@ -139,7 +139,8 @@
const int count = it->second;
// Static cast necessary for Windows.
const double weight = static_cast<double>(count) /
- (sqrt(static_cast<double>(visibility[camera1].size() * visibility[camera2].size())));
+ (sqrt(static_cast<double>(
+ visibility[camera1].size() * visibility[camera2].size())));
graph->AddEdge(camera1, camera2, weight);
}
diff --git a/internal/ceres/visibility_based_preconditioner.h b/internal/ceres/visibility_based_preconditioner.h
index 8a09c78..dae4987 100644
--- a/internal/ceres/visibility_based_preconditioner.h
+++ b/internal/ceres/visibility_based_preconditioner.h
@@ -38,7 +38,8 @@
// documented here can be found in
//
// Visibility Based Preconditioning for Bundle Adjustment
-// A. Kushal & S. Agarwal, submitted to CVPR 2012
+// A. Kushal & S. Agarwal, CVPR 2012.
+//
// http://www.cs.washington.edu/homes/sagarwal/vbp.pdf
//
// The two preconditioners share enough code that its most efficient
