Post Reply 
newRPL: [UPDATED April 27-2017] Firmware for testing available for download
10-06-2015, 09:27 PM (This post was last modified: 10-07-2015 11:39 PM by matthiaspaul.)
Post: #56
RE: newRPL: [UPDATED Oct-01-2015] Firmware for testing available for download
(10-03-2015 06:15 PM)Claudio L. Wrote:  I consider a bad thing if the result of a command depends on flags. I believe (as much as possible) that output of a command should depend exclusively in the input provided, not on system-wide flags.
Actually, I think it very much depends on what you're doing. If you need to make decisions in programs based on values affected by various mode settings, things can become quite cumbersome, in particular if the program language does not provide good support to determine the current mode. If, however, you are using the calculator interactively, modes can make working with the calculator much more convenient or even help safe operations. Therefore, I think, both need to be supported.
Quote:For trig functions, I've been thinking there should be sets of functions for each unit, for instance: SIN, DSIN, and GSIN would be the same function SIN, but accepting radians, degrees and grads. You'd still have DEG/GRAD/RAD mode in the calc, but it's only for the UI, which will use DSIN instead of SIN when you are in DEG mode. A compiled program with SIN should run the same regardless of the system mode you are in.
If by this you mean that SIN should always work in radians mode, I don't think it would be a good idea. Instead SIN should always assume a number to be given in the current mode setting (DEG, RAD, GRAD, TURN, ...) except for when the number has an angular unit attached to it. In this case, it should accept the number in the given unit (as it already does in RPL).

There could be additional functions like SIND, SINR, SING or SINT, which would assume a number to be given in the corresponding unit (DEG, RAD, GRAD, TURN) regardless of the current angular mode setting, except for when an angular unit is attached to the input value as well. In that case, they should accept the number in the given unit just like the normal SIN function.

Similarly, the standard ASIN should always return an angular value in the currently selected angular mode. There could be additional functions like ASIND, ASINR, ASING, ASINT, which would return the number in the corresponding unit regardless of the current angular mode setting.
In my preliminarly (and unfinished) proposal above, all such functions would automatically append the corresponding angular unit to the resulting value, so that this information does not get lost later on. However, to not break existing programs, it would require some kind of special mode, otherwise the functions should return unit-less values as before. Of course, another parallel set of functions could be introduced for this purpose (ASINDU etc.).

But: While from personal experience I see usecases for all of them, I don't like the idea of having vast amounts of virtually identical trigonometric functions with minor internal mode changes. Since programs can be interrupted anyway, do we really need atomic instructions for all of these cases? Isn't it possible to define either some unobtrusive syntax enhancements or a more general set of functions which could be used to achieve the same effect?

For example, the proposed SIND could be replaced by a combination of D> (or DEG>) followed by the normal SIN function, if D> would be a function which assumes a unit-less stack value to be given in degrees and converts it into the current angular mode. If the input parameter has an angular unit attached to it, D> will convert from the given unit into the current unit according to the mode setting. If the input value had units, the output value should have units as well, otherwise a unit-less value should be returned.

Likewise, the proposed ASIND could be replaced by the sequence ASIN >D, where >D (or >DEG) would be a function converting a unit-less stack value from the current angular mode to degrees, unless the input value has an angular unit attached to it. In this case it would convert from that unit to degrees. If the input value had units, the output value should have units as well, otherwise a unit-less value should be returned. >D should not change the global mode to DEG, just convert the value, if necessary.

In addition to >D and D> we'd need similar functions >R (>RAD), R> (RAD>), >G (>GRAD), G> (GRAD>) and >T (>TURN), T> (TURN>). These 6 (or 8) functions would safe us from adding vast amounts of similar trigonometric functions, and would be useful in their own right as well. Unless the user would interrupt a program in the middle of the sequence, switch angular modes and let it continue to run, the result would be the same as using dedicated functions like SIND or ASIND carrying out the same operations as atomic function.

Regarding user interface, in a special advanced UI mode pressing the SIN key could still emit the corresponding sequence of operations (f.e. D> SIN, R> SIN, G> SIN, T> SIN) depending on the current mode setting (although I do not know if I would really like this in practise, assuming that the >x and x> function would be easily available on the keyboard as well).

Several things are still missing:

- Direct conversion functions from any to any other angular mode similar to the two existing RPL functions R>D and D>R:

R>G, R>T,
D>G, D>T,
G>D, G>R, G>T,
T>D, T>R, T>G

- Some way to tell functions returning angular values to append the unit as well. This could be a mode setting, but would be ideally some syntax sugar, like ASIN_ instead of just ASIN. Perhaps this could be part of a more general concept. Alternative, is there some easy means to attach the current angular mode to a stack value, if it does not contain an angular unit already?

- Some way to conveniently retrieve the current angular mode setting (beyond reading any raw flags), perhaps something like DEG?, RAD?, GRAD? and TURN? returning a boolean value, or AMODE? returning a number corresponding with the mode.

- 3 (4) hotkeys to directly switch to the 3 (4) angular modes, or a toggle hotkey switching between the current and the previously set angular mode when pressed once, between the current and the pre-previously set mode, when pressed twice in a row (and between the current and the pre-pre-previously set mode when pressed three times in a row).

Greetings,

Matthias


--
"Programs are poems for computers."
Find all posts by this user
Quote this message in a reply
Post Reply 


Messages In This Thread
RE: newRPL: [UPDATED Oct-01-2015] Firmware for testing available for download - matthiaspaul - 10-06-2015 09:27 PM



User(s) browsing this thread: 6 Guest(s)