HP49-50G : Matrix & Strings

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