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

[matthiaspaul]

We have means to attach the various supported angular units (_deg, _rad, _grad, ...) to values, but this implies that the angular mode is known, which may not be the case in programs unless the program would enforce a particular angular mode or query the current mode.

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.

Example:

- angular mode is set to DEG
- ASIN returns a unitless value n (in degrees)
- attaching the "generic" angle unit _< to the value n results in n_deg

- angular mode is set to RAD
- ASIN returns a unitless value n (in radians)
- attaching the "generic" angle unit _< to the value n results in n_rad now

etc.

Greetings,

Matthias

[Claudio L.]

(10-22-2015 08:50 PM)matthiaspaul Wrote:  Actually, I think, prefixes are so fundamental, the system should ideally support them both (decimal per SI/ISO and binary per IEC/IEEE/ISO) by default.

I understand your point.
Decimal prefixes are used for many units, consistently as per SI specifications, therefore it makes sense that the system supports them automatically, as the effort of entering 20 units for each unit you want to define is significant.
Binary prefixes on the other hand, are only used on one unit (byte). For that one particular case, there's only a few units that need to be defined (8), so I'm not sure I can justify the speed penalty in the system to scan for those prefixes on every single operation involving units.
Other than the definition of the unit, there's absolutely no difference on whether the prefix is applied "manually" by the user, or automatically by the system, so in that case I'll probably define the byte with all its prefixes as a system unit, with 8 individual definitions, and the user will never know the difference.

(10-22-2015 08:50 PM)matthiaspaul Wrote:  For flexibility, perhaps the ? syntax could be expanded by adding some kind of "attributes" to it so that the system will support on a unit by unit basis:

- no unit prefixes (f.e. 'u' UDEFINE)
- all decimal and binary prefixes (f.e. '?u' UDEFINE)
- only decimal prefixes (f.e. 'x?u' UDEFINE)
- only binary prefixes (f.e. 'i?u' UDEFINE)
- only decimal prefixes with positive exponents (f.e. '+?u' UDEFINE or '+x?u' UDEFINE)
- only decimal prefixes with negative exponents (f.e. '-?u' UDEFINE or '-x?u' UDEFINE)
- decimal with positive exponents only as well as binary prefixes (f.e. '+i?u' UDEFINE or '+xi?u' UDEFINE)

Ideas for other special case attributes:

- allow percent and permille as unit prefixes (f.e. '%?u' UDEFINE)
- absolute / relative unit conversion as with temperatures (would need some additional notation to specify conversion factors)
- allow to specify a "preferred" target prefix to be used in results (would need some system to resolve conflicting preferences for different units). The system would still allow to convert into something specific, but would default to preferred units otherwise (f.e. 'm?m' UDEFINE would return results in mm, even if given in cm or m etc. or 'Gi+x?B' UDEFINE would return results in GiB even if given in GB, whereas 'G+xi?B' UDEFINE would return results in GB even if given in GiB.)

(The syntax is just a rough proposal to illustrate the idea, nothing "finished".)

Greetings,

Matthias

I like the "preferred target unit" idea, perhaps as an attribute of a variable, not of the unit per se. I'm not so sure how to implement something like that yet, I'll have to give it some more thought.
Regarding the additional syntax, 'G+xi?B' looks like a Regex expression, a user would only be able to use that with the manual in hand, or more likely will never use that feature.

[Claudio L.]

(10-22-2015 08:59 PM)matthiaspaul Wrote:  Are there some easy (interactive and programmatical) means to declare an approximated number as exact again?

Greetings,

Matthias

Good point.
I didn't really think about it, but I believe they will become necessary. You could calculate something approximate, round to 4 digits for example, and then want to treat that number as an exact constant for input to an expression.
I'm thinking A→E and E→A could be good candidates (exact to approx and viceversa). But perhaps it should just be →EXACT and →APPROX.
These commands should work not only on commands, but on identifiers too once the trailing dot is extended to mean "identifiers to be evaluated immediately". Perhaps the names should be different, since "exact" and "approx" don't really apply to the identifiers.
Any ideas for more generic names?
As far as interactive, I don't know how often this will be needed, if it is justified to give it a dedicated key or just some menu entries somewhere for the commands above.

