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

[Claudio L.]

(08-05-2019 06:49 PM)ijabbott Wrote:  I'd quite like a calculator where the standard trig functions only worked in radians, at least for writing programs. You could then have some non-standard trig functions such as SIND/ASIND for angles in degrees, etc., as well as functions for converting between angle units (so SIND would be more or less equivalent to D->R SIN, perhaps avoiding any D->R rounding error). If there is an angle mode setting, it would only affect which set of trig functions the keys map to.

I considered going that route. There were a few annoyances:

a) The key definition changes when you change the mode, so when you are typing a program in the command line and press S, you get SIN, SIND, or SING depending on the current mode. It can get annoying if this is not what you intend.

b) From the user's perspective, if you type 90 and press S (assuming S key = SIN), you'd still need to check if the machine is in degrees, so there's no real difference from that point of view because you get a result without ever seeing if the key was actually mapped to SIN, SIND, etc.

c) For symbolic manipulation, you'd need to handle simplification of expressions separately for each of the 3 commands. This is not a bad thing per se, but it triples the number of rules dealing with trig, which triples the time it takes to process them all.

There's some good things: The derivative becomes crystal clear: the derivative of SIND(X) is pi/180*COSD(X)*derivative(X) and end of discussion. On the other system, the derivative of SIN(X) with X accepting any angular system will be COS(X)*derivative(X), which is correct or not depending on the point of view. If X is an angle object, then it's correct because X in any system represents the same angle, but if you plot the derivative vs. X in degrees then the magnitude of the slope is off.