Added n-ary vector summation

appengine/findit/libs/math/test/vectors_test.py

Index: appengine/findit/libs/math/test/vectors_test.py
diff --git a/appengine/findit/libs/math/test/vectors_test.py b/appengine/findit/libs/math/test/vectors_test.py
new file mode 100644
index 0000000000000000000000000000000000000000..0e7983d37a7714d834f4164ac669e56143f31b97
--- /dev/null
+++ b/appengine/findit/libs/math/test/vectors_test.py
@@ -0,0 +1,70 @@
+# Copyright 2016 The Chromium Authors. All rights reserved.
+# Use of this source code is governed by a BSD-style license that can be
+# found in the LICENSE file.
+
+import math
+import numpy as np
+import unittest
+
+from libs.math.vectors import vsum
+
+
+BIG = 1e100
+LITTLE = 1
+
+
+class VectorsTest(unittest.TestCase):
+
+  def setUp(self):
+    self._xs = [BIG, LITTLE, -BIG]
+
+  def testFsumKeepsPrecision(self):

[inferno, 2016/12/05 00:12:37]

Should a test be there for testing precision with BIG for testFsumKeepsPrecision
and testVsumKeepsPrecision

[wrengr, 2016/12/05 19:06:43]

I don't know what you mean.

As math.fsum ships with Python, there's no point in testing it for itself; this
test (testFsumKeepsPrecision) is a meta-test to ensure that
testVsumKeepsPrecision is valid as a test of our code. That is, if we pick some
self._xs which causes even math.fsum to fail to keep precision, then vsum has no
hope of doing any better. The key aspect of both tests is that if we evaluate
(BIG + LITTLE - BIG) naively then we will get an answer of zero because the
intermediate value (BIG + LITTLE) looses precision and its absolute difference
against BIG is zero. (FWIW, reordering the summands to the order (LITTLE + BIG -
BIG) would achieve the same result.)

Conversely, testing (BIG + LITTLE - LITTLE) == BIG doesn't achieve the same
purpose. If the intermediate value (BIG + LITTLE) rounds to BIG that's as
expected.

+    """Make sure ``testVsumKeepsPrecision`` should actually work.
+
+    That is, this is a meta-test to make sure that the particular values
+    of ``BIG`` and ``LITTLE`` we use will indeed behave as expected.
+    """
+    # N.B., with precision loss, we'll get 0 rather than LITTLE.
+    self.assertEqual(LITTLE, math.fsum(self._xs))
+
+  def testVsumKeepsPrecision(self):
+    """Ensure that ``vsum`` retains precision over ``sum``.
+
+    Because ``BIG`` is big and ``LITTLE`` is little, performing summation
+    naively will cause the ``LITTLE`` to be lost in rounding errors. This
+    is the same test case as ``testFsumKeepsPrecision``. We make the
+    arrays have more than one element to make sure ``vsum`` actually
+    does work on vectors, as intended. We use variations on ``x`` in the
+    different components just so we don't do the same thing over and over;
+    there's nothing special about negation or doubling.
+    """
+    vs = [np.array([x, -x, 2*x]) for x in self._xs]
+    total = vsum(vs)
+    self.assertIsNotNone(total)
+
+    self.assertListEqual([LITTLE, -LITTLE, 2*LITTLE], total.tolist())
+
+  def testVsumEmptyWithoutShape(self):
+    """Ensure ``vsum`` returns ``None`` when expected.
+
+    The empty summation should return the zero vector. However, since
+    we don't know the shape of the vectors in the list, we don't know
+    what shape of zero vector to return. Thus, we return ``None`` as
+    the only sensible result. This test ensures that actually does happen.
+    """
+    self.assertIsNone(vsum([]))
+
+  def testVSumEmptyWithShape(self):
+    """Ensure ``vsum`` returns the zero vector when expected.
+
+    The empty summation should return the zero vector. If we know the
+    shape of the vectors in the list then we can in fact return the
+    zero vector of the correct shape. This test ensures that actually
+    does happen.
+    """
+    expected_shape = (3,)
+    total = vsum([], shape=expected_shape)
+    self.assertIsNotNone(total)
+    self.assertTupleEqual(expected_shape, total.shape)
+    self.assertListEqual(np.zeros(expected_shape).tolist(), total.tolist())
+