[HP-PIRME] ^ OPERTOR // => SUPER BUG - Printable Version +- HP Forums (https://archived.hpcalc.org/museumforum) +-- Forum: HP Museum Forums (https://archived.hpcalc.org/museumforum/forum-1.html) +--- Forum: Old HP Forum Archives (https://archived.hpcalc.org/museumforum/forum-2.html) +--- Thread: [HP-PIRME] ^ OPERTOR // => SUPER BUG (/thread-258393.html) |
[HP-PIRME] ^ OPERTOR // => SUPER BUG - CompSystems - 12-11-2013 google translator =( M1:=[[1,2,3],[4,5,6]]; // matrix define M2:=[[1,2,3],[4,5,6],[7,8,9]]; [HOME MODE version ?] numeric math engine rectangular matrix ^ n => returns a wrong object type must be a string M1^1; => ~OK Error: Invalid input // => "Error: invalid dimension" M1^2; => ~OK Error: Invalid input M1^3; => ~OK Error: Invalid input M1^4; => ~OK Error: Invalid input M2^2; = [[30,36,42],[66,81,96],[102,126,150]] // OK [CAS mode version 1.1.0.27] numeric AND symbolic math engine M1^1; => "Warning, ^ is ambiguous on non square matrices, Use .^ to apply ^ element by element." ?? => [[1,2,3],[4,5,6]] // == .^ OPERATOR M1^2; => "Warning, ^ is ambiguous on non square matrices, Use .^ to apply ^ element by element." ?? => 91 // == DOT PRODUCT M1^3; => "Warning, ^ is ambiguous on non square matrices, Use .^ to apply ^ element by element." ?? =>[[1,8,27],[64,125,216]] // == .^ OPERATOR M1^4; "Warning, ^ is ambiguous on non square matrices, Use .^ to apply ^ element by element." ?? => 8281// == DOT PRODUCT M2^2; = [[30,36,42],[66,81,96],[102,126,150]] // OK SOMETIMES ^ OPERATOR CALCULATED THE DOT PRODUCT, ANOTHER MAKES THE SAME AS THE OPERATOR .^ For this?, is educational? is pedagogical?, if there are specific operators DOTP & .^
Edited: 11 Dec 2013, 1:07 p.m. after one or more responses were posted
Re: [HP-PIRME] ^ OPERTOR // => SUPER BUG - Han - 12-11-2013 The calculator gives a warning when you use a non-square matrix in CAS mode and even tells you to use .^ for dot products.
Quote:
I don't see the issue you are raising. Did you update to the most recent firmware?
Re: [HP-PIRME] ^ OPERTOR // => SUPER BUG - CompSystems - 12-11-2013 Quote: Fabulous that says the warning, but then do the dot function (.^) of command or dot product, HP-PrimeCAS is super ambiguous == SUPER BUG
example rectangular matrix ^ n => Error: Invalid input ~ok home mode rectangular matrix ^ 2*n => DOT PRODUCT cas mode, ? rectangular matrix ^ 2*n+1 => DOT ^ cas mode, ?
Edited: 11 Dec 2013, 1:12 p.m.
Re: [HP-PIRME] ^ OPERTOR // => SUPER BUG - Han - 12-11-2013 Quote: I made a typo about the warning. It does not say that .^ should be used for dot product. It says that it is used for element-wise exponentiation -- because it is making a guess that this might be what you actually intended to do. The way I am looking the different outputs is: what difference does it make if you are already warned that the operation is ambiguous? Does it matter what it returns at this point? Any result that it gives should really just be ignored because all that you get is a guess as to what was meant by M1^n. The result is consistent between even and odd cases, even if they are all meaningless in the context of a non-square matrix multiplication. As for why odd powers have a different output from even powers, only Bernard can answer this. It is either indeed a bug (but hardly a super bug) or it was intended behavior because the folks who use xcas prior to the HP Prime have certain needs for separating even and odd powers of this "alternative" type of multiplication. As already stated in much earlier threads, my personal opinion on this is ^ should only allow square matrices and produce an error otherwise. Hopefully this is just for transition into the next firmware in which ^ will only accept square matrices (since we have .^ now for element-wise exponentiation).
[Another related command for powers of matrices is matpow().]
Re: [HP-PIRME] ^ OPERTOR // => SUPER BUG - parisse - 12-12-2013 Even power of v is interpreted as ||v||^n, a notation that is often used for vectors, extended to non square matrices.
Re: [HP-PIRME] ^ OPERTOR // => SUPER BUG - Han - 12-12-2013 Quote:
Thank you for the clarification.
Re: [HP-PIRME] ^ OPERTOR // => SUPER BUG - CompSystems - 12-12-2013 Han: Thank you for the clarification. what is the clarification? M1:=[[1,2,3],[4,5,6]]; // matrix define M1^2; = 91 ??? ABS(M1); => SQROOT(91) ???? => ABS /=/ NORM => |...| not equal ||...||
||...|| Norm_(mathematics) http://reference.wolfram.com/mathematica/ref/Norm.html /=/ (different => not equal ) I agree that an ambiguous command, if there was no alternative command, why complicate the logic of mathematics? ^ not equal .^ // .^ is not the extention of ^, is a completely different operator * not equal .* // .* is not the extention of *, ... + not equal .+ // ... - not equal .- // ... / not equal ./ // ... abs not equal norm ... black not equal white
Edited: 12 Dec 2013, 8:43 p.m.
Re: [HP-PIRME] ^ OPERTOR // => SUPER BUG - Han - 12-12-2013 Quote: The clarification was that the even powers were computed differently than the odd powers. From the Help text for ABS():
Quote: http://en.wikipedia.org/wiki/Matrix_norm M1^2 = ||M1||^2 = ABS(M1)^2 = 91 since ||M1|| = ABS(M1) and even power is treated as even power of the Euclidean norm M1^3 = M1 .* M1 .* M1 = M1.^3 since odd power is treated as entry-wise .^
This is exactly the behavior that Bernard clarified. I don't agree with overloading the ^ to allow non-square matrices (even worse, to have two different behaviors), but I alas I do not work for HP nor am I a developer for xcas/giac. Some consider this a feature; I classify it as enabling sloppy mathematical notation. Edited: 12 Dec 2013, 8:54 p.m.
Re: [HP-PIRME] ^ OPERTOR // => SUPER BUG - CompSystems - 12-12-2013 operator overloading should only be applied in cases not involving math 3+4 => 7 "3" + "4" => "34" // valid [[ matrix ]] ^ (2*n+1) => "invalid dimension" // OK [[ matrix ]] .^ (2*n+1) => element by element ^ (2*n+1) // OK
Edited: 12 Dec 2013, 9:21 p.m.
Re: [HP-PIRME] ^ OPERTOR // => SUPER BUG - CompSystems - 12-12-2013 v1:=[1,-2,3]; v1 .^ 2; => [ 1^2, (-2)^2, 3^2 ] => [ 1, 4, 9 ] // Super OK dot( v1, v1 ); 1^2 + (-2)^2 + 3^2 => 14 // Super OK abs( v1 ); => [ 1, 4, 9 ] // Super OK, absolute value of each element ABS( v1 ); => SQROOT(14) // == NORM but go to entry line show abs( v1 ) => BUG, solution ||..|| == ABS(...) why better not to create a new command (NORM)and thus avoid ambiguity ( abs with ABS CAS version 1.1.0.27) For vectors, Norm[v] is Sqrt[v.Conjugate[v]] NORM( v1 ); => SQROOT(14) // Super OK v1 ^ 2; => 14 == NORM( v1 )^2 Why? mathematical criterion? [spn] El autor del CAS quiere que si se eleva un vector al cuadrado entonces esta realizando la norma al cuadrado, quien va recordar esto cuando este programando? obliga a tener un manual avanzando siempre al lado, mientras que si se respeta las definiciones de álgebra lineal no hay necesidad de buscar manuales, así mismo se sabe que si existe un comando para hallar la norma (NORM) me olvido de usar abs, igualmente yo se que existen operadores punto*/-+ que hacen operan elemento a elemento para que hacer que un operador matemático extienda su definición si se programo un comando para tal propósito, entonces estaría sobrando esos comando, que contradice la filosofía del autor del CAS
Una anecdota, hay un comando que es ambiguo o mejor como dice el autor del xCAS un comando que expande las posibilidades por defecto ese comando en la HP48 es el [/] que realiza la solución al sistema A*x=b por mínimos cuadrados, mientras estudiaba álgebra lineal, muchos de mis compañeros de clase se confundieron por que la calculadora les daba un resultado y sus operaciones otra, claro no habían leído el manual de la operación de este comando, ahora en la HP-Prime con tan terrible ambigüedad de varios comandos muchos en lugar de tener una herramienta que les ayude a comprobar resultados, sera un herramienta que genere confusión
Edited: 12 Dec 2013, 10:35 p.m.
|