newRPL: [UPDATED April 27-2017] Firmware for testing available for download

[matthiaspaul]

(10-23-2015 01:00 AM)Claudio L. Wrote:  

(10-22-2015 09:26 PM)matthiaspaul Wrote:  It would be convenient to have some easy means to attach the *current* angular mode to a value by something like a "generic" angle unit _< which gets automatically replaced by the specific unit according to the currently set angular mode.

That's interesting. The current unit system will not be able to support something like this without extensive modifications.
To make it simpler, we could provide a command that returns the current angle mode as a unit (1_r, etc.), let's call it ANGUNIT for now.
And to attach it you'd simply do << ANGUNIT →UNIT >>, or << ANGUNIT * >>.
Is that good enough? I don't know what specific use case you are thinking of.

Well, the idea is to make working with units and angles as easy (and powerful) as possible. ;-) I always found the treatment of angles in RPL half-baked, like an idea, that was started but left unfinished, and this also holds true for unit support for angles.

Specifically, trigonometric functions like SIN will assume arguments to be given in the currently set angular mode (DEG, RAD, GRAD, ...) unless the argument has a specific angular unit attached. Likewise, inverse trigonometric functions like ASIN return angular values according to the currently set angular mode, but there's no method to attach the corresponding angle unit automatically.
This doesn't impose much of a problem if the angular mode is never changed, but if it gets switched often, some unit-less values on the stack may be in degrees, others in radians etc. This is error-prone and it is therefore desirable to have the corresponding angle unit attached to these values.
To do this, the user or the program needs to know the current mode setting first. The user could accidently type the wrong unit. A program has to query mode flags and branch into several cases. (Of course, this could be put in a little utility program, but it'll always look like an after-thought. It would be better to address the problem in the core system already.)

One way to address this would be the introduction of functions like ASINU or _ASIN, which differ from the normal ASIN by returning values with the corresponding angle unit readily attached. But we recently discussed that having large sets of "parallel" functions only differing in intrinsical details is less than ideal for other reasons.

Your ANGUNIT would address the problem as well, but is still quite long to type.
I was hoping we could find something shorter, ideally as short as choosing ∠, [->]∠, [<-]∠ in the Units.Angle soft menu or typing a "special" unit like _∠ .

There's one more potential problem, but it applies to ANGUNIT as well as my idea to replace the _∠ by the actual unit on the first attempt to interpret this as a unit:

If the angular mode is changed after the ASIN, but before the invocation of ANGUNIT or the evalulation of _∠, it would reflect the new angular mode, not the one active while ASIN was executed. Basically, this is down to this being a sequence of operations rather than one atomic operation (like the hypothetical ASINU or _ASIN). While this loophole may be acceptable, it might be possible to avoid it: For this, we'd need a system where functions returning angles would store the current angular mode in a hidden attribute attached to the number object. For backward compatibility and to avoid unexpected sideeffects, this attribute would have to be ignored, except for if the "generic angle unit" _∠ would be attached to the value somewhen later on. Whenever this happens, it would be immediately replaced by the angle unit taken from the hidden attribute, and if not present, the current mode.

Alternatively, seeking for a simple solution, if the behaviour of functions like ASIN would be changed to attach the angular unit by default (perhaps depending on a flag), what were the effects on existing RPL programs only expecting such functions to return unit-less numbers?

Greetings,

Matthias