(sqrt(-2))^2

[retoa]

Hello !

I try to calculate (sqrt(-2))^2, which should give -2.
In home mode it works fine.

In CAS mode it works using brackets (first picture).
After pressing enter the square root will be represented without brackets, it will give (sqrt(2)*i)^2 which simplified gives -2 (second picture).

If I try to enter it without brackets (third picture), when I press enter the root becomes sqrt((-2)^2) and the answer will be 2, which is wrong (fourth picture).

Any hints?

[toml_12953]

(10-05-2016 02:33 PM)retoa Wrote:  Hello !

I try to calculate (sqrt(-2))^2, which should give -2.
In home mode it works fine.

In CAS mode it works using brackets (first picture).
After pressing enter the square root will be represented without brackets, it will give (sqrt(2)*i)^2 which simplified gives -2 (second picture).

If I try to enter it without brackets (third picture), when I press enter the root becomes sqrt((-2)^2) and the answer will be 2, which is wrong (fourth picture).

Any hints?

Use brackets.

Tom L

[retoa]

First you should not need brackets in this case.

Second if you look at the third picture the input line is equal to the left term (input) in the upper line, so both should give the same result.

[parisse]

(10-05-2016 02:33 PM)retoa Wrote:  Any hints?

Choose algebraic mode entry.

[retoa]

Ok, I can use brackets or choose algebraic mode entry (which will mean use brackets).
But why can the CAS not compute it right in textbook mode without brackets?

What is the difference between the input in the upper line and the one in the input line in the third picture? Why don't they give the same result?

Are there other situations where the CAS can not work in textbook entry mode?
Better said, should we always use algebraic entry mode in CAS to be sure the results will be correct?

Thank you for the answer

Reto

[Tim Wessman]

I suspect this is a result of the √ symbol which is treated as a unary operator vs a function sqrt(...). Maybe bernard will be able to shed some light here.

[parisse]

I would say it's a UI problem, since it works in algebraic mode. The CAS sees only algebraic input, 2d input is converted to algebraic outside the CAS.

[retoa]

(10-06-2016 05:10 AM)parisse Wrote:  I would say it's a UI problem, since it works in algebraic mode. The CAS sees only algebraic input, 2d input is converted to algebraic outside the CAS.

I agree, the input changes from (sqrt(-2))^2 to sqrt((-2)^2) when you press enter, so the CAS evaluates sqrt((-2)^2).

But in home it works fine. Is there a difference between the 2D interpretation in home and CAS?

It is very useful to know that CAS only sees algebraic input.

Reto

[Tim Wessman]

(10-06-2016 05:10 AM)parisse Wrote:  I would say it's a UI problem, since it works in algebraic mode. The CAS sees only algebraic input, 2d input is converted to algebraic outside the CAS.

√(-2)^2 is what is being passed to the CAS though. Shouldn't that be interpreted identically to sqrt(-2)^2? It gets evaluated and changed to √((-2)^2) which would indicate to me that the √ function token is being handled in a different way/priority then the spelled out "sqrt" function.

[compsystems]

I discovered the problem

In infix notation and linear infix notation , the precedence rules say the brackets () are evaluated first, then unary operators (change of sign/NEG [-]), then the multiplier operators (*, /, mod, ^), then the sum operators (+, -) ... then √, ...

-2 ^ 2 is equivalent to -(2^2) the brackets (2^2) is evaluated first -> 4 then changes sign -(4) -> NEG(4) the end result is -4

(-2)^2, the brackets (-2) is evaluated first NEG(2) -> -2, Then (NEG(2))^ 2 -> -2*-2 the end result is 4

The brackets () are also used to delimit the function arguments f(arg1, arg2, ..., argN)

sqrt( arg ) or

√(arg) ->
____¬
√arg


HP-PRIME KEY SEQUENCE (TEXT BOOK MODE aka 2D printing, infix notation )

ENTRY LINE

[√▣] + [2] + [±] is √(-2)¬ -> sqrt(-2) -> i*√2 // ok
https://www.wolframalpha.com/input/?i=%E2%88%9A(-2)

[√▣] + [2] + [±] + [-3] is √(-2-3)¬ -> sqrt(-2-3) -> √(-5) ¬ -> i*√5 // ok
https://www.wolframalpha.com/input/?i=%E2%88%9A(-2-3)

Now

[√▣] + [2] + [±] + [^2] is √(-2^2)¬ -> sqrt(-2^2) -> √(-(2^2) )¬ -> √(-(4)) ¬ -> √(-4)¬ -> 2*i // ok
https://www.wolframalpha.com/input/?i=%E2%88%9A(-2%5E2)

[√▣] + [2] + [±] + [>] + [spc] + [spc] «out of the radical » + [-3] is √(-2)¬ -3 -> sqrt(-2)-3 -> √(-2)-3 -> -3+(i*√2) // ok
https://www.wolframalpha.com/input/?i=%E2%88%9A(-2)-3

Problem Parser with ^2
in the example above it works well (√(-2)¬ -3) -> sqrt(−2)-3

[√▣] +[2] + [±] + [>] + [spc] « out of the end symbol radical (¬) » + [^2] retunrs 2 // ????

√(-2)^2 Brackets are the delimiters of radical function, must be as sqrt(−2)^2 and not sqrt(−2^2) , otherwise ambiguity is generated with the case √(-2)-3


