newRPL: Angles revisited

[Nigel (UK)]

(04-01-2016 11:15 PM)Claudio L. Wrote:  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?

Suppose we allow powers - positive and negative - of these angle tags. Then:
45D * 45D / 45D is 45D whichever way we associate, and
50G * 2 / 90D is always going to be 1.

A rule saying that when adding an angle to a number, the number has an implicit tag corresponding to the current angular mode but that there are no implicit tags for multiplication or division would make me happy, but I expect that you would prefer the tag for addition to come from the first argument.

There should be a function that at any point removes a tag, including its powers, leaving a number that depends on the current angular mode. This function will be called if an operation is performed that makes no sense for angles.

Does this work? If so, does it introduce new problems that I haven't yet considered?

Nigel (UK)