Talk:Kahan summation

Task

The idea of showing the Kahan summation on Rosettacode is good, but the Task is not good yet. I suggest to remove the requirements of using a Decimal module and make it optional. So many languages can use normal floating point values. I also suggest to increase the number of input values and the number of their digits, to better show why the Kahan summation is useful.

This is a D version of the Task, without a Decimal:

<lang d>real kahanSum(T)(in T[] data) pure nothrow @safe @nogc {

   real tot = 0, c = 0;
   foreach (immutable x; data) {
       immutable y = x - c;
       immutable t = tot + y;
       c = (t - tot) - y;
       tot = t;
   }
   return tot;

}

void main() {

   import std.stdio, std.algorithm;

   enum a = 10000.0L, b = 3.14159L, c = 2.71828L;
   writefln("%5.10f", (a + b) + c);
   writefln("%5.10f", [a, b, c].kahanSum);
   writefln("%5.10f", [a, b, c].sum);

}</lang>

It prints (the D+Phobos sum performs a Kahan summation):

10005.8598700000
10005.8598700000
10005.8598700000

-bearophile (talk) 10:28, 11 December 2014 (UTC)

Would you need different numbers for different precision numbers? What numbers to choose as I would prefer some standardisation.

Or should it be written so that the example is forced to show the effect with the constants they use? --Paddy3118 (talk) 10:49, 11 December 2014 (UTC)

I also agree Kahan summation is a good task but have some issues. It seems Kahan summation is meaningful for fixed-precision floating-point numbers. That is, floating point numbers where the number of significant digits (or bits) is limited. This needs to be clear in the task description. If a language has no convenient fixed-precision floating-point representation, people should feel free to omit it.

I think the fixed-precision floating-point type most languages will support is IEEE 754 64-bit float. I suggest we provide task data crafted for this type. The Python example data works for floating point math that can be limited to 6 significant decimal places. It would be fine to retain this as alternative data for languages that can conveniently limit the significant decimal digits as Python can. If other languages come along that can do neither IEEE 754 64-bit floats nor 6-significant decimal digit floats but have some other limited precision floating point representation, we should allow them appropriate test data. —Sonia (talk) 20:29, 11 December 2014 (UTC)

Example added. Bearophile's suggestion of adding more numbers turned out to be good. —Sonia (talk) 20:49, 11 December 2014 (UTC)

I also suggest we explicitly disallow solutions showing the same answer from both a naive method and Kahan and concluding, "my language already does it." A valid solution should show that Kahan provides some advantage over some other method. —Sonia (talk) 20:57, 11 December 2014 (UTC)

All good suggestions.Please join in in improving this. --Paddy3118 (talk) 23:41, 11 December 2014 (UTC)

OK made my task revisions for the night, taking your comments into consideration... --Paddy3118 (talk) 05:40, 12 December 2014 (UTC)