A few weeks ago, Ted Ashton wrote me a note and said that there was a problem
with Equater!'s HP real number representation of numbers that are even powers
of 2 (2, 4, 8, 16, 64, etc.).

Because of Jeff Vance's math question on Monday, I noticed another, directly
similar problem with the trigonometric functions in Equater!. Both problems
stem from an intermix of single and double real numbers in Equater!'s code.

A double real number on the HP3000 has 16.5 decimal places of accuracy (16
guaranteed, the 17th being logarithmically slightly indeterminate). In
Equater!, we guarantee only 14 places of accuracy to allow for accumulated
error after repeated calculations. We use the 15th significant figure for
rounding of the 14th place.

At least that's the intent.

In Ted's reported bug and the trig functions that I discovered on Monday,
short reals unintentionally appear in the code, thus when these functions are
invoked, only 6 places can be guaranteed, not 16. I distinctly remember
fixing these problems ten years ago, but somehow we seem to have lost that
code, probably during our transition from the Classic machines to RISC boxes,
although that certainly doesn't say much good about our software version
control system.

Nevertheless, these problems will be fixed again soon. It has been my
intention ever since Ted's original bug report to kill two birds with one
stone and convert Equater! into the first fully QCTerm Van Gogh-ified program
at the same time I scrub the code of single-reals. Once Equater! is modified,
it will still appear as it always has before on a regular HP terminal (or
emulator), but it will become bright and colorful on a QCTerm emulator.

For the moment, don't trust any significant figures in Equater! past 6
decimal places (although most of them will truly be good to 16). I'll try and
get a new copy up (and Van Gogh-ified) before the end of the year. What we're
really waiting on is development in QCTerm.

Wirt Atmar