HP49-HP50 : comparison of two "identical Matrixes"

[Gil]

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

[Gjermund Skailand]

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

[Gil]

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.

[DavidM]

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

[Gil]

Great answer.
Just incredible persons to "meet" in that HP site.
Thanks for sharing your knowledge.
Regards, Gil

[gor1060]

I used the EXPAND to avoid this issues with comparision of integers, matrices and lists

[DavidM]

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

[ttw]

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)

[John Keith]

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