Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.python > #107036 > unrolled thread

Re: sum accuracy

Started byRobin Becker <robin@reportlab.com>
First post2016-04-15 10:24 +0100
Last post2016-04-15 10:24 +0100
Articles 1 — 1 participant

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: sum accuracy Robin Becker <robin@reportlab.com> - 2016-04-15 10:24 +0100

#107036 — Re: sum accuracy

FromRobin Becker <robin@reportlab.com>
Date2016-04-15 10:24 +0100
SubjectRe: sum accuracy
Message-ID<mailman.10.1460712319.6324.python-list@python.org>
On 13/04/2016 18:05, Random832 wrote:
.........
>
> No, it doesn't. Sum works on any type that can be added (except
> strings), it can't make any assumptions about the characteristics of
> floating point types. For non-numeric types, the addition operator may
> not be semantically commutative or associative.
>
I thought as much. My problem was that the sum of an array of small floats was 
being used to compute a grid of points by subtraction like this

height = sum(H)
pos = [height]
for h in H:
	height -= h
	pos.append(height)

the value of height[0] came out negative which was a problem. I could reduce the 
error by using Kahan summation instead of sum, but that required Kahan style 
subtraction as well. In the end it just seemed better to reverse the loop and 
compute pos by addition.


> Look at
> http://code.activestate.com/recipes/393090-binary-floating-point-summation-accurate-to-full-p/
> for an example of a more accurate algorithm, but note that, for example,
> this algorithm wouldn't work on complex numbers (you'd have to sum the
> real and imaginary components separately)
>
yes indeed summation is hard :(

-- 
Robin Becker

[toc] | [standalone]


Back to top | Article view | comp.lang.python


csiph-web