HP49-50G : Matrix & Strings

[Gil]

I create a Matrix (in fact, 2 Matrixes) by


« -105 CF { 2 2 } RANM DUP —>STR OBJ—> SAME
»

They are identical. Logical?

Not so sure.

Because when executing now
« -105 CF { 2 2 } RANM INV DUP —>STR OBJ—> SAME
»
though apparently the same Matrixes, they are in fact somewhat different (SAME gives now 0).

Curiously the subtraction does not give zero when the elements are negative.

Could somebody tell me what is happening by adding strings and removing them?

Of course, when subtracting their respective numerical values
— that are the same —, I get zero.

Thanks for your comments.

Regards,
Gil

[DavidM]

(09-27-2022 11:18 PM)Gil Wrote:  ...Because when executing now
« -105 CF { 2 2 } RANM INV DUP —>STR OBJ—> SAME
»
though apparently the same Matrixes, they are in fact somewhat different (SAME gives now 0).

Curiously the subtraction does not give zero when the elements are negative.

Could somebody tell me what is happening by adding strings and removing them?

This is an unintended consequence of how different parts of the calculator's firmware construct symbolic objects containing negative integers.

Consider that there are multiple ways for the simple rational -1/7 to be represented internally on the 50g. Here are two of them:

SYMBOL
ZINT -1
ZINT 7
x/
;

and

SYMBOL
Z1_
xNEG
Z7_
x/
;

These look the same on the stack, but the bit patterns are different between them, so SAME being executed on those two would result in 0.

In your specific example, converting the symbolic rational to a string, then performing OBJ-> to compile the string back into a symbolic, you start out with something like the former and end up with something like the latter.

This problem is not limited to SAME. Even replacing SAME with == won't get around this.

Note that I'm not trying to justify this, just to show what's happening.

[Gil]

Understood.

Thanks.

I was trying to create a square Matrix M on the EMU48
.
Then to "transfer" it, with a appropriate string on the stack, to the command line of the Maxima software.
Then, in Maxima, after pressing ENTER and getting the M Matrix, with its correct format,
I execute minv : invert (%).

And transfer this inverted Matrix into HP50G Stack.

From the appropriate conversion of the string on the stack,
(with a special program)
I multiply the resulting Matrix b, by the former, original Matrix.

I get, with some discrepancies, the identity Matrix.

With the trouble of the minus sign when elements are fractions.

Regards

[DavidM]

I'm wondering if a normalization step can be introduced into your workflow.

Since it appears that the problems are creeping in when OBJ→ is executed for a matrix in string form, you may want to try inserting these steps after the OBJ→ step:

Code:

::EVAL MAP

The null tag '::' allows EVAL to be placed on the stack without execution. MAP applies that EVAL to each element of the matrix recursively. In this context, EVAL simply invokes the CAS to EVALuate the given expressions, effectively rebuilding them into a predictable symbolic form.

Note that this assumes exact mode and system flag -3 being clear.

Example:

Start with this program

Code:

Gil01
\<<
  @ seed the PRNG for consistency
  54321 RDZ

  @ build a sample matrix with rationals
  { 2 2 } RANM INV

  @ make a copy, cycle through string form
  DUP \->STR OBJ\->
\>>

Run the above code, and you should see something like this:


While you can't see the top of the first matrix, both appear to be the same. You can see that by swapping the objects.

Check for "sameness" with the SAME command. The result should be 0, indicating that the objects are different.

Run the program again, but this time press "-" to perform a subtraction with the two objects. You should see something like this oddity:


Drop that from the stack and run the program again. This time, type in "::EVAL MAP" on the command line. Make sure that EVAL is after the second colon (as opposed to between the colons):


The second matrix (the one that's fully visible) does not appear to have changed, but it actually has:


Now execute SAME. Success!


Executing "-" instead of SAME will now give the expected result:


Try placing "::EVAL MAP" after the appropriate OBJ→ steps in your flow. It may help you out here.

[Gil]

Absolutely amazing!

I didn't think it might be possible to find a solution to that "riddle".

Your tip worked beyond my expectations.

In HP50G (EMU48)
1) I can have a matrix by {9 9} RANM that I duplicate with DUP command.
2) Then I use my HP program to convert that matrix to a string.
3) Then, always in my HP, I copy that stack

4) And paste it into the command line of the Maxima software.
5) ENTER in Maxima
6) Always in Maxima software, I write
invert (%) ENTER.
7) Then, still in Maxima software, I copy the resulted matri with its fractions.

8) And paste it into the stack of the HP50G.
9) With another HP50G program, I transform the above stack content (a string) in the HP50G into a matrix compatible with HP50G Matrix format.
10) And execute *, to get exactly the expected Identity Mstrix!

Many, many thanks, David.

Regards,
Gil Campart

[DavidM]

Glad it worked, Gil!

Thanks for pointing this out -- I don't recall having seen this issue before, though at this point I don't think anything is new with the RPL systems. It just means I haven't run across the issue where it was previously posted.