+- HP Forums (https://www.hpmuseum.org/forum)
+-- Forum: HP Calculators (and very old HP Computers) (/forum-3.html)
+--- Forum: HP Prime (/forum-5.html)
+--- Thread: a bug or a feature. (/thread-5114.html)
a bug or a feature. - ji3m - 11-12-2015 03:05 PM
I am having great difficulty doing cas matrix operations in a program.
The test case below shows one of the problems
EXPORT hsbat2(M)
BEGIN
LOCAL I,P,Q;
DEBUG;
I := inv(M); <- the inverse seems ok. Both M and I are lists
P := I*M; <- a problem here since '*' does silly list multiply
Q := simplify(P); <- since P is wrong this doesnt do much.
{M,I,P,Q}
END;
From the cas console by hand the matrices are sugar coated with
[[..]] and the parser knows that they are matrices (hidden type) so
it does the right thing.
Not so in a program where '*' sees things as lists so it multiplies element
by element, the wrong answer for matrices and vectors.
If there is a multiplyMat(M1,M2) like function, i cant find it.
Apparenty most of the cas functions expecting vectors or matrices treat
lists appropriatly. Not so for lexical operators, i guess.
Another problem i have is determing the return type when matrices or vectors
are involve since everything is a list.
Do i need to write my own matrix /vector multiply routines for program use[/u]?
RE: a bug or a feature. - Marcus von Cube - 11-12-2015 03:14 PM
(11-12-2015 03:05 PM)ji3m Wrote: EXPORT hsbat2(M)
BEGIN
LOCAL I,P,Q;
...
{M,I,P,Q}
END;
Have you tried to create a #CAS program using the pragmas (#CAS, #END if I'm right)? Your program is a Home program which does a lot of unnecessary conversions between the environments for each call to a CAS function. These conversions may lose information such as the CAS subtype of a list.
RE: a bug or a feature. - Han - 11-12-2015 03:29 PM
(11-12-2015 03:05 PM)ji3m Wrote: I am having great difficulty doing cas matrix operations in a program.
The test case below shows one of the problems
EXPORT hsbat2(M)
BEGIN
LOCAL I,P,Q;
DEBUG;
I := inv(M); <- the inverse seems ok. Both M and I are lists
P := I*M; <- a problem here since '*' does silly list multiply
Q := simplify(P); <- since P is wrong this doesnt do much.
{M,I,P,Q}
END;
How are you calling the program? It runs just fine to me.
M5:=[[1,2,3],[−1,0,1],[0,0,1]];
hsbat2(M5) returns
Code:
{
[[1,2,3],
[−1,0,1],
[0,0,1]],
[[0,−1,1],
[0.5,0.5,−2],
[0,0,1]],
[[1,0,0],
[0,1,0],
[0,0,1]],
[[1,0,0],
[0,1,0],
[0,0,1]]
}Why are you using lists? Can you show us your example that fails?
RE: a bug or a feature. - ji3m - 11-12-2015 03:45 PM
Sure enough, converted test case to #cas and it produced the very correct results.
So i can make a matmpy(m1,m2) in #cas.
Ive been trying to avoid #cas pgms since they are deleted when a restart is done.
The purge () function doesnt let a program purge selected vars only.(no way to get a list of vars from a program env)
BTW, the general help menu shows operators like ",*" , ",+" to do element by element
operations on lists, etc. which implied that the normal "*" should not do this. But alas, it doesnt know the subtypes as you point out.
RE: a bug or a feature. - ji3m - 11-12-2015 03:51 PM
Han:
Everything is fine with numeric matrices. They even have their own TYPE.
Symbolic (cas) Matrices and vectors are all typed as lists so the home-mode program language is lost in space when symbolics cross into its domain.
RE: a bug or a feature. - Han - 11-12-2015 04:16 PM
(11-12-2015 03:51 PM)ji3m Wrote: Han:
Everything is fine with numeric matrices. They even have their own TYPE.
Symbolic (cas) Matrices and vectors are all typed as lists so the home-mode program language is lost in space when symbolics cross into its domain.
I see now. Yes, unfortunately a #cas program is necessary to avoid these cross-parsings of inputs (and outputs, too).