Misc. small cleanups

webrtc/modules/audio_processing/beamformer/nonlinear_beamformer.cc

Index: webrtc/modules/audio_processing/beamformer/nonlinear_beamformer.cc
diff --git a/webrtc/modules/audio_processing/beamformer/nonlinear_beamformer.cc b/webrtc/modules/audio_processing/beamformer/nonlinear_beamformer.cc
index 029fa089fc761704dc69dec031f0abcf79471580..0544104b79e9cab12b92d58383462d71ae450eae 100644
--- a/webrtc/modules/audio_processing/beamformer/nonlinear_beamformer.cc
+++ b/webrtc/modules/audio_processing/beamformer/nonlinear_beamformer.cc
@@ -163,7 +163,7 @@ void TransposedConjugatedProduct(const ComplexMatrix<float>& in,
 }
 
 std::vector<Point> GetCenteredArray(std::vector<Point> array_geometry) {
-  for (int dim = 0; dim < 3; ++dim) {
+  for (size_t dim = 0; dim < 3; ++dim) {
     float center = 0.f;
     for (size_t i = 0; i < array_geometry.size(); ++i) {
       center += array_geometry[i].c[dim];
@@ -379,7 +379,7 @@ void NonlinearBeamformer::ProcessChunk(const ChannelBuffer<float>& input,
       (high_pass_postfilter_mask_ - old_high_pass_mask) /
       input.num_frames_per_band();
   // Apply the smoothed high-pass mask to the first channel of each band.
-  // This can be done because the effct of the linear beamformer is negligible
+  // This can be done because the effect of the linear beamformer is negligible
   // compared to the post-filter.
   for (size_t i = 1; i < input.num_bands(); ++i) {
     float smoothed_mask = old_high_pass_mask;
@@ -412,9 +412,9 @@ void NonlinearBeamformer::ProcessAudioBlock(const complex_f* const* input,
                                             size_t num_freq_bins,
                                             int num_output_channels,
                                             complex_f* const* output) {
-  RTC_CHECK_EQ(num_freq_bins, kNumFreqBins);
-  RTC_CHECK_EQ(num_input_channels, num_input_channels_);
-  RTC_CHECK_EQ(num_output_channels, 1);
+  RTC_CHECK_EQ(kNumFreqBins, num_freq_bins);

[hlundin-webrtc, 2016/01/07 10:57:06]

Does the order of the arguments matter for CHECK? I know it produces nicer
print-outs for gtest's EXPECT_EQ, but what is the rationale here?

[Peter Kasting, 2016/01/07 12:14:13]

Examining the source code, it looks like it doesn't matter for these specific
macros; the macros just treat the args as "val1" and "val2".

At least some of us in Chromium have been in the habit of always using
(expected, actual) ordering for _EQ and _NE macros of any type, so as to simply
be consistent and not have to think about which type of checking macro is in
use.  (Which is part of why I didn't know the answer to your question without
reading the source.)  Whether you find that rationale compelling here is up to
you.  If not, I can revert these changes.  Let me know.

[hlundin-webrtc, 2016/01/07 12:24:31]

Either is fine.

+  RTC_CHECK_EQ(num_input_channels_, num_input_channels);
+  RTC_CHECK_EQ(1, num_output_channels);
 
   // Calculating the post-filter masks. Note that we need two for each
   // frequency bin to account for the positive and negative interferer