Talk:Kahan summation: Difference between revisions

→‎Task: added a comment concerning another talk page about summation methods.
(Epsilon computation)
(→‎Task: added a comment concerning another talk page about summation methods.)
 
(2 intermediate revisions by 2 users not shown)
Line 146:
 
::::OK, indeed the options() call just restricts the number of digits being displayed, not the actual number used in calculations. In that respect it is in the same boat as PHP. AFAIK there is a package (not a base component) that can deal with arbitrary precision (http://cran.r-project.org/web/packages/Rmpfr/), but that is not what this particular task is aiming to show. I have redone the operations and results on a Windows 7 64-bit machine from a friend, will check again on my Ubuntu 64-bit box to corroborate the results. --[[User:Jmcastagnetto|jmcastagnetto]] ([[User talk:Jmcastagnetto|talk]]) 02:11, 17 December 2014 (UTC)
 
:For a clear example of the differences in summation methods, try adding the first billion terms of the harmonic series 1/i. It will also be significantly different adding forward or backward. In 32 bit floats, the results are:
<pre> forward: 15.4036827
backward: 18.8079185
forward compensated: 21.3004818
backward compensated: 21.3004818</pre>
--[[User:Andy a|Andy a]] ([[User talk:Andy a|talk]]) 04:56, 21 April 2020 (UTC)
 
::::: The above topic (summation methods) is also mentioned in the &nbsp; ''talk/discussion'' &nbsp; page at &nbsp; [http://rosettacode.org/wiki/Talk:Sum_of_a_series#summing_backwards (Talk) &nbsp; Sum of a series, summing backwards]. &nbsp; &nbsp; &nbsp; &nbsp; -- [[User:Gerard Schildberger|Gerard Schildberger]] ([[User talk:Gerard Schildberger|talk]]) 09:24, 21 April 2020 (UTC)
 
==So far, in J and R==
Line 409 ⟶ 418:
It is interesting to see that several compilers do not use the different IEEE-754 precisions to implement the different data types.
The trade-off between compiler simplicity a runtime efficiency is: why to bother with different floating point precisions and all the implied cross conversion routines, why not use only the higher precision.<br>
===Kahan summation===
Kahan summation algorithm task is a good idea but, the example numbers : 10000.0, 3.14159, 2.71828
are a bad choice, because no rounding errors when IEEE 754 floating point double precision (64 bits) are used by the language, and unfortunatly is now the standard. Let's note that William Kahan is a father of the original IEEE 754 and its revisions.<br>
<br>
--[[User:PatGarrett|PatGarrett]] ([[User talk:PatGarrett|talk]]) 16:43, 16 February 2019 (UTC)