Add sum stat to basicstats aggregator

[cpacey]

Implements #3467. sum is not included by default to maintain backwards compatibility.

Required for all PRs:

• Signed CLA.
• Associated README.md updated.
• Has appropriate unit tests.

[cpacey]

This seemed the simplest way to implement it.

[JeffAshton]

And cheapest for backwards compatibility case

[cpacey]

This might be overkill, but I like the idea of verifying "default configuration" separately from verifying "aggregations are working".

[JeffAshton]

Hey @danielnelson , I would love to use this feature to help simplify my continuous queries. Do you have time to take a look?

[danielnelson]

One thing I'm worried about is that we might see some weird floating point artifacts that wouldn't appear if we kept a running sum:

cpu value=1 1519251291871635057
cpu value=1 1519251291871803032
cpu value=1 1519251291871857634
cpu value=1 1519251291871884218
cpu value=2 1519251291871907024
cpu value=1 1519251291871931726
cpu value_sum=6.999999999999999 1519251294000000000

[cpacey]

@danielnelson I'll switch to tracking sum as we go. Would you like to keep tracking mean as it's done now, or would you want to switch to calculating the mean based on sum and count? The former simplifies the code change and reduces the likelihood of changing previous behaviour; the latter simplifies the code and reduces calculation cost.

[danielnelson]

Let's switch to calculating the mean based on sum and count.

[cpacey]

@danielnelson I've switched to keeping a running sum (and added a test for the floating-point problem you were concerned about). However, when I tried to remove tracking the mean, the naive approach added another floating-point divide when calculating variance (example here). Do we care about a potential performance impact of this? I haven't measured anything yet - I wanted to get a sense of whether you'd be concerned before investing time.

If you are concerned, options I see are: continue tracking the mean; or rearranging the variance equations to avoid the extra floating-point divide, but at the cost of an extra floating-point multiplication (example here).

[danielnelson]

In the first example, doesn't it equal out since we can remove this divide?

mean = mean + delta/n

[cpacey]

Not without changing the stdev calculation, which I'm not excited to do.

The online variance algorithm produces its estimate by using both the current mean and the previous mean. In the current code, the previous mean is tracked, and the new mean is calculated with a single divide (mean + delta/n). If we stop tracking the mean, then we need to compute both the previous mean and the current mean, which (naively) requires 2 divides: either oldSum / oldCount and newSum / newCount; or oldSum / oldCount and oldMean + delta/n.

(Note that I'd be very happy to be wrong about this.)

[cpacey]

@danielnelson, could we keep tracking mean and merge as-is?