The Museum of HP Calculators

HP Forum Archive 14

[ Return to Index | Top of Index ]

Matrices on the 33s
Message #1 Posted by Ben Salinas on 3 Mar 2004, 12:20 a.m.

There has been many complaints about the 33s not having enough variables for any more than 5x5 matrix support. However, as long as you are not using to large of numbers, and restrict yourself to integers (that is the big one there), you can have up to 8x8 matrices. I experimented with this on the 32sii, but on the 32sii the extra lines of code were not worth the saved variables. On teh 33s, with virtually unlimited memory, it would be.

The trick is to store 2 integers as aaa.bbbb, then by taking the FP and IP of the variable, you have 2 number from one, allowing you to have 66 variables, or an 8x8 matrix.

I am currently trying to come up with a way to use decimals and negative numbers also. I'm thinking about incorporating place value to denote sign (such as in other bases, where FFFFFFFD6 is -42)

Just some food for thought


Re: Matrices on the 33s
Message #2 Posted by Brent on 3 Mar 2004, 8:19 a.m.,
in response to message #1 by Ben Salinas

Would another possibility be to calculate the upper triangular matrix and then stop and then r/s and calculate the lower triangular matrix? It's been a long time since I messed with matrices, so I don't know.

Re: Matrices on the 33s
Message #3 Posted by Paul Brogger on 3 Mar 2004, 10:35 a.m.,
in response to message #1 by Ben Salinas

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.

[ Return to Index | Top of Index ]

Go back to the main exhibit hall