Posts: 3,229
Threads: 42
Joined: Jul 2006
The secret behind the slowness of the built in summation function is that is isn't naïvely summing the returned terms as I suspect your program is. It uses the Kahan Sum algorithm instead which provides better numerical results by utilising both a register for the sum and a register for the lower order digits correction term. the cost is of course, more operations and hence it will be slower. It doesn't provide double the number of digits of accuracy but it does provide somewhat more than just summing the terms and it comes into its own when lots of small numbers are summed to produce a larger result.
The source code is an interesting read, but don't try to analyse it using algebra -- the correction term is universally zero in that case. In a floating point world, it isn't however and this is the important point and why the result will be more accurate.
Essentially, it boiled down to a choice of fast or accurate. I chose the latter. This is universally the trade off made on the 34S. The results must be correct even if they take longer.
- Pauli
Posts: 3,229
Threads: 42
Joined: Jul 2006
Your function probably isn't the best example but check the lowest order digits.
Ideally, you want to sum this series in reverse so the small terms accumulate before the larger ones.
- Pauli
Posts: 735
Threads: 34
Joined: May 2007
Quote:
calculating from 1-600 the sum of 4/(n*(n+2))
As this is a telescoping series the result is simply:
Thus no real need to use a summation function.
Kind regards
Thomas
