Comparison (34C-59) R⇄P conversion

[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.