HP Forums

Is there an easy way to (within a program) set M1 to the matrix:

[[ 1, 0 , 0], [0, COS(a), -SIN(a)], [0, SIN(a), COS(a)]]

At the top I have:

local a;
a:=30;

I tried using:

[[ 1, 0 , 0], [0, COS(a), -SIN(a)], [0, SIN(a), COS(a)]] -> M1;

which gives me a syntax error. Then I try:

M1:=[[ 1, 0 , 0], [0, COS(a), -SIN(a)], [0, SIN(a), COS(a)]];

and still get a syntax error. So finally I try:

M1:=expr("[[ 1, 0 , 0], [0, COS(a), -SIN(a)], [0, SIN(a), COS(a)]]");

still does not work -- no syntax error, but I get invalid input. What's going on? Is there no way to set M1 equal to a matrix? (Of course, convert "->" to the proper "store" symbol)

Edited: 24 Sept 2013, 1:27 p.m.

I think I may have figured it out. It appears that despite the local variable declaration, expr converts all variables to global variables. Perhaps the same parser for expr is also the handler for the programming environment?

Anyway, A temporary workaround is to store values into the A-Z variables.

So:

local a;

a:=30;

a->A;

[[ 1, 0 , 0], [0, COS(A), -SIN(A)], [0, SIN(A), COS(A)]] -> M1;

would work, whereas

local a;

a:=30;

[[ 1, 0 , 0], [0, COS(a), -SIN(a)], [0, SIN(a), COS(a)]] -> M1;

does NOT work.

Edited: 24 Sept 2013, 1:56 p.m.

There definitely is a limitation using locals in a matrix. I don't remember the exact reason. Perhaps cyrille can elaborate.

Also, be aware the home matrices only support real and complex at this time.

TW

Quote:

---

There definitely is a limitation using locals in a matrix. I don't remember the exact reason. Perhaps cyrille can elaborate.

Also, be aware the home matrices only support real and complex at this time.

TW

---

Thanks for the confirmation. What I thought would work in fact does not work. When using global variables, the parser uses the actual values of the global variables at the instant the user OPENS the program editor. For example, if A has the value 0 prior to opening the program editor, then even something like:

LOCAL a;

a:=3.141592;

a->A;

[[COS(A), 0, 1],[SIN(A),1,0]]->M1;

would produce an array that looks like:

[[1, 0, 1], [0, 1, 0]]

which is certainly not what is expected! Not only is there a limitation, I would argue this is a severe limitation in that only static matrices can be easily created. The only other idea I have is to do element-wise updates of each entry in a matrix :-(

Edit:

M1:=expr("[[COS(A),0,1],[SIN(A),1,0]]");

seems to work and update properly since it saves the parsing until runtime.

Edited: 24 Sept 2013, 3:41 p.m.

You can do this :

EXPORT Test()

BEGIN

 local a;

 a:=3.14159;

 A:=a;

 M1:=EVAL('[[COS(A),0,1],[SIN(A),1,0]]');

END;

This avoid M1 to be evaluated in the compilation time.

EDIT : I saw your edit now ;) In my opinion EVAL is better than EXPR but same result

By the way, it's not very different from the HP50G

Edited: 24 Sept 2013, 3:53 p.m.

Thanks for the tip on EVAL. It makes sense that it works similar to the HP50G. I think I got stuck on the language being similar to the TI BASIC that I started to expect similar behavior!

Edit: the EVAL trick does not work for matrices; see later post

Edited: 25 Sept 2013, 2:35 p.m.

Gilles,

I just got my PRIME and I am using your program lines to enter my first program. It only works if I omit the single quote marks in EVAL.

Thanks.

Chris

Edited: 25 Sept 2013, 1:43 p.m.

Quote:

---

You can do this :

EXPORT Test()

BEGIN

 local a;

 a:=3.14159;

 A:=a;

 M1:=EVAL('[[COS(A),0,1],[SIN(A),1,0]]');

END;

This avoid M1 to be evaluated in the compilation time.

EDIT : I saw your edit now ;) In my opinion EVAL is better than EXPR but same result

By the way, it's not very different from the HP50G

---

Actually, this does _NOT_ work (only tested with matrices) -- with or without the single quotes. In this example, the program is compiled to use whatever the global A value was at the time of compiling. Here's how to test this.

First, store 0 into A before editing the program. Then, edit the program and do nothing to the source code. Just open the editor and then close out the editor with the [ESC] key. Then run the program. You would expect something close to [[-1,0,1],[0,1,0]] but you actually get [[1,0,1],[0,1,0]] because the parser converted the global variable into 0 (the value prior to opening the program editor) upon exiting with [ESC].

But now that you have run the program once (or however many times, it doesn't matter because the value of A was pre-compiled to be 0), go back into the program editor -- open it once and immediately close it. Then re-run the program, and you get the expected [[-1,0,1],[0,1,0]].

The reason is that after your program was initially run, the global variable A was then set to approx. pi, so that upon exiting the editor the second time, the parser compiles the program to use the now-current A value of pi.

Open the editor again (third time) and edit the lower-case 'a' value and you will not see any changes in the output of the program until you "recompile" it by opening and closing the editor a fourth time (to use the updated global variable A).

So the point is you HAVE to use expr(" blah ");

Edited: 25 Sept 2013, 2:33 p.m.

You are right. It seems to be a bug or something not allowed...

This one works fine :

EXPORT Test(a)

BEGIN

 EVAL('2*a');

END;

But this don't work

EXPORT Test(a)

BEGIN

 EVAL('[a,a]');  // same error with '[a a]'  => Error at 'Check' time

END;

Edited: 25 Sept 2013, 3:12 p.m.

Home matrices are numerical/complex only for now. Thus having an identifier or function encoded in them is not possible. The compiler is pulling values to try and get a numerical value.

The function on the other hand, is perfectly happy to have an ID/function pointer inside it. Hence that one works.

Wasn't it exactly this way on the vanilla 48? I thought I remembered that alowing symbolics in a matrix was only allowed the first time on the 49g without 3rd party tools? (????)

TW

Edited: 25 Sept 2013, 3:48 p.m.

Quote:

---

Home matrices are numerical/complex only for now. Thus having an identifier or function encoded in them is not possible. The compiler is pulling values to try and get a numerical value.

The function on the other hand, is perfectly happy to have an ID/function pointer inside it. Hence that one works.

Wasn't it exactly this way on the vanilla 48? I thought I remembered that alowing symbolics in a matrix was only allowed the first time on the 49g without 3rd party tools? (????)

TW

---

correct -- that's how it was on the vanilla HP48. That is, you were not allowed to enter in anything but real or complex values for the entries of a matrix. The only way around that was a list of lists and using software the supported lists of lists as matrices. The HP49/50 allowed symbolic matrices as a new object type (new prologue, etc).

The TI-BASIC was what got me to assume that it was similarly handled on the HP Prime.

It would be nice, though, that expr("[COS(a),0,1]") would search through local variables, too. Moreover, if 'a' as a global variable exists, then local variables should take precedence over the global variables. As it currently stands, expr("[COS(a),0,1]") seems to only search among global variables, and then give up the ghost if 'a' does not exist globally. To be clear, though, this is only for matrices -- this is not an issue outside the context of matrices.

Edited: 25 Sept 2013, 4:00 p.m.