[Han]

(10-23-2015 12:48 AM)Claudio L. Wrote:  

(10-22-2015 08:59 PM)matthiaspaul Wrote:  Are there some easy (interactive and programmatical) means to declare an approximated number as exact again?

Greetings,

Matthias

Good point.
I didn't really think about it, but I believe they will become necessary. You could calculate something approximate, round to 4 digits for example, and then want to treat that number as an exact constant for input to an expression.
I'm thinking A→E and E→A could be good candidates (exact to approx and viceversa). But perhaps it should just be →EXACT and →APPROX.
These commands should work not only on commands, but on identifiers too once the trailing dot is extended to mean "identifiers to be evaluated immediately". Perhaps the names should be different, since "exact" and "approx" don't really apply to the identifiers.
Any ideas for more generic names?
As far as interactive, I don't know how often this will be needed, if it is justified to give it a dedicated key or just some menu entries somewhere for the commands above.

How about ~ for approx and \( \equiv \) for exact? Make left shift enter one, and right shift enter the other in terms of keypresses.

[Claudio L.]

(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.

[Claudio L.]

(10-23-2015 12:59 AM)Han Wrote:  How about ~ for approx and \( \equiv \) for exact? Make left shift enter one, and right shift enter the other in terms of keypresses.

That could work as far as symbols. However, Enter has ANS and →NUM, are you suggesting we relocate those? ANS might not be needed on a full RPL machine but I'm concerned about relocating →NUM.
EDIT: Perhaps only ANS should be replaced with a toggle function, if it's exact goes approx and vice versa.

[Han]

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

(10-23-2015 12:59 AM)Han Wrote:  How about ~ for approx and \( \equiv \) for exact? Make left shift enter one, and right shift enter the other in terms of keypresses.

That could work as far as symbols. However, Enter has ANS and →NUM, are you suggesting we relocate those? ANS might not be needed on a full RPL machine but I'm concerned about relocating →NUM.
EDIT: Perhaps only ANS should be replaced with a toggle function, if it's exact goes approx and vice versa.

Well, I was thinking ease of programming by having the two symbols accessible via the keyboard (rather than via a character catalogue). If we want to keep as much of the old keyboard layout as possible, perhaps →E and →A would suffice, and Ans can toggle. I prefer the unix style of naming commands -- use as few characters as possible :-)

[Helix]

(10-19-2015 10:14 PM)Claudio L. Wrote:  Latest ROM update as of October 19, 2015:
Changelog:
* Added multi-line command line editor
* Added autocomplete function
* First mode is always C when entering alpha
* ENTRY cycles between P and A only

To use autocomplete, just start adding letters, the suggested word will be displayed in the status area. Holding Alpha+cursors up and down will select next/previous suggestion.
Holding Alpha+ cursor right will insert the command in the command line.

As usual, please find bugs and report back.

Claudio

ALPHA mode:
- it is easy to use now, and I can say it is intuitive for me.
- I think that ENTRY works now as it should work in program mode. In algebraic mode, I think that some keys should remain active, for example the HIST key (or the STO key depending of the settings for the menus). This would permit to create a variable A with the sequence:
' ALPHA A ' ' HIST (or ' ALPHA+A HIST) instead of ' ALPHA A ENTER HIST

Multi-line editor:
- inserting the carriage return character inside a line shifts the cursor at an unpredictable place (end of the new line, beginning of the following line, or somewhere in the new line). It should be placed at the beginning of the new line.
- The down arrow key doesn't open the multi-line editor (probably not yet implemented…)

Autocomplete function:
- a lot of commands are missing
- they are arranged in an arbitrary order. Because of these two (temporary?) drawbacks, the autocomplete function is useless for me.
- if a complete list of commands can be displayed in alphabetic order, I imagine a long press on the arrow keys could scroll the list of commands.
- It would be nice also to have access to names beginning with a special character, for example <-HMS. Perhaps it should appear among names beginning by the letter H?
- If ON is pressed to quit the line editor, the suggested command remains in the status area. For example, R ON leaves ROT (If I remember correctly).

Other remarks:
- EEX should show e instead of E, to be consistent with the symbol used in the stack.
- 'A/2.' ENTER EVAL returns A