[√▣] +[2] + [±] + [>] + [^2] must be for next firmware =) ( √(-2) )^2 -> sqrt(-2)^2 ->
-> (√(-2))¬^2 -> (√( neg(2) )^2 -> (i*√2)^2 -> 2*(-i)^2 -> -2 // ok
https://www.wolframalpha.com/input/?i=(%...A(-2))%5E2


HP-PRIME KEY SEQUENCE (ALGEBRAIC MODE aka LINEAR MODE 1D, aka linear infix notation )

ENTRY LINE

[√] + [2] + [±] is √(-2)¬ -> i*√2 // ok

[√] + [2] + [±] + [-3] is √(-2-3)¬ -> √(-5) ¬ -> i*√5 // ok

Now

[√] + [2] + [±] + [>] + [spc] « out of the end symbol radical (¬) » + [-3] is √(-2)¬ -3 -> (i*√2) -3 // ok
[√] + [2] + [±] + [^2] is √(-2^2)¬ -> √(-(2^2) )¬ -> √(-(4)) ¬ -> √(-4)¬ -> 2*i // ok

[parisse]

(10-06-2016 02:12 PM)Tim Wessman Wrote:  √(-2)^2 is what is being passed to the CAS though. Shouldn't that be interpreted identically to sqrt(-2)^2? It gets evaluated and changed to √((-2)^2) which would indicate to me that the √ function token is being handled in a different way/priority then the spelled out "sqrt" function.

Yes, they are parsed differently because you don't need parenthesis after √, unlike for sqrt. The token for the bison parser is T_NOT, which means you must add parenthesis around the sqrt (they are not required inside): (√-2)^2.

[John P]

(10-06-2016 06:05 PM)parisse Wrote:  

(10-06-2016 02:12 PM)Tim Wessman Wrote:  √(-2)^2 is what is being passed to the CAS though. Shouldn't that be interpreted identically to sqrt(-2)^2? It gets evaluated and changed to √((-2)^2) which would indicate to me that the √ function token is being handled in a different way/priority then the spelled out "sqrt" function.

Yes, they are parsed differently because you don't need parenthesis after √, unlike for sqrt. The token for the bison parser is T_NOT, which means you must add parenthesis around the sqrt (they are not required inside): (√-2)^2.

I am not sure if what I noticed is very relevant to the discussion, but I will post it anyway.

1. sqrt(-2*i)^2-> -2*i which is OK because ((-2*i)^1/2)^2-> -2*i
2. radical -2*i ^2, no barckets, I get 2*i, but when I enclose in brackets the (radical -2*i)^2 I get -2*i, the same as in 1 above.

I looks that when you do like in 2 above, even when calculator does show that you are outside of the radical sign and do the ^2 the parser puts in the brackets and squares (-2*i)^2, what is under the radical sign and that evaluates to -4. The radical then evaluates the -4 as (-1)*4 that gives i*2 and that is not correct with what you expect.

For me the problem with the radical as square root is that the parser does not enclose in brackets the radical with what is inside of it, but only what is inside, and in the case of ^2 applies it only to what is inside, under the radical, hence, the wrong result.

If you put brackets around:(radical for square root -2*i)^2 you will get -2*i the correct result.

[compsystems]

(10-06-2016 06:05 PM)parisse Wrote:  you don't need parenthesis after √

true, but if is a 2D template √[▣], but if it is written in infix notation linear, parentheses are required √().
using the 2D template of the hp-prime there is a problem, try the above examples

[parisse]

Parenthesis are *not* required in algebraic (1-d) entry after √. This is the reason why √ is different from sqrt.
A solution to the UI/CAS parser misbehaviour in 2-d entry would be to add parenthesis outside of the sqrt before calling the CAS parser.

[compsystems]

(10-06-2016 08:19 PM)parisse Wrote:  Parenthesis are *not* required in algebraic (1-d) entry after √. This is the reason why √ is different from sqrt.

ok, but it gives clarity to the expression
√(-2)-3 == √-2-3 [enter] 1
√-2-3 ≠ √(-2-3) [enter] true

the ti68k calc, the operator √ automatically put brackets
[√] -> √(), you avoid adding them into compound expressions


why different answers? hp-prime versus Wolfram/hp48/50g/tiv200/ti-nspireCXcas/...

(10-06-2016 08:19 PM)parisse Wrote:  A solution to the UI/CAS parser misbehaviour in 2-d entry would be to add parenthesis outside of the sqrt before calling the CAS parser.

The template √▣ has a bug
[√▣] +[2] + [±] + [>] + [spc] « out of the end symbol radical (¬) » + [^2] returns 2 //
Why?

clearly shows that the ^ 2 is outside the radical

[parisse]

In fact, I now think that the best way to reflect the 2-d template (where the sqrt bar has a variable width) would be to translate √... to sqrt(...)
For √(-2)^2 I don't think there is a universal convention for the precedence between √ and ^, that explains the difference.

[compsystems]

https://en.wikipedia.org/wiki/Order_of_operations says

The root symbol, √, requires a symbol of grouping around the radicand. The usual symbol of grouping is a bar (called vinculum) ̄ ̄ over the radicand √ ̄ ̄. Other functions use parentheses around () the input to avoid ambiguity.

https://en.wikipedia.org/wiki/Vinculum_(symbol)

sorry google translator ->

on 2-D template of √ included the symbol ̄ ̄ that distinguishes or group the expression of radicand, in 1-D the only way of grouping expression of the radicand is to use Bracket

https://en.wikipedia.org/wiki/Bracket_(mathematics)

√( ), parentheses
√[ ] square brackets
√{ } braces
√<> angle brackets

This is the convention that follow several CAS I've tried
√[-2]^2 == √(-2)^2 == SQRT(-2)^2 = -2 and not SQRT(-2^2)

another symbol to delimit can be ¬

√ ¬

√-2¬^2

I suggest that in Algebraic mode (1-D)
pressing √ key, the parentheses is incorporated on entry line

[√] -> √()