The case of the disappearing angle units, or "the dangle of the angle"

[Claudio L.]

(07-31-2019 07:34 PM)ijabbott Wrote:  Is it better to ignore angular units and just treat angles as plain old numbers (as long as an angle of 1 corresponds to 1 radian), or does the angular aspect have some cosmic significance that shouldn't be casually discarded? I guess this is more of a philosophical question, inspired by the way the WP-43S project plans to handle angles.

Oh, the joys of the angular units.
Basically, angles ARE just dimensionless numbers, but that doesn't really solve the problem, does it?
Let's say the user wants to add a number to an angle in degrees: do you consider the number to be in degrees? or the number to be in radians? or in the current angular system?
Then you have the inverse problem, like the area example you proposed: The user wants to calculate the area of an arc providing that angle in any system. But the formula only works if you divide by 1 radian or in other words: if the angle the user inputs is already in radians.
Here's how newRPL handles angles in the angle objects. It's a hack, but it does work the way the user expects 99% of the time without modifying the formulas.
I recently reworked my prior solution because I used to convert angles to numbers in the current angular system. That didn't work well for EXP(i*Theta) style expressions: multiplying the complex unit by the angle in degrees did not go well...
With the new solution, it converts to radians always, but then it has a problem when you do this for example: let's say you do SIN(90) and the system is in DEG mode. The SIN function takes an angle, but 90 is just a number, so you'd expect that number to be interpreted as an angle in degrees and return 1. But what if you have an actual angle with units and operate on it?

SIN( INV(INV(90°)))

Now you need to compute the INV() of an angle... so you convert those 90 degrees to pi/2, invert and later you invert again and end up with SIN(pi/2) but wait... in DEG mode SIN() was expecting a number in degrees, not in radians! How would the system know that when the user does SIN( INV(INV(90°))) it will receive the angle already in radians, but if the user just does SIN(90) it's in degrees?
A whole tracking system was put in place to determine if the arguments to SIN, COS and TAN were involved in any forced conversion to radians. It works but it's not foolproof, you can come up with some combinations of operations that can fool the system and still give a bad result (those combinations are typically meaningless so they don't come up naturally in formulas anyway, like the INV(INV(angle)) example).

That's one side of the story, using angle objects.

Then there's the old full-fledged unit system which tracks operations like INV(INV(90°)) without issues because it has the ability to work with units of °^-1. But... that system fails to recognize for instance that i*Theta needs to convert the system to radians. It keeps it in degrees, returning a complex number with a unit in degrees (0,90)_[°] (what the heck does that complex angle mean?) and the user would have to "manually" convert to radians so it doesn't solve the whole problem either. Radians, while a unit in itself, is non-dimensional so it's consistent with non-dimensional quantities (adding a number to an angle in radians is OK). This works well... except there's other non-dimensional units, and they are all consistent, so for instance you can add radians to decibels and that's fine because both are non-dimensional units (what does that even mean??).
For now you can't even do EXP(unit) in newRPL, because... what's the unit of e^(1_m)? e_[e^m]?? The unit system is equipped to deal with unit^n and even unit^(n/m) but no exp or log of units, that doesn't make physical sense.
So EXP needs non-dimensional arguments and will error if it's arguments have units... until somebody helps with an idea for a solution.

Then there's the third solution (the 49/50 series solution): whenever you have an expression that works with angles, you ask "Switch to radians?" and force the user to provide all arguments in radians, convert everything to radians and the problem is gone. It's a valid solution, but I hate the nagging though...