Glad you could check out a psion or two!

I just checked with a short C program on a PowerPC, which has native single- and double-precision IEEE arithmetic, and that gets zeroes for all four cases in both precisions. This is perfectly consistent with the results for half-precision that I worked out mostly by hand.

It is interesting how different the results actually are, where some produce a result of zero for some results, but not for others, while a different device does the opposite.

Oh, and one thing that many forget, is that any number system is an approximation of the real world where everything has an infinite resolution. Only humans like nice ‘round’ numbers...!

So, when using a 4¾ digit digital multimeter, how often does anyone take any notice of the two least significant digits? Same for the last digit on a 3½ digit multimeter...

When the utility company wants an electricity meter reading or a gas meter reading, they are not the least bit interested in the digits after the decimal point.

And no one says we will have a meeting at 10:35.45...

But when it comes to computers and calculators, because the device shows the displayed result, people will argue that it “must be right” because machines don’t suffer from human error. Oh much fun

Mark

With a real CPU and with half-precision floats, you could probably run through an exhaustive
x/y*y-x
test in reasonable time, and count up how many times you get each number of ULP of error. Anything more than 1 ULP would be interesting, but it would also be interesting to know how often you get 0 ULPs of error and how often 1.

With BBC Basic, with my very non-exhaustive testing, I think I was getting at most 2 ULPs of error.

Yes, because there are not only two different radixes in common use (decimal versus binary), but different rounding rules. Sometimes there are no guard digits or bits at all, sometimes just one digit, sometimes two, and for IEEE arithmetic only, the sticky bit. Sometimes ties are rounded away from zero, sometimes to even as IEEE does; some very basic implementations just truncate instead of rounding.

You can see the effect of the sticky bit in the 7/3 and 10/3 rounding in half-precision. The IEEE rules mean that those are rounded up; with only one or two guard bits the rounding would be a tie, and the round-to-even rule would round them both down.

I've been reading some of WIlliam Kahan's writings: he worked on the 8087 FPU, on the IEEE standard (at the same time, but aiming to be scrupulous about conflict of interest) and on several of HP's calculators. He mentions and to some extent explains these three extra digits in this 49 page PDF:

Mathematics Written in Sand

Also good, an interview with him (a 15 min read):

An Interview with the Old Man of Floating-Point

And, still on HP, when they improved their algorithms as used in the HP-35 they wrote some articles:

The New Accuracy: Making 2^3=8 by Dennis Harms, HP Journal, October 1976, pages 16-17

Within Kahan's various writings are some example simple calculations which can show up anomalies in arithmetic. For example:

pi * e - e * pi
729^33.5 / 3^201 -1

Over on the hpmuseum forum, some other suggested calculations.

I tried this one: Nine ones squared, or 111.111111 ^ 2 - 12345


I had a go multiplying some square roots (even my two most basic calculators do square root)
sqrt 2 * sqrt 3, squared, minus 6

Psion 3 is a bit wysiwyg - displayed numbers can be re-used as is but internally there's more going on. It's clearly binary rather than decimal.

I get just over -2E-11 if I re-enter each number as printed - just under 36 bits.
If I put everything in a single line I get 8.88E-16 which is 2^-50, about 15 digits

edit: fix typo

Just with that one, it's easy to see something revealing about HiPER Calc Pro. If I enter it as a single formula, I get zero, which is correct. If I press = before -, I get a 45-digit answer with exponent 10^-45.

The explanation is that HiPER Calc Pro is doing its internal clculations to twice the precision of display - but pressing equals rounds the value in processing to display precision.

That's interesting, and quite remarkable: it's working at twice the precision it displays? That's much much more work than the extra 16 bits in the 8087's 80 bit format, or the 3 extra digits in a 12-digit HP calculator.

Just a couple more points...

We're told, I think, that the original 6502 BBC Basic used approaches found in Cody and Waite. But I see in Kahan's Sand article linked above that the 8087 did better:


(Indeed, I note that Kahan says that in binary, taking a square root and then squaring should always be lossless, but 6502 BBC Basic isn't, at least for 15 and 17.)

One of Kahan's notes is a lament that IEEE's three different rounding modes are not more readily accessible: running the same calculation in all three modes can give a hint as to whether a calculation is sound or not.

A couple of nice pull-quotes from the Sand piece:



Finally, maybe, Kahan has more of a slide-deck presentation here, from 2005, which also links back into some specific other writings of his:

Floating-Point Arithmetic Besieged by “Business Decisions” (28pp, 2005, IEEE keynote)

Pointers within include:

How Futile are Mindless Assessments of Roundoff in Floating-Point Computation? pp56, 2006

"Some parentheses in Microsoft's Excel 2000 spreadsheet possess uncanny powers" which is about binary arithmetic masquerading as decimal.

and
Marketing versus Mathematics and other Ruminations on the Design of Floating-Point Arithmetic pp48, 2000

Well, HiPER Calc Pro gets to take advantage of the modern gigahertz-class RISC CPU in my smartphone. It can *afford* to do more work than the sub-megahertz logic in many pocket calculators.

A fair point!

I found it satisfying to find some sums which the more modern Sharp and Casio calculators did worse at than the older HPs, given the different tactics: it looks like HP tries to round but doesn't have extra digits, whereas the Sharp and Casio just have a couple of extra digits but truncate into them.

Seen on the HP Museum forums:

The most accurate scientific calculator??

where we find a link to an article on all-digits-correctness:

Small-Data Computing: Correct Calculator Arithmetic

which includes this snippet[1] describing an old version of Android's calculator app:

and goes on to describe a later version which uses 'constructive real arithmetic' which gives the possibility of scrolling a calculated result to see as many digits as desired. There is then a bit of a difficulty in that a rounded result isn't consistent with scrolling (a simple example being 2/3), so


The forum thread goes on to mention the superior calculator, 'spigot' by the inestimable Simon Tatham, which always returns correct digits, and as many as you want. It is, however, a command line calculator, or indeed an expression evaluator. It comes with this amusing note:


[1] Another interesting note in the article on the Android app involves the possibility of a calculation timing out, if the result is undecidable.