[matthiaspaul]

(10-22-2015 09:43 PM)Claudio L. Wrote:  

(10-22-2015 08:50 PM)matthiaspaul Wrote:  Actually, I think, prefixes are so fundamental, the system should ideally support them both (decimal per SI/ISO and binary per IEC/IEEE/ISO) by default.

I understand your point.
Decimal prefixes are used for many units, consistently as per SI specifications, therefore it makes sense that the system supports them automatically, as the effort of entering 20 units for each unit you want to define is significant.
Binary prefixes on the other hand, are only used on one unit (byte). For that one particular case, there's only a few units that need to be defined (8), so I'm not sure I can justify the speed penalty in the system to scan for those prefixes on every single operation involving units.

In IEC 60027-2 the binary prefixes were still restricted to units of information storage, but AFAIK ISO/IEC 80000-13, which incorporates the SI decimal as well as the IEC binary prefixes into the ISQ system, no longer has this restriction, that is, it is possible to apply binary prefixes to other units as well - and it even makes sense for a number of things outside of information technology. F.e. a frequency ten octaves above 1 Hz is 1024 Hz (the value must be doubled for each octave, so ten octaves represent a factor of 2^10). 1024 Hz = 1.024 kHz = 1 KiHz (or 1 kiHz - both are valid).

Another potential use of binary prefixes could be in conjunction with the TU (time unit), a unit of time defined in the IEEE 802.11 standard as 1024 µs.

(10-22-2015 09:43 PM)Claudio L. Wrote:  

(10-22-2015 08:50 PM)matthiaspaul Wrote:  - allow to specify a "preferred" target prefix to be used in results (would need some system to resolve conflicting preferences for different units). The system would still allow to convert into something specific, but would default to preferred units otherwise (f.e. 'm?m' UDEFINE would return results in mm, even if given in cm or m etc. or 'Gi+x?B' UDEFINE would return results in GiB even if given in GB, whereas 'G+xi?B' UDEFINE would return results in GB even if given in GiB.)

(The syntax is just a rough proposal to illustrate the idea, nothing "finished".)

I like the "preferred target unit" idea, perhaps as an attribute of a variable, not of the unit per se. I'm not so sure how to implement something like that yet, I'll have to give it some more thought.
Regarding the additional syntax, 'G+xi?B' looks like a Regex expression, a user would only be able to use that with the manual in hand, or more likely will never use that feature.

I agree. Of course, that ad-hoc "syntax" is cumbersome and incomplete. For example, it misses a syntax to remove attributes from or add attributes to existing definitions without having to repeat the whole definition (something like setting bit flags in C via |= etc.).
Ideally, there would be some short notation for experienced users (to safe keystrokes when entering it on the calculator) and a longer, more "symbolic" representation for readability in programs and when writing programs externally.

Regarding applying attributes to units or variables, I think, both might make sense depending on the situation. Under the pre-requisite that there is some easy means to redefine and overload existing definitions (in order to minimize the risk of accidently screwing up the "core definitions"), there are scenarios where a user might know that s/he needs specifically prefixed output units for a while, so putting such preferences into the unit definitions directly (or something else that affects the units individually) might be easier than defining the preferred format for a variable. Also, this continues to work for immediate number-crunching without using variables at all.
In other situations, it might be convenient to attach preferred output formats to variables. If both were defined, preferred formats for variables should certainly override preferred formats for units.

Greetings,

Matthias

[matthiaspaul]

(10-23-2015 10:04 PM)Helix Wrote:  Other remarks:
- EEX should show e instead of E, to be consistent with the symbol used in the stack.

Hm, then perhaps it would be better to change the symbol used in the stack to "E", as "e" is easily confused with the e number, and using uppercase letters for the decimal scientific notation is far more common than using lowercase letters.

Also, this could help to avoid potential confusion with an extension I am slowly (due to lack of time) working on for the WP 34s, and which, I think, would also be great to have in the Prime and newRPL:

Similar to the E notation denoting "*10^", there is an old informal convention to denote "*2^" using an uppercase "B" instead of the "E" (e.g. 1024 = 1.024E3 = 1.000B10 or 1000 = 1.000E3 = 0.9765625B10). Problem is that a lowercase "b" is also often used to denote a binary number.

