newRPL: Angles revisited

[emece67]

(04-01-2016 06:27 PM)Nigel (UK) Wrote:  So 30D 3 / gives 10D; 30D 3D / gives 10.

I agree that 30D 3 / is ambiguous - does 3 mean "3" or "3D" or "3R" in radians mode? - but I think that this is the best way to resolve the ambiguity.

I agree on this. On my view:

• 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
• 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)
• angle / angle = scalar, prior to the division, both angles are converted to the same unit (90D / 100G = 1)
• unary minus: maintains the angle unit
• trigs: work as expected (tagged arguments are taken into account, untagged ones are in the units given by the current angle mode)
• inverse trigs: the result is in the units specified by the current angle mode, but see next
• all others: if any operand is an angle, it is converted to radians
  

This way, the angular mode only specifies the format used by the direct trigs if the argument is not tagged, and in the inverse trigs to specify the output format.

Still, there are cases where this approach can give rise to funny/unexpected results. I really enjoy the questions raised by Claudio on this project!