+- HP Forums (https://www.hpmuseum.org/forum)
+-- Forum: HP Calculators (and very old HP Computers) (/forum-3.html)
+--- Forum: General Forum (/forum-4.html)
+--- Thread: HP49-HP50 : comparison of two "identical Matrixes" (/thread-19268.html)
HP49-HP50 : comparison of two "identical Matrixes" - Gil - 12-08-2022 10:40 AM
Suppose I put on the stack
[[ 2 3 ]
[ 5 1 ]]
Then
DUP
Then key 1/x for inverse gives
[[ '-1/13' '3/13' ]
[ '5/13' '-2/13' ]]
Let multiply the initial Matrix by its inverse here, and we get :
:
[[ 1 0 ]
[ 0 1 ]]
Write now
2 IDN
Then compare it by ==
And the answer is 0.
How can I get the correct answer working with integers?
Thanks for your help.
Gil
RE: HP49-HP50 : comparison of two "identical Matrixes" - Gjermund Skailand - 12-08-2022 11:08 AM
I don't have a HP50 here, so I can't test this, but you could try some alternatives. And some of the below may be sys-rpl words, I don't remember.
SAME
EQ
EQUAL
if none of the above works you may have do subtract, calculate root mean square and compare to 0, i.e:
-
ABS
NOT
BR Gjermund
RE: HP49-HP50 : comparison of two "identical Matrixes" - Gil - 12-08-2022 12:51 PM
Of course, knowing the problem, an easy solution would be to compare real Matrixes :
[[ 2 3 ]
[ 5 1 ]]
Then key 1/x for inverse gives
[[ '-1/13' '3/13' ]
[ '5/13' '-2/13' ]]
Then, after multiplying the initial Matrix by its inverse here, and getting :
:
[[ 1 0 ]
[ 0 1 ]]
We add the 1st instruction
—>NUM
Then, as before, we write 2 IDN
And again we write the instruction
—>NUM
Then compare it by == (or SAME)
And the answer is 1.
But, why, when comparing the two integer identy Matrix do we get different objects?
I. e #7545 d for
[[ 2 3 ]
[ 5 1 ]]
×
[[ '-1/13' '3/13' ]
[ '5/13' '-2/13' ]]
& #47765 d for
2 IDN
In fact, though the display of
[[ 2 3 ]
[ 5 1 ]]
×
[[ '-1/13' '3/13' ]
[ '5/13' '-2/13' ]] is an apparent nice
[[ 1 0 ]
[ 0 1 ]] Matrix.
clearly there should exist, internally, rounding, non significant hidden digits.
RE: HP49-HP50 : comparison of two "identical Matrixes" - DavidM - 12-08-2022 03:11 PM
(12-08-2022 12:51 PM)Gil Wrote: But, why, when comparing the two integer identy Matrix do we get different objects?...
I'm surprised this issue doesn't come up more often.
Short answer: It's a bug. It affects a variety of operations that deal with exact integers on 49G-50g calculators.
Essentially, this is happening because there are two different ways for exact integers in the range -10..10 to be represented internally. While they represent the same values (there's no hidden digits), comparison operators don't always see them as being equal. If all of the values being compared are outside the range -10..10, this isn't an issue. It only affects that specific range of values.
Most math operations work as you would expect with both forms, but the results of the operations can be in either form and therefore checking for equality is hit-and-miss.
Here's another way to see the same issue. Try the following with the calculator in EXACT mode:
{ 1 2 3 }
{ 2 4 6 } 2 /
== ( or SAME, they both fail this test on a 50g)
Some operations work differently in specific ROM versions, so some of this actually works better on certain older versions. It just depends on the specific operations you are performing.
To make matters worse, some operations give one type of result for 0 and the other for 1..10 (or -1..-10).
If you are dealing with a square matrix, you could conceivably use a strategically-placed INV INV to "normalize" the values so that a comparison with the identity would succeed. You can probably see how that would get messy, though, depending on the contents of the matrices in question and what operations you are performing.
To deal with this when comparing lists, I resorted to creating special commands in the ListExt library that "normalize" -10..10 values anywhere in a list. You could convert the matrices to lists with AXL and then use LSAME to see if they match. It's a pain, but it works.
RE: HP49-HP50 : comparison of two "identical Matrixes" - Gil - 12-08-2022 03:16 PM
Great answer.
Just incredible persons to "meet" in that HP site.
Thanks for sharing your knowledge.
Regards, Gil
RE: HP49-HP50 : comparison of two "identical Matrixes" - gor1060 - 12-09-2022 07:21 AM
I used the EXPAND to avoid this issues with comparision of integers, matrices and lists
RE: HP49-HP50 : comparison of two "identical Matrixes" - DavidM - 12-09-2022 03:43 PM
(12-09-2022 07:21 AM)gor1060 Wrote: I used the EXPAND to avoid this issues with comparision of integers, matrices and lists
That's nice to know, thanks for sharing!
It works for this situation using built-in tools, and doesn't require converting things to a list first. It's not a speed demon, but for occasional use should work well.
RE: HP49-HP50 : comparison of two "identical Matrixes" - ttw - 12-09-2022 06:15 PM
The EXPAND command has worked for me in general. Fortunately, for the last several years, I have mostly been working with unimodular matrices (determinant 1 or -1).
There is another problem with integers; I think (based on experiments) that the HP50g can convert 40 bits real to integer or to binary. I can't always rely on some conversions as integers less than 2^64 don't always convert nicely to binary (some conversions seem to go through reals or something equivalent.) I cannot sort large integers (bigger than 40 bits) but I just wrote a Heapsort as comparisons work.
I finally settled on using integers for everything with a final conversion at the end. There are still problems, one cannot compare fractions using the comparison operators. No language seems to support the "mediant" operator (this is not too surprising). I did find that storing fractions a fractions 'a/b' is good for saving and moving things but sometimes a list (a b) can be better. The list form supports mediants (a b) M (c d)=> (a+c b+d)
RE: HP49-HP50 : comparison of two "identical Matrixes" - John Keith - 12-09-2022 08:28 PM
(12-09-2022 06:15 PM)ttw Wrote: There is another problem with integers; I think (based on experiments) that the HP50g can convert 40 bits real to integer or to binary. I can't always rely on some conversions as integers less than 2^64 don't always convert nicely to binary (some conversions seem to go through reals or something equivalent.) I cannot sort large integers (bigger than 40 bits) but I just wrote a Heapsort as comparisons work.
Joe Horn's I->B and B->I, available here can do the conversions accurately. LSORT can sort lists of large integers but doesn't work with lists having a mix of exact and approximate numbers. LSORT is also orders of magnitude faster than the built-in SORT.