Apparently the 33s maintains for each numeric value a 12-digit mantissa with its sign, and a "2.5-digit" exponent with *its* sign. (Exponents may be in the range of +/-500.)

One could probably encode within a "native" 33s number two "encoded numbers", each 5-digit mandissas with two-digit exponents. For one of the numbers, encode the 5-digit mantissa as (say) the high-order 5 digits of the native number, use the lower two digits of the exponent for the first encoded number's exponent, and utilize the native number and exponent signs.

For the second encoded value's mantissa, use the next 5 digits of the native mantissa. Utilize the final two digits of the native mantissa for the second encoded number's exponent, and encode the second number's signs (overall and exponent) in the high-order digit of the native exponent. (Multiply by a factor of 10^100 if the second encoded value is negative, and a factor of 10^200 if its exponent is negative -- all the while maintaining the sign of the *first* encoded number's exponent.)

So, a few examples:

1st enc. # 2nd enc. # HP-33s #

1.2345 E 67 9.8765 E 21 1.23459876521 E 67

-1.2345 E 67 9.8765 E 21 -1.23459876521 E 67

1.2345 E 67 -9.8765 E 21 1.23459876521 E167

1.2345 E-67 9.8765 E 21 1.23459876521 E-67

1.3245 E 67 9.8765 E-21 1.23459876521 E267

1.3245 E-67 9.8765 E-21 1.23459876521 E-267

-1.3245 E-67 -9.8765 E-21 -1.23459876521 E-367
-9.9999 E-99 -9.9999 E-99 -9.99999999999 E-399

A couple of relatively complex encoding & decoding routines would have to be incorporated in an indirect STO/RCL facility, and those would also have to check for overflow and underflow (absolute values > 9.9999 E99 and < 0.0001 E-99, respectively) and handle those.

The 33s will no doubt make things more difficult than that, so the scheme probably won't work exactly as proposed. It'll try to normalize numbers in scientific notation, shifting the mantissa to the left or right & changing the exponent willy-nilly, depending upon what is stored where. (It occurs to me only now that the leading digit may have to be forced to a non-zero value to keep things fixed -- maybe the exponent of the second number could be stored there in some form of "excess 99" notation, or its signs might be encoded in that first digit, to keep the alignment static . . . )

It does seem, however, that 5 digits of precision with ranges of -9.9999 E99 to +9.9999 E99 is about the best one might do if two numbers are to be stored in each variable. Some playing with the range and/or precision will allow trade-offs with those, and also three or four values might be encoded in each variable, at the cost of greatly reduced precision and/or range.

(I'm at best half-acquainted with the theoretical side of this, so some mathematician may wish to correct my terminology!)

All in all, a fun-sounding project!

*Edited: 3 Mar 2004, 11:19 a.m. *