Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #107036 > unrolled thread
| Started by | Robin Becker <robin@reportlab.com> |
|---|---|
| First post | 2016-04-15 10:24 +0100 |
| Last post | 2016-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.
Re: sum accuracy Robin Becker <robin@reportlab.com> - 2016-04-15 10:24 +0100
| From | Robin Becker <robin@reportlab.com> |
|---|---|
| Date | 2016-04-15 10:24 +0100 |
| Subject | Re: 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
Back to top | Article view | comp.lang.python
csiph-web