# HP Forums

Full Version: [HP-PIRME] ^ OPERTOR // => SUPER BUG
You're currently viewing a stripped down version of our content. View the full version with proper formatting.

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

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:
Warning, ^ is ambiguous on non square matrices. Use .^ to apply ^ element by element.

I don't see the issue you are raising. Did you update to the most recent firmware?

Quote:
The calculator gives a warning when you use a non-square matrix in CAS mode and even tells you to use .^ for dot products.

Fabulous that says the warning, but then do the dot function (.^) of command or dot product, HP-PrimeCAS is super ambiguous == SUPER BUG

example
M1^2; => "Warning, ^ is ambiguous on non square matrices, Use .^ to apply ^ element by element." ?? => Then 91 ??? // == DOT PRODUCT

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.

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
M1^2; => "Warning, ^ is ambiguous on non square matrices, Use .^ to apply ^ element by element." ?? => Then 91 ??? // == DOT PRODUCT

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, ?

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().]

Even power of v is interpreted as ||v||^n, a notation that is often used for vectors, extended to non square matrices.

Quote:
Even power of v is interpreted as ||v||^n, a notation that is often used for vectors, extended to non square matrices.

Thank you for the clarification.

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://en.wikipedia.org/wiki/Norm_(mathematics)

/=/ (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.

Quote:
Han: Thank you for the clarification.

what is the clarification?

The clarification was that the even powers were computed differently than the odd powers. From the Help text for ABS():

Quote:
Syntax: ABS(expr) or ABS(matrix)

For numerical arguments, returns the absolute value of the expression. For matrix arguments, returns the Frobenius (Euclidean) norm of the array.

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.

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.

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
Gracias

Edited: 12 Dec 2013, 10:35 p.m.