[request] [±] key, always as change of sign operator

[compsystems]

sorry for my bad English

Currently the unary operator CHange of Sign (CHS), function NEG() is operating only for numbers on entry line =(

the key [±] is associated with NEG() operator

neg(5) → -5 // ok
5[±] → -5
x [±] → x- // in this case acts as subtraction operator binary =(, and there is a dedicated key for subtraction [-],two keys for the same operation

My suggestion is that the key associated change of sign [±] always acts always as neg(), It is very useful to change the sign to an expression without having to be returned to the start of it, for example

(a-b) [±] → -(a-b) and not as (a-b)-

[Han]

So when a user types 5+3 and places the cursor between the 5 and the +, should the negation key change the 5 to -5, or should it change the + symbol to - (subtraction)? I do not think that it would be easy to have a single key guess correctly 100% of the time as far as what the user intended is concerned.

[compsystems]

| → cursor position
[±] → [−] sign change unary operator −(#/expr) a number or expression but not to SUM or MINUS binary operator (ruler)
[-] → minus binary operator expr1-expr2
[+] → sum binary operator expr1+expr2


case 1:
5
5|± →−5 // ok, sign change to 5
−5|± → −(−5) -> 5 // ok


case 2:
5+3
5+| 3
5+|± 3 → 5+(−|3) → 5+(−3) // ok, sign change to 3 ⇒ 5+neg(3)
5+−±|3 → 5+−(−3) → 5+3

case 3:
5+3
5|+ 3 → -(5)+3 → -5+3 // ok, sign change to 5

case 4:
x|± → x− not acting as sign change, bad =( right no expressions
must be
x|± → −x

with minus operator
x|- → x- // ok



case 5:
±(+1) → neg(+1) → neg(1) → −1

case 5.1:
±+1 → neg(+1) → neg(1) → −1

case 6:
±(-1) → neg(-1) → −(-1) → 1
or
±(−1) → neg(neg(1)) → −(−1) → 1

case 6.1:
±-1 → Error Why? → neg(-1)

[retoa]

textmode is not RPN.

In RPN the operation (i.e. +/-) comes after the operand, so 2 [+/-] will be -2
In textbook and algebraic the operation are infix, or prefix if they are unary like [+/-], so the correct notation is [+/-] 2

If we start to mix RPN with non RPN the calculator behavior will be very chaotic.

[Tim Wessman]

(10-13-2016 07:49 AM)retoa Wrote:  If we start to mix RPN with non RPN the calculator behavior will be very chaotic.

Agreed. For convenience though, numbers and complexes and similar numerical only things are supported postfix since it makes sense in those cases.