(There's a newer standard convention to denote "*2^" using "P" (in C99 and IEEE 754-2008), but for length reasons it assumes the mantissa to be shown in hex, whereas "B" assumes decimal unless a different base is indicated specifically or known from context. Both, "B" and "P", assume the exponent to be shown in decimal unless otherwise noted. Using "P" instead of "B" would completely avoid any potential confusion with "b" for binary, but I'm not sure it would justify the violation of a standard by introducing a usage of "P" with decimal mantissas, even if such a usage may be obvious for a user from context.)

Anyway, for these reasons it might make sense to display an uppercase "E" for "*10^".

Greetings,

Matthias

[Helix]

(10-23-2015 12:48 AM)Claudio L. Wrote:  

(10-22-2015 08:59 PM)matthiaspaul Wrote:  Are there some easy (interactive and programmatical) means to declare an approximated number as exact again?

Greetings,

Matthias

Good point.
I didn't really think about it, but I believe they will become necessary. You could calculate something approximate, round to 4 digits for example, and then want to treat that number as an exact constant for input to an expression.
I'm thinking A→E and E→A could be good candidates (exact to approx and viceversa). But perhaps it should just be →EXACT and →APPROX.

I have a preference for →EXACT and →APPROX, because these names are intelligible.

(10-23-2015 12:48 AM)Claudio L. Wrote:  These commands should work not only on commands, but on identifiers too once the trailing dot is extended to mean "identifiers to be evaluated immediately". Perhaps the names should be different, since "exact" and "approx" don't really apply to the identifiers.
Any ideas for more generic names?

I'm not sure I undestand what you mean. An identifier without quotes is evaluated immediately. Could you give a short example of what you think?

[Helix]

(10-24-2015 06:02 PM)matthiaspaul Wrote:  Also, this could help to avoid potential confusion with an extension I am slowly (due to lack of time) working on for the WP 34s, and which, I think, would also be great to have in the Prime and newRPL:

Similar to the E notation denoting "*10^", there is an old informal convention to denote "*2^" using an uppercase "B" instead of the "E" (e.g. 1024 = 1.024E3 = 1.000B10 or 1000 = 1.000E3 = 0.9765625B10). Problem is that a lowercase "b" is also often used to denote a binary number.

It's an interesting idea!
Since it's an informal convention, there would be no problem with the letter b in my opinion. I can't see confusion with binary numbers, because they have the # prefix (at least in RPL, I don't know the WP34s)
Of course, the E symbol is perfectly valid too, and more common than e indeed. I have no preference here.

[Claudio L.]

(10-24-2015 08:30 PM)Helix Wrote:  

(10-23-2015 12:48 AM)Claudio L. Wrote:  These commands should work not only on commands, but on identifiers too once the trailing dot is extended to mean "identifiers to be evaluated immediately". Perhaps the names should be different, since "exact" and "approx" don't really apply to the identifiers.
Any ideas for more generic names?

I'm not sure I undestand what you mean. An identifier without quotes is evaluated immediately. Could you give a short example of what you think?

Yes, but the quotes work only when the identifier is by itself, not inside an expression. The idea is that 'X.+2' evaluates X immediately, because the user "requested" it by adding the trailing dot.
There should be a command to make certain variables in an expression evaluate, perhaps:
'X^2+Y' 'Y' ->EVALNOW would produce the expression 'X^2+Y.' which would cause Y to be evaluated immediately next time the expressions is executed or operated upon. If Y is 4, then:

'X^2+Y' 1 + --> 'X^2+Y+1'
'X^2+Y.' 1 + --> 'X^2+5'

In the second case, only the Y was evaluated automatically, X will not be evaluated unless EVAL is called on the expression.

What I meant is that the name ->APPROX doesn't really work for variables, should be something like the EVALNOW above.

[Han]

(10-25-2015 01:52 AM)Claudio L. Wrote:  

(10-24-2015 08:30 PM)Helix Wrote:  I'm not sure I undestand what you mean. An identifier without quotes is evaluated immediately. Could you give a short example of what you think?

