On computer sums

[nickbarnes]

Since certain sceptics don't like my attempts to correct some of the misapprehensions in their blog postings and comment threads, and refuse to allow my comments, I have tried to clarify some issues relating to computer arithmetic in a post on the project blog instead. I'd appreciate any numerate friends having a quick look, and commenting here.

Comments

[enlivend]

Yeah, that's fine.

You've mentioned - if not named - accuracy and stability, two of the bug-bears of numerical analysts (the third being rate of convergence). I really like the links into different code revisions.

This sentence needs cleaning up: "Recently, in removing the explicit rounding, and treating temperatures as floating-point values rather than integral numbers of tenths of degrees, this code is now..."

There was a pair of seminal papers on reading and writing floats, JonL White co-authored one of them, which you might reference.

[nickbarnes]

Steele & White, and Clinger, in POPL'90. My article was much too long already, and references to those might seem odd next to quoting floating-point numbers to 48 decimals.....

[gareth_rees]

I wrote the following:

Dirk: Python's rules for arithmetic operator precedence are here. You can see that multiplication and division have the same precedence, and that expressions are evaluated from left to right. So when evaluating a*b/c Python will carry out the multiplication first and then the division.

In the case of the Fahrenheit to tenths-of-degrees-Celsius conversion, we can do a bit of numerical analysis to see how much difference order of evaluation can make.

With the multiplication first, i.e. ((f−32)*50)/9.0, the subtraction and multiplication can be done exactly, and the division results in an error of up to ½ulp (ulp = unit in the last binary place). This is assuming that there's no underflow or overflow, but since the range of inputs (i.e. temperature in Fahrenheit) is small, it's easy to check that can't happen.

With the division first, i.e. (f−32)*(50/9.0), the subtraction is exact, the division results in an error of up to ½ulp, and the multiplication in another ½ulp, so up to 1ulp in total.

You can explore this

[nickbarnes]

I wrote something similar (slightly less detailed), but my comments there are generally "held for moderation" indefinitely. So are Joshua's, as he is tarred by association with me. I'm not holding my breath waiting for yours to appear.

[gareth_rees]

Your comment and mine have both been approved. Numerical analysis is probably not as controversial as climate change.

[ext_44906]

And in reply to E.M.Smith's (annoyingly inline) reply to Nick's comment I responded with a comment that is yet to be approved

[artw]

I got to the end of it and didn't have to read any bits twice so it is fine for readability by non computer people.