Matrices on the 33s « Next Oldest | Next Newest »

 ▼ Ben Salinas Member Posts: 166 Threads: 28 Joined: Aug 2007 03-03-2004, 12:20 AM 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 -Ben ▼ Brent Junior Member Posts: 48 Threads: 7 Joined: Jan 1970 03-03-2004, 08:19 AM 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. Paul Brogger Posting Freak Posts: 1,153 Threads: 94 Joined: Mar 2006 03-03-2004, 10:35 AM 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.

 Possibly Related Threads... Thread Author Replies Views Last Post HP Prime Matrices curiosity bluesun08 0 818 12-09-2013, 06:44 PM Last Post: bluesun08 [HP-Prime CAS] "Warning, ^ (Command) Is ambiguous on non square matrices"?? CompSystems 1 1,148 12-07-2013, 07:15 PM Last Post: CompSystems HP Prime: matrices in programs, in need of help Alberto Candel 9 1,780 11-26-2013, 01:33 AM Last Post: cyrille de Brébisson HP 50g - question about matrices arrays vectors etc. Sean Freeman 6 1,470 11-14-2013, 01:44 PM Last Post: peacecalc HP Prime SIZE and OBJ-> with matrices/vectors/lists Helge Gabert 8 1,574 09-27-2013, 05:44 PM Last Post: Helge Gabert Programming with Matrices Han 10 1,697 09-25-2013, 03:59 PM Last Post: Han [HP-prime] Parallel Processing, vectors, matrices as a only data type =( CompSystems 1 686 08-08-2013, 04:48 PM Last Post: peacecalc Matrices on HP39gii (Cautionary Tale) Eddie W. Shore 2 800 03-23-2013, 07:54 PM Last Post: Gilles Carpentier WP 34S: a litlle matrix helper to enter and review matrices Miguel Toro 11 1,892 10-09-2011, 12:20 PM Last Post: Miguel Toro Near, or exactly, rank-deficient matrices. Rodger Rosenbaum 17 2,683 02-04-2008, 02:52 AM Last Post: Karl Schneider

Forum Jump: