newRPL: Angles revisited

[Claudio L.]

(04-01-2016 07:01 PM)emece67 Wrote:  I agree on this. On my view:
[list]
[*]angle +/- scalar = scalar +/- angle = angle, with scalar meaning an angle in the same units as the other operand (30D + 1 = 31D, no matter the current angle mode)
[*]angle * scalar = scalar * angle = angle, in the same units as the angular argument
[*]angle / scalar = angle, in the same units as the angular operand

So far so good, scalar +/- angle breaks consistency but could be done.

(04-01-2016 07:01 PM)emece67 Wrote:  [*]scalar / angle = scalar, the result is scalar/(angle converted to radians), 2 / 90D = 4/pi
[*]angle * angle = scalar, the result being the product of the 2 angles converted to radians (90D * 100G = pi^2/4)

This could be a problem. For example an expression:
'ASIN(A)*ASIN(A)/ASIN(A)'. The user has the settings in DEG, and thinks ASIN will return DEG, so you would expect the result to be let's say 45 or ∡45°.
If the operator associates the right side first:
ASIN(A)*(ASIN(A)/ASIN(A)) = ASIN(A)*1 = ∡45°
but if it associates from the left:
(ASIN(A)*ASIN(A))/ASIN(A) = (pi/4)^2/∡45° = pi/4 (correct, but in radians!)

With the "angle is a number" approach:
ASIN(A)*(ASIN(A)/ASIN(A)) = ASIN(A)*1 = ∡45°
(ASIN(A)*ASIN(A))/ASIN(A) = 45^2 / ∡45° = 45 (not an angle, but at least the same number as expected)

On the other hand, the "angle is a number" can also give bad results in expressions with mixed systems:

'∡50g*2/∡90°'

If associated from the left:
(∡50g*2)/∡90° = ∡100g/∡90° = 1
versus:
∡50g*(2/∡90°)= ∡50g*(1/45)= ∡1.11111111111111g

This can seriously drive a user crazy. What could be a solution for this?