a bug or a feature. - Printable Version +- 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).