Yes, but the quotes work only when the identifier is by itself, not inside an expression. The idea is that 'X.+2' evaluates X immediately, because the user "requested" it by adding the trailing dot.
There should be a command to make certain variables in an expression evaluate, perhaps:
'X^2+Y' 'Y' ->EVALNOW would produce the expression 'X^2+Y.' which would cause Y to be evaluated immediately next time the expressions is executed or operated upon. If Y is 4, then:

'X^2+Y' 1 + --> 'X^2+Y+1'
'X^2+Y.' 1 + --> 'X^2+5'

In the second case, only the Y was evaluated automatically, X will not be evaluated unless EVAL is called on the expression.

What I meant is that the name ->APPROX doesn't really work for variables, should be something like the EVALNOW above.

While I think the "dot" notation is nice for immediate evaluation, it really seems to be contrary to the whole notion of RPN.

'X^2+Y' 1 + --> 'X' SQ 'Y' + 1 +
'X^2+Y.' 1 + --> 'X' SQ Y + 1 +

But even with the feature, I am not sure it would be used as described. If I wanted immediate substitution, I imagine that I would still end up double checking the value of Y prior to having the calculator actually include it into a formula. So a quick RCL of the contents of Y would most likely occur -- and at this point I may as well just build my formula with the Y value already on the stack.

[Claudio L.]

(10-25-2015 11:31 AM)Han Wrote:  While I think the "dot" notation is nice for immediate evaluation, it really seems to be contrary to the whole notion of RPN.

'X^2+Y' 1 + --> 'X' SQ 'Y' + 1 +
'X^2+Y.' 1 + --> 'X' SQ Y + 1 +

This is exactly right, but I fail to see why it's contrary to RPN (??). All you are telling the machine is that you want the value of Y replaced ASAP.
I think for instance of a quadratic solver.
You have the generic equation:
'a.*X^2+b.*X+c.' stored somewhere

Then the user defines 'a', 'b' and 'c' to his liking.
Next time you operate on that expression, all 3 values will be immediately replaced, but not X, so you can display the final equation even if X has a value. Doing EVAL would also replace the X if it has any value. This way you control what gets replaced in the expression.
Currently, you'd need to make sure X doesn't exist in current or higher directories to get the equation.

(10-25-2015 11:31 AM)Han Wrote:  But even with the feature, I am not sure it would be used as described. If I wanted immediate substitution, I imagine that I would still end up double checking the value of Y prior to having the calculator actually include it into a formula. So a quick RCL of the contents of Y would most likely occur -- and at this point I may as well just build my formula with the Y value already on the stack.

Ah, but you are thinking interactively only. The dot in the expression is most useful when executed inside a program, since the mere presence of the symbolic in the runstream would trigger the replacement. Without the dot, you'd have to break down the expression in the program so you can evaluate the different parts and then reconstruct the symbolic.

Think of my example above:
Currently:
<< a 'X^2' * b 'X' * + c + >>
Proposed:
<< 'a.*X^2+b.*X+c.' >>

They produce the same result.

[Claudio L.]

(10-23-2015 10:04 PM)Helix Wrote:  ALPHA mode:
- it is easy to use now, and I can say it is intuitive for me.
- I think that ENTRY works now as it should work in program mode. In algebraic mode, I think that some keys should remain active, for example the HIST key (or the STO key depending of the settings for the menus). This would permit to create a variable A with the sequence:
' ALPHA A ' ' HIST (or ' ALPHA+A HIST) instead of ' ALPHA A ENTER HIST

This is no different from the 50g. Once you are in alpha mode, STO, HIST, etc. they all have letters, so I don't know how we could keep it active.
Alpha-hold+A then HIST does what you are looking for.

(10-23-2015 10:04 PM)Helix Wrote:  Multi-line editor:
- inserting the carriage return character inside a line shifts the cursor at an unpredictable place (end of the new line, beginning of the following line, or somewhere in the new line). It should be placed at the beginning of the new line.

Fixed this and also the fact that backspace wasn't deleting the newline. It will all come out in the next update.

(10-23-2015 10:04 PM)Helix Wrote:  - The down arrow key doesn't open the multi-line editor (probably not yet implemented…)

Not implemented, I need some code beautifier to break down objects in multiple lines, with proper indentation.

