newRPL: Angles revisited

[Claudio L.]

(03-31-2016 08:40 PM)Nigel (UK) Wrote:  A long time ago I wrote an RPN calculator program for the Casio FX-9860G calculator that uses angle tags in a similar way. I liked it; it would be nice to see something similar in newRPL.

My program has two buttons (D and R) which tag the number in the x register as degrees or radians respectively. If the x register already contains an angle tagged with D then pressing R converts it to radians and changes the tag to R, while pressing D removes the tag. So tagging and conversion are done with the same function.

In my program:

• Adding or subtracting two angles (e.g., 2D 1R +) gives an answer with the angle tag of the current angle mode. Adding or subtracting an angle and an untagged number works in the same way with the untagged number being implicitly tagged with the current angle mode. I don't like the idea of adding a number to an angle giving a number. In radian mode, 1 1D + and 1D 1 + should both mean the sum of 1 radian and one degree and should be tagged as an angle. I'm not too bothered about whether it is tagged as radians or degrees, but it is definitely an angle!
• There is no implicit tag when multiplying or dividing an angle by an untagged number.
• Dividing one angle by another gives an untagged result - the ratio of the two angles.
• In every other case (e.g., 2D 1R *) the angles are converted to the current angle mode, the tags are removed, and the calculation is carried out. It might be more sensible to throw an error in situations like these, although powers of angles might be meaningful in some cases.
• Dealing with trig and hyperbolic trig functions with complex arguments needs care!
  

Nigel (UK)

It seems we think alike. Your tags are pretty much the same thing I'm proposing.
The only difference is my proposal of keeping the format of the first argument.
My logic is a bit different, I think of operations as something applied to the number that's on the stack. For example, you have a hex number and you want to increase it. For easy typing, you just want to type 1 +, but you still want the result to be a hex number, hence keeping the first argument format is useful. Same concept helps with temperatures, etc.

For angles, I think the same applies: if you have an angle, it's reasonable to assume if you add a number to it you are adding another angle and want the result to be an angle, you just don't type it as an angle to save keystrokes.
However, when you have a real number and you add an angle, I'm not sure you are working with numbers or angles, so the type should remain "unknown"= real number. At least that's my logic, or it was until I read your post.
I think your logic makes sense too, but I have to think a little more before I break the consistency with all the other parts of newRPL.