Comparison (34C-59) R⇄P conversion

[SlideRule]

An excerpt from Lecture Notes in Computer Science, 142, Problems and Methodologies
in Mathematical Software Production, International Seminar Held at Sorrento, Italy, November 3-8,1980

     We motivate our concerns for the environment and for the design and implementation of algorithms by experimenting with some simple programs. Consider the evaluation of the magnitude of a complex number z = x + iy, where i = √(-1).
By definition,
                                         〡z〡 = √(x² + y²).

This definition corresponds to the theoretical method for determining 〡z〡, and suggests the obvious algorithm of squaring the components, summing them, and extracting the square root. Suppose we implement that algorithm on a programmable hand calculator, a TI 59, say, and run it with x = 3 and y = 4. Then we find that 〡z〡 = 5, which suggests that we have implemented the algorithm correctly. Now suppose we scale the original data by 10^-50 , and try again. This time the calculator stops with a blinking display of '1.-99'. Clearly there is an error of some sort in the calculation. Even though the data and correct result are all representable within the machine, the program is unable to return the correct result. At least the blinking display warns of trouble.
     When we try the same experiment on an HP 34C calculator, we obtain the result '4.00-50' for the scaled problem. The result is again in error, but it is different from the previous one. Even worse, there is no indication of trouble this time. We conclude that the obvious algorithm is not necessarily the best algorithm, and that implementations on different machines behave differently. This conclusion reinforces our decision to distinguish between the algorithm and its implementation.
     Each of these calculators contains a built-in program, accessible with a simple keystroke, for conversion between rectangular and polar coordinates. Such a program automatically determines 〡z〡as the radial coordinate. If we use the conversion program on a TI 59 with the scaled test data, we obtain the puzzling result '4.472136-50', again with no indication of error. This is more serious than before because we have used a 'system program' that is supposed to be correct, not one that we wrote. When systems programs contain errors, especially programs built into calculators, they are hard to correct. Happily, the conversion program built into the HP 34C returns the correct result '5.00-50'.

The results of this demonstration are not reassuring.

BEST!
SlideRule

[bxparks]

Forty-four years after this publication, I ran into related problems while implementing RPN83P on the TI-83+/84+ series calculators.

If you are in normal TI-OS mode, and try to perform some conversions using its R>Pr( function, you will see something like this:

Code:

R>Pr(3E63,4E63)
               5E63
R>Pr(3E64,4E64)
               Error

That's odd, because the TI-83+/TI-84+ should support numbers as large as 9.999999999E99. Let's see what happens with complex numbers:

Code:

(3E63+4E63i)>Polar
               5E63e^0.9271952...
(3E64+4E64i)>Polar
               3E64+4E64i

So the >Polar function detects an Error with (3E64+4E64i), then simply echoes the complex number in rectangular form with no indication of any errors.

How does this affect RPN83P? The 83+/84+ SDK provides a function named RToP which implements this Rect-Polar conversion, and it suffers from this exact overflow problem. The solution was to implement my own Rect-Polar conversion routines, so that RPN83P does the following:

Code:

3E64 2ND i 4E64
ENTER
MODE PRAD

X: 5E64 ∠ .927295218

And RPN83P does slightly better than expected when bumping against the limit of 9.999999999E99:

Code:

9E99 2ND i 9E99
ENTER
MODE PDEG

X: 1.2728E100 ∠° 45

The E100 is courtesy of a quirk in the TI-OS which supports numbers as large as 9.99999999E127 under certain conditions. RPN83P takes advantage of that for the purposes of displaying complex numbers in Polar form.