(10-23-2015 10:04 PM)Helix Wrote:  Autocomplete function:
- a lot of commands are missing
- they are arranged in an arbitrary order. Because of these two (temporary?) drawbacks, the autocomplete function is useless for me.

Only commands that are currently declared by libraries are shown (about 150 now declared, some 120 implemented). Autocomplete asks each library to propose suggestions. So commands are in "library order". Sorting would need a lot of memory.

(10-23-2015 10:04 PM)Helix Wrote:  - if a complete list of commands can be displayed in alphabetic order, I imagine a long press on the arrow keys could scroll the list of commands.
- It would be nice also to have access to names beginning with a special character, for example <-HMS. Perhaps it should appear among names beginning by the letter H?
- If ON is pressed to quit the line editor, the suggested command remains in the status area. For example, R ON leaves ROT (If I remember correctly).

Autocomplete is quite simple and only tries to save you keystrokes, it's not a heuristic search engine. For instance, I found it very useful when I was doing some unit conversions the other day, just type CON and Alpha+Right will complete "CONVERT".
It's not intended as a replacement for a catalog. If you want a catalog where you can search for a command, that's a different feature, which will likely exist at some point.

(10-23-2015 10:04 PM)Helix Wrote:  Other remarks:
- EEX should show e instead of E, to be consistent with the symbol used in the stack.
- 'A/2.' ENTER EVAL returns A

True, the symbol E or e is actually a configurable setting. The EEX keyboard handler doesn't use the current system configuration, is hardcoded to 'E' for now but has to be fixed.
I'll have to investigate the other bug, I think it's a bug in the numeric simplification routine.

Thanks for the bug reports!

[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

[matthiaspaul]

(10-23-2015 01:13 AM)Han Wrote:  

(10-23-2015 01:05 AM)Claudio L. Wrote:  That could work as far as symbols. However, Enter has ANS and →NUM, are you suggesting we relocate those? ANS might not be needed on a full RPL machine but I'm concerned about relocating →NUM.
EDIT: Perhaps only ANS should be replaced with a toggle function, if it's exact goes approx and vice versa.

Well, I was thinking ease of programming by having the two symbols accessible via the keyboard (rather than via a character catalogue). If we want to keep as much of the old keyboard layout as possible, perhaps →E and →A would suffice, and Ans can toggle. I prefer the unix style of naming commands -- use as few characters as possible :-)

On the 48GX, 50g and Prime, pressing . followed by ENTER gives a syntax error. If this would hold true for newRPL as well (sorry, I still haven't found the time to try it "live"), it might be an intuitive hotkey for a toggle. Pressing . multiple times before ENTER has the same effect - just in case, we'd need more than a toggle.

(On the other hand, many other calculators take a single . as 0., or the hotkey might be more useful to be reserved for other special stuff (fractions input?).)

Greetings,

Matthias

[Claudio L.]

(10-25-2015 10:46 PM)matthiaspaul Wrote:  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 _∠ .

That shouldn't be a problem: →∠ is available instead of ANGUNIT. Remember, longer to type won't be that much of a problem with the new Autocomplete function.

(10-25-2015 10:46 PM)matthiaspaul Wrote:  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.

I don't see this as a big deal. If you want to attach units you'd use ASIN →∠ immediately, this is not a multitasking environment where the flags could change in the background.

(10-25-2015 10:46 PM)matthiaspaul Wrote:  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?

I work mainly in radians, and angles, while treated as a physical magnitude for unit purposes, it's actually a non-dimensional quantity by definition (arc_length/radius), so even when I'm working with units, my angles are always unit-less.
Angular velocity is 1/s (or r/s if you use angular units), and multiplied by a distance is supposed to be m/s, not m*r/s.
So I'm not a fan of adding units by default, as angles work best when unit-less in my opinion.

[Claudio L.]

(10-23-2015 10:04 PM)Helix Wrote:  - It would be nice also to have access to names beginning with a special character, for example <-HMS. Perhaps it should appear among names beginning by the letter H?

FYI, I just implemented this feature, I think it's a nice addition, as typing LIST for example will let you access the commands for sum, product, etc. that have "hard to find" characters at the beginning of the command.