Differences in Home vs CAS

[ftneek]

Hello, I'm fairly new to the HP Prime and PPL. I started out by trying to recreate a program I wrote in python as a CAS program, but was running into some problems. After a few days of debugging and writing it as a non-CAS program, it works as I'm expecting in the home view, but when I run it in the CAS view it generates warnings that "A/B with B a square matrix is misleading notation interpreted as inv(B)*A", and error "Ifte: Unable to check test Error: Bad Argument Value". Can someone help me understand why that is? Are matrix calculations treated differently in Home vs CAS mode? Ideally I would like my program to works in both modes, with decimals returned in home view and fractions in CAS. I have also tried using the syntax for a cas program but then it errors in either mode. I would appreciate any insights or suggestions.

For reference it is the iterative conjugate gradient method to solve Ax=b, where in this case A is the nxn Hilbert matrix and b is an nx1 matrix which is the rowsum of A, so the exact solution for x is an nx1 matrix composed of 1's, but the computed solution should be "close" to 1's.

Code:

EXPORT conjugate_gradient(A, b)
BEGIN

LOCAL x, t, r, I, n;

n := DIM(A);
x := MAKEMAT(0, n(1), 1);
x(1, 1) := 1;
I := 1;
r := A*x - b;

WHILE I < 75 DO
t := (TRN(r)*r) / (TRN(r)*A*r);
x := x - r*t;
r := A*x - b;
IF ROWNORM(r) < .001 THEN
BREAK;
END;
I := I + 1;
END;

RETURN {I, x};
END;

Here is also a method for generating the rowsum, since I couldn't find an easy way to that with any of the built in methods. It works in both CAS and home view.

Code:

#cas
rowsum(A):=
BEGIN

LOCAL n;
LOCAL b;
LOCAL I;

n := dim(A);
b := makemat(0, n(1), 1);

FOR I FROM 1 TO n(1) DO
b(I,1) += ΣLIST(row(A, I));
END;

RETURN b;

END;
#end

update: So after some more digging, I think it those warnings came from a leftover file from when I was writing it as a CAS program. I reset my virtual calculator and retransferred the files. It works in Home mode but when I call

Code:

conjugate_gradient(hilbert(20), rowsum(hilbert(20)))

in CAS mode I no longer get the previous warnings, instead I get this error: "Error: Bad argument type". Why is that? I would like the conjugate_gradient method to work in CAS mode if possible. My question still stands if there are differences between how matrix calculations are performed in CAS mode. Thank you

[parisse]

The line t := (TRN(r)*r) / (TRN(r)*A*r); should be rewritten as t := (TRN(r)*r) * (TRN(r)*A*r)^(-1)
Try debug(conjugate_gradient(...)), this will spot the line where the error occurs.

[Didier Lachieze]

Another way to implement rowsum:

Code:

#cas
rowsum(A):=
begin
  Σ(transpose(col(A,n)),n,1,colDim(A));
end;
#end

[ftneek]

So it turns out the simulator on Mac (software from 2020 01 16) produces the bad argument argument type error, while my physical calculator on (2021 12 02) is able to run the command in CAS mode. However, if I try to write it to be a CAS program then it throws the "Ifte" error. When I use the debug() command on the CAS version of the program, it throws the error when rowsum() returns. Any ideas why?

(10-20-2022 05:56 AM)parisse Wrote:  The line t := (TRN(r)*r) / (TRN(r)*A*r); should be rewritten as t := (TRN(r)*r) * (TRN(r)*A*r)^(-1)
Try debug(conjugate_gradient(...)), this will spot the line where the error occurs.

Thank you, I made this change and it removed the A/B warning when I try to write it as a CAS program, though I am still getting the Ifte error.

(10-20-2022 09:25 PM)Didier Lachieze Wrote:  Another way to implement rowsum:

Thank you.

[parisse]

(10-21-2022 12:42 AM)ftneek Wrote:  

(10-20-2022 05:56 AM)parisse Wrote:  The line t := (TRN(r)*r) / (TRN(r)*A*r); should be rewritten as t := (TRN(r)*r) * (TRN(r)*A*r)^(-1)
Try debug(conjugate_gradient(...)), this will spot the line where the error occurs.

Thank you, I made this change and it removed the A/B warning when I try to write it as a CAS program, though I am still getting the Ifte error.

That's precisely why I suggest you to run your program in step by step mode. From CAS commandline, run debug(conjugate_gradient(arguments)) instead of conjugate_gradient(arguments). This way you will know which line of the program raises the error.

[ftneek]

(10-21-2022 10:02 AM)parisse Wrote:  That's precisely why I suggest you to run your program in step by step mode. From CAS commandline, run debug(conjugate_gradient(arguments)) instead of conjugate_gradient(arguments). This way you will know which line of the program raises the error.

(10-21-2022 12:42 AM)ftneek Wrote:  When I use the debug() command on the CAS version of the program, it throws the error when rowsum() returns. Any ideas why?

When I use debug(conjugate_gradient(arguments)) in CAS mode I only see code from the rowsum function. I tried stepping through it a few times and the error is thrown when rowsum finishes executing. When I use my own implementation for row sum, the error is thrown after line 6 of the debugger, when I use the implementation by @Didier it is thrown after line 1. I’m just having a hard time understanding why I only see the code for rowsum in the debugger and why I’m getting an error after rowsum executes.

[parisse]

Yes, the debugger is confused. There is an easy workaround: decompose in 2 steps: 1/ call rowsum first and store the result in a variable, 2/ call debug(conjugate-gradient(...)) with this variable.

[ftneek]

(10-21-2022 03:52 PM)parisse Wrote:  Yes, the debugger is confused. There is an easy workaround: decompose in 2 steps: 1/ call rowsum first and store the result in a variable, 2/ call debug(conjugate-gradient(...)) with this variable.

This seems to have fixed the issue, thanks.

Just some things I've noted:
The non cas version of the program is able to work in both modes on my physical calculator, even when the parameters haven't been stored as variables. It only works in Home mode on my virtual calculator regardless if the arguments are variables or not. The cas version of the program works in both modes on both physical and virtual calculator, but only if the the arguments have been stored as variables/don't need to be evaluated. The two versions produce slightly different numbers but still what I was expecting. The cas version still only produces a decimal, which is what I thought might happen, but if I want I can get a fraction by pressing the b/c key. Anyhow thanks for helping me figure out why it wasn't working.