newRPL - build 1255 released! [updated to 1299]
04-27-2019, 06:23 PM
Post: #414
 Claudio L. Senior Member Posts: 1,883 Joined: Dec 2013
RE: newRPL - build 1089 released! [update:build 1158]
(04-26-2019 10:08 PM)Gilles Wrote:  About DMS mode, perhaps it could be better that this applies only with numbers taged as angle when we use trigonometric functions (like it does for the addition). For exemple :

<\30.4510d SIN would return the SINUS of 30°45'10"
but :
30.4510 SIN would return the SINUS of decimal 30.4510 even if you are in DMS mode

The actual behaviour seems inconsistant for me, because :

<\44.30d
<\0.30d
+
returns <\45.d

but of course :
44.30
0.30
+
returns 44.60

Nota : My old Casio fx-602P displays the dms mode with a unambigous 30°45'10". It could be nice to a have in New RPL a display like this : <\30°45'10"

Let's go by parts:
The angular mode only affects how trig functions interpret raw numbers.
In other words, if a function expects an angle and you pass a real number, what should the system do?
In the same way, inverse trig functions that return an angle, in which system do you want it? That's all that DMS, DEG, RAD, GRAD modes do. Everything else is business as usual (and that's where the consistency is).

You can always enter an angle as an angle object, regardless of the mode, and it will be correctly processed. Your first example of 30.4510 SIN being interpreted as decimal degrees is exactly what you get using DEG mode (you can still feed SIN with angle objects in any other system). DMS mode is for surveyors that want quick input of angles, forcing them to use the angle symbol defeats the purpose.

Your second example of 44.30 0.30 + giving you 44.60 is consistent... with math! The system doesn't have any way to know those numbers are angles and not reals, so why would it do a DMS addition? DMS mode only affects how trig commands interpret raw numbers, not how + interprets raw numbers, that should be clear.

In my view, a programmer should always use angle objects whenever they deal with angles. They are always consistent and flag-independent. However, old code might expect SIN to accept real numbers, so I couldn't completely eliminate that without breaking a lot of old RPL code. The compromise solution was to have a systemwide angle mode alongside the new angle objects.
If it was for me, the system would be locked into RAD mode (which is the only one that gives symbolic expressions like 'SIN(X)' a unique result, independent of any flags), any other system would have to be explicitly noted using angle objects.
 « Next Oldest | Next Newest »