Live data from Hacker News

Calculating the mean of a list of numbers (2016)

hypothesis.works

91–96 of 96 posts

Re: Calculating the mean of a list of numbers (2016)

#91
Aren't means recursive? It's just sum/count. So you just split the list into arbitrary sublists, such that the sum of each sublist is well under the infinity cutoff. Calculate the mean of each sublist, and then the mean of those means.

And you could add the split logic to calculating the mean of the means. Just as insurance.

So would that work?

Re: Calculating the mean of a list of numbers (2016)

#92
post #90

Earlier quoted context omitted.

A solution more accurate than sorting before adding is to place your numbers into a priority queue and repeatedly add the smallest two numbers and re-insert the result into the queue. This helps handle the case where you have many similarly valued numbers and your running sum becomes large enough relative to your numbers to cause the same rounding errors.

Isn't a priority queue implicitly sorted?

Yes. I don't think your parent post meant to imply otherwise.

The priority queue approach boils down to "sort after every addition, instead of just once at the beginning".

Re: Calculating the mean of a list of numbers (2016)

#93
post #6

If you're reaching these values then it's extremely likely that either: (a) You're doing something wrong (usually, not standardizing your data, etc.) which means that you're not thinking about the fact that computers have finite numerical precision and adjusting your problem accordingly (e.g., have a wide dynamic range of numbers). Or, (b) your problem is pretty ill-conditioned and there's probably no solving it in a…

I think that was the author's point to some extent: it's probably ok to ignore this problem, but you should know it exists.

Re: Calculating the mean of a list of numbers (2016)

#94
post #92
post #90

Earlier quoted context omitted.

Isn't a priority queue implicitly sorted?

Yes. I don't think your parent post meant to imply otherwise. The priority queue approach boils down to "sort after every addition, instead of just once at the beginning".

Ah right, I read 'more accurate than sorting before adding' as 'without sorting before adding' and missed that it was more about rounding errors than the sorting.

Re: Calculating the mean of a list of numbers (2016)

#95
post #76

Here is a fascinating post by Stefan Karpinski, one of the creators of Julia: https://discourse.julialang.org/t/array-ordering-and-naive-s... He shows off a function named "sumsto" which takes a single positive double precision floating point number "x" as an argument. "sumsto" always returns the same vector of 2046 floating point numbers -- just in an order so that naive left-to-right summation returns "x". Just cha…

`realmax` got renamed to `floatmax` in 1.0; similarly, `realmin` got renamed to `floatmin` (they're both very much specific to floating point types).

Re: Calculating the mean of a list of numbers (2016)

#96
post #76

Here is a fascinating post by Stefan Karpinski, one of the creators of Julia: https://discourse.julialang.org/t/array-ordering-and-naive-s... He shows off a function named "sumsto" which takes a single positive double precision floating point number "x" as an argument. "sumsto" always returns the same vector of 2046 floating point numbers -- just in an order so that naive left-to-right summation returns "x". Just cha…

You think that's bad? Theoretical math has "conditionally convergent series'" [1] Sum in order and it can convergence to a given value. Rearrange the terms and any real number is possible. I have a hunch there could be a bit of relation between these things. [1] https://en.wikipedia.org/wiki/Conditional_convergence

It's an interesting connection. Any finite collection of real values (represented in floating-point or otherwise) has a definite correct sum. If you're constrained to the floating-point to represent that value, you should ideally round the true value to the closest float and return that. Computing this true sum of a sequence of floating-point values is surprisingly hard though. The state of the art seems to be Radford Neal's paper on superaccumulators from 2015:

https://arxiv.org/abs/1505.05571

Fortunately pairwise summation (Julia's default) is fast and fairly hard to trip up, although it certainly is possible to trick it.

Post reply on HN