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

[Claudio L.]

(10-01-2015 11:25 PM)Han Wrote:  Can't wait to try this. Quick question: does this release have a usable "OFF" command? Or will we have to remove batteries if we want to turn it off?

Not yet, sorry. Things that deal with hardware are slower to achieve because the trial and error cycle involves flashing the calc every time and watching it crash with no feedback at all. On the other hand, other features can be developed and tested much more quickly on the simulator.

[matthiaspaul]

Unfortunately, I haven't found any time to test newRPL so far, but I'm following the discussions for quite some while with interest and are delighted to find several of the remaining limitations of RPL already addressed in newRPL. Four comments regarding how to possibly further improve the units implementation:

- For regression and stress testing against the HP 48 or HP 50 implementation or to allow deliberately working with a particular CODATA set - f.e. (in the long run) in contractual engineering work, in exams, or when working with old or future literature, it might be useful to have the option to switch the CODATA definitions. While for developers this could be a compile-time option, a special newRPL specific command to flip the complete set of definitions at runtime might be a better solution for users. Something like 2014 CODATA Enter, 1998 CODATA Enter, perhaps?

- The 50g and Prime do not define the same set of predefined units. Wouldn't it be useful to add the units defined by the Prime to newRPL as well to make switching between different calculators and implementations easier and to improve the level of "future" compatibility somewhat?

- AFAIK newRPL already supports SI decimal prefixes, doesn't it? What about IEC binary prefixes, which are becoming more and more important?

Ki: 2^10 or 1024^1
Mi: 2^20 or 1024^2
Gi: 2^30 or 1024^3
Ti: 2^40 or 1024^4
Pi: 2^50 or 1024^5
Ei: 2^60 or 1024^6
Zi: 2^70 or 1024^7
Yi: 2^80 or 1024^8

- According to the newRPL status list, switching between DEG, RAD and GRAD angular modes isn't implemented yet (BTW perhaps adding a TURN mode as well to the ToDo list?), so the use for the following is still limited at present: But since this thread is about units, what about automatically appending the angular unit of the currently selected angular mode so that 1 ASIN Enter would result in 90_° in DEG mode, 100_gon in GRAD mode, or 1.570..._rad in RAD mode (and 0.25_tr in TURN mode) etc. This way, angular values on the stack or in variables would remain usable beyond global angular mode switches without a need for conversion.

Keep up the great work!

Greetings,

Matthias

[Claudio L.]

(10-03-2015 01:22 PM)matthiaspaul Wrote:  Unfortunately, I haven't found any time to test newRPL so far, but I'm following the discussions for quite some while with interest and are delighted to find several of the remaining limitations of RPL already addressed in newRPL.
Four comments regarding how to possibly further improve the units implementation:

- For regression and stress testing against the HP 48 or HP 50 implementation or to allow deliberately working with a particular CODATA set - f.e. (in the long run) in contractual engineering work, in exams, or when working with old or future literature, it might be useful to have the option to switch the CODATA definitions. While for developers this could be a compile-time option, a special newRPL specific command to flip the complete set of definitions at runtime might be a better solution for users. Something like 2014 CODATA Enter, 1998 CODATA Enter, perhaps?

I think it's a great suggestion, but perhaps not for the core system.
In newRPL you always have the option: the system looks for user-defined units first, then system defined, so if you want to work with a certain unit and don't like the system definition, just override it by using the UDEFINE command (which I just finished implementing).
You can go back to the system definition with UPURGE to purge the newly defined unit.
I think third party developers can create "unit packs" and publish them, that would override the units with older (or newer) CODATA values. The command 2014 CODATA you proposed could very well be the main command of such unit pack.
In the more than 100 units supported, I think there's only 3 or 4 that use approximated values by CODATA, the rest are exact numbers. The trend is now to redefine the units in terms of physical constants, so more and more physical constants become "fixed" because the unit is defined based on that (like speed of light for example).

(10-03-2015 01:22 PM)matthiaspaul Wrote:  - The 50g and Prime do not define the same set of predefined units. Wouldn't it be useful to add the units defined by the Prime to newRPL as well to make switching between different calculators and implementations easier and to improve the level of "future" compatibility somewhat?

I haven't seen any docs like the AUR listing all the units supported by the Prime, with their definitions. Do you have any pointers for me? (I don't own a Prime).

(10-03-2015 01:22 PM)matthiaspaul Wrote:  - AFAIK newRPL already supports SI decimal prefixes, doesn't it? What about IEC binary prefixes, which are becoming more and more important?

Ki: 2^10 or 1024^1
Mi: 2^20 or 1024^2
Gi: 2^30 or 1024^3
Ti: 2^40 or 1024^4
Pi: 2^50 or 1024^5
Ei: 2^60 or 1024^6
Zi: 2^70 or 1024^7
Yi: 2^80 or 1024^8

newRPL allows you to to define for example:
8_bit 'B' UDEFINE --> This will define B (byte) as 8 bits, and don't allow automatic SI units
or, you might prefer the byte to be the base unit:
1 'B' UDEFINE
if you want the new unit to accept all SI prefixes:
1 '?B' UDEFINE ---> will do just that.

Problem is, for bytes it doesn't make a lot of sense to have 1_µB, so it's probably best if byte is defined without SI prefixes, then kB or KiB are each defined separately.

(10-03-2015 01:22 PM)matthiaspaul Wrote:  - According to the newRPL status list, switching between DEG, RAD and GRAD angular modes isn't implemented yet

Which reminds me, I haven't updated that list in quite a long time. The commands are implemented now, but the way SIN/COS/TAN use the mode is still in question, so I didn't do that yet.
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.
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.
This would eliminate the annoying "The calculator needs to switch to radians mode, OK?", as the CAS would know which unit you intend to use.

(10-03-2015 01:22 PM)matthiaspaul Wrote:  (BTW perhaps adding a TURN mode as well to the ToDo list?)

What is a TURN mode? An angular unit where 1 unit = 2*pi radians?

(10-03-2015 01:22 PM)matthiaspaul Wrote:  But since this thread is about units, what about automatically appending the angular unit of the currently selected angular mode so that 1 ASIN Enter would result in 90_° in DEG mode, 100_gon in GRAD mode, or 1.570..._rad in RAD mode (and 0.25_tr in TURN mode) etc. This way, angular values on the stack or in variables would remain usable beyond global angular mode switches without a need for conversion.

This is another possible solution to the same problem of commands returning values based on flags.

[Helix]

Some initial comments :
- the variable menu is much better now.
- the short program << 2 _m >> works as expected, but on the stack it shows << 2 1_m_[ INVALID_COMMAND
- I was about to ask the question, but I've discovered how to enter the Δ and ° characters to test the temperature units : left shift 9 and left shift 6 respectively, in alpha mode. I don't know if this has been already explained somewhere. Are they temporary key combinations?

20_°C
1_°F
CONVERT
Returns 254.52._°F instead of 68_°F…

[matthiaspaul]

(10-03-2015 06:15 PM)Claudio L. Wrote:  

(10-03-2015 01:22 PM)matthiaspaul Wrote:  - For regression and stress testing against the HP 48 or HP 50 implementation or to allow deliberately working with a particular CODATA set [...]

I think it's a great suggestion, but perhaps not for the core system.
[...]
I think third party developers can create "unit packs" and publish them, that would override the units with older (or newer) CODATA values. The command 2014 CODATA you proposed could very well be the main command of such unit pack.

This sounds like a perfect solution in my opinion. It even ensures "future compatibility", which is important as there seem to be several changes ahead in the next couple of years.

(10-03-2015 06:15 PM)Claudio L. Wrote:  

(10-03-2015 01:22 PM)matthiaspaul Wrote:  - The 50g and Prime do not define the same set of predefined units. Wouldn't it be useful to add the units defined by the Prime to newRPL as well to make switching between different calculators and implementations easier and to improve the level of "future" compatibility somewhat?

I haven't seen any docs like the AUR listing all the units supported by the Prime, with their definitions. Do you have any pointers for me? (I don't own a Prime).

Like you, I could not find a list of supported units in the Prime's manuals (only a list of physical constants), but if you like the idea of adding the "missing" units, a list could be derived manually by us.

(10-03-2015 06:15 PM)Claudio L. Wrote:  

(10-03-2015 01:22 PM)matthiaspaul Wrote:  (BTW perhaps adding a TURN mode as well to the ToDo list?)

What is a TURN mode? An angular unit where 1 unit = 2*pi radians?

Yes, exactly. In TURN mode, ASIN(1) results in 0.25, just like it results in 90 in DEG mode, 100 in GRAD mode or 1.57... in RAD mode. The basic idea behind it is that if the source or target representation isn't in any of the three traditional units in some kind of technical solution, why not work with a "neutral" unit (full circle = 1 turn)? Saves a step in ad-hoc conversions. I had implemented this in a software calculator a long time ago and found it to be intuitive and quite useful in practise. See:

http://www.hpmuseum.org/forum/thread-449...l#pid40343

Greetings,

Matthias

[Claudio L.]

(10-03-2015 07:14 PM)Helix Wrote:  Some initial comments :
- the variable menu is much better now.

Glad it looks better for you.

(10-03-2015 07:14 PM)Helix Wrote:  - the short program << 2 _m >> works as expected, but on the stack it shows << 2 1_m_[ INVALID_COMMAND

Fixed.

(10-03-2015 07:14 PM)Helix Wrote:  - I was about to ask the question, but I've discovered how to enter the Δ and ° characters to test the temperature units : left shift 9 and left shift 6 respectively, in alpha mode. I don't know if this has been already explained somewhere. Are they temporary key combinations?

I forgot to mention: the degree is where it's always been, I figured for now I needed the Delta to be close, and number 9 key was not used in the 50g, so why not. Delta is actually in the B or C (don't remember), but I didn't add all the greek letters yet. I actually like it in the 9, but at this point I don't know if it's temporary or not. I think delta is like the Sum symbol, it's much more often used than other greek letters so it should be readily accessible.

(10-03-2015 07:14 PM)Helix Wrote:  20_°C
1_°F
CONVERT
Returns 254.52._°F instead of 68_°F…

Ouch, I broke CONVERT when fixing addition, it's fixed now.

Thanks for the bug hunt, it was very useful. I'll probably upload a new firmware image at the end of the weekend with these bugs fixed.

[Claudio L.]

(10-03-2015 11:08 PM)matthiaspaul Wrote:  Like you, I could not find a list of supported units in the Prime's manuals (only a list of physical constants), but if you like the idea of adding the "missing" units, a list could be derived manually by us.

I don't have any problem adding more units. If you or somebody wants to prepare a list I'll be happy to add them.
They could also become an external "Prime unit pack", and define for instance the "inch" unit that caused some headaches.

(10-03-2015 11:08 PM)matthiaspaul Wrote:  

(10-03-2015 06:15 PM)Claudio L. Wrote:  What is a TURN mode? An angular unit where 1 unit = 2*pi radians?

Yes, exactly. In TURN mode, ASIN(1) results in 0.25, just like it results in 90 in DEG mode, 100 in GRAD mode or 1.57... in RAD mode. The basic idea behind it is that if the source or target representation isn't in any of the three traditional units in some kind of technical solution, why not work with a "neutral" unit (full circle = 1 turn)? Saves a step in ad-hoc conversions. I had implemented this in a software calculator a long time ago and found it to be intuitive and quite useful in practise. See:

http://www.hpmuseum.org/forum/thread-449...l#pid40343

Greetings,

Matthias

Interesting read. I tend to agree, but it's not common practice by any means. I'll have to think about it some more before adding it. I want to be very cautions about unnecessary "feature creep" at this early stage, because I might run out of ROM space before finishing the important stuff. If there's space in ROM when everything else is finished, then minor things like this are easy to add.

[Helix]

(10-01-2015 11:04 PM)Claudio L. Wrote:  *Temperatures work as described in a recent thread.

I've played a bit with the temperature units, and I think it's a nice improvement.
For example sometimes I read English texts in which the author says for example that at the beginning the ambient temperature was 68°F, then after a drop of 12°F he observed [A], after another drop of 9°F he observed [B], and so on. All these conversions in °C are boring to do…
With newRPL there is only one conversion to do: 70_°F gives 20_°C
Then it's straightforward:
12_Δ°F - gives 13.33_°C
9_Δ°F - gives 8.33_°C, and so on.
I like that feature a lot!

(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.
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.
This would eliminate the annoying "The calculator needs to switch to radians mode, OK?", as the CAS would know which unit you intend to use.

I don't know yet if this is a good idea. Existing programs for the HP50g with trigonometric functions inside will have to be entirely edited to be used with newRPL. Also, I'm afraid that function names like SIN COS TAN are so natural that it will be very easy to make errors in writing or editing programs…
However, if you implement this feature, I think I would prefer command names like SIND, SING, instead of DSIN, GSIN…

[Claudio L.]

(10-04-2015 09:57 PM)Helix Wrote:  I don't know yet if this is a good idea. Existing programs for the HP50g with trigonometric functions inside will have to be entirely edited to be used with newRPL. Also, I'm afraid that function names like SIN COS TAN are so natural that it will be very easy to make errors in writing or editing programs…

The idea is that if you are writing or editing a program let's say in DEG mode, the SIN key will not only compute SIND, but also type SIND in your program and SIND() in your algebraic expressions, this makes it clear it's in degrees.
But yes, it breaks compatibility with any existing code using a mode other than radians. On the other hand, CAS programs are always forcing the radians mode on you, so those will not be affected. Non-CAS programs will be using SIN, so not affected either.
One advantage is that in CAS programs, by having a different name, the derivative of SIND for example, could automatically be PI/180*COSD(u)*u', no mode change needed.
I don't know, I'm still debating myself if this is really "better", hence is still not implemented. Perhaps more comments from people can help clear this out.

(10-04-2015 09:57 PM)Helix Wrote:  However, if you implement this feature, I think I would prefer command names like SIND, SING, instead of DSIN, GSIN…

Now that you mention, I prefer SIND too (so I started using it above already).

[Han]

(10-05-2015 12:11 PM)Claudio L. Wrote:  

(10-04-2015 09:57 PM)Helix Wrote:  I don't know yet if this is a good idea. Existing programs for the HP50g with trigonometric functions inside will have to be entirely edited to be used with newRPL. Also, I'm afraid that function names like SIN COS TAN are so natural that it will be very easy to make errors in writing or editing programs…

The idea is that if you are writing or editing a program let's say in DEG mode, the SIN key will not only compute SIND, but also type SIND in your program and SIND() in your algebraic expressions, this makes it clear it's in degrees.
But yes, it breaks compatibility with any existing code using a mode other than radians. On the other hand, CAS programs are always forcing the radians mode on you, so those will not be affected. Non-CAS programs will be using SIN, so not affected either.
One advantage is that in CAS programs, by having a different name, the derivative of SIND for example, could automatically be PI/180*COSD(u)*u', no mode change needed.
I don't know, I'm still debating myself if this is really "better", hence is still not implemented. Perhaps more comments from people can help clear this out.

(10-04-2015 09:57 PM)Helix Wrote:  However, if you implement this feature, I think I would prefer command names like SIND, SING, instead of DSIN, GSIN…

Now that you mention, I prefer SIND too (so I started using it above already).

Sometimes less is more. I find that after some point, having too many commands becomes cumbersome. We have units, including ° should we want degrees. The trig functions should always assume radians (in my opinion) or at the very most depend on the angle mode. Users who wish to explicitly use an angle measure that is invariant under angle mode should specify the units. A custom key can be set up to quickly add the appropriate units. In programs, the explicit unit only needs to be appended once as subsequent operations would inherit the initial unit.

EDIT: My proposal also does away with the derivative issue; e.g. the derivative of SIN(X) will always be COS(X) since the trig functions should presumably know how to auto-adjust for inputs that are properly tagged with units of angle measure (and assume radians otherwise).

[Helix]

(10-05-2015 12:11 PM)Claudio L. Wrote:  The idea is that if you are writing or editing a program let's say in DEG mode, the SIN key will not only compute SIND, but also type SIND in your program and SIND() in your algebraic expressions, this makes it clear it's in degrees.
But yes, it breaks compatibility with any existing code using a mode other than radians. On the other hand, CAS programs are always forcing the radians mode on you, so those will not be affected. Non-CAS programs will be using SIN, so not affected either.
One advantage is that in CAS programs, by having a different name, the derivative of SIND for example, could automatically be PI/180*COSD(u)*u', no mode change needed.

I see, and it's better than what I thought. Furthermore, I seldom use the CAS.

(10-05-2015 12:11 PM)Claudio L. Wrote:  I don't know, I'm still debating myself if this is really "better", hence is still not implemented. Perhaps more comments from people can help clear this out.

Maybe you could open a new thread for trig functions, in order to get more opinions.

[Claudio L.]

(10-05-2015 02:05 PM)Han Wrote:  Sometimes less is more. I find that after some point, having too many commands becomes cumbersome. We have units, including ° should we want degrees. The trig functions should always assume radians (in my opinion) or at the very most depend on the angle mode. Users who wish to explicitly use an angle measure that is invariant under angle mode should specify the units. A custom key can be set up to quickly add the appropriate units. In programs, the explicit unit only needs to be appended once as subsequent operations would inherit the initial unit.

Well, SIN will only accept radians, but if there's units, it has to use the units given. In that aspect your proposal is identical to mine. Mine just builds on top of that, adding the SIND and SING commands.
The problem with using units alone, is how to specify the units for the inverse functions.
ASIN(1) = ???
We'd have to provide a second argument with the units, and those functions have traditionally needed one argument. Or, we are back to square one, with a system-wide flag.

(10-05-2015 02:05 PM)Han Wrote:  EDIT: My proposal also does away with the derivative issue; e.g. the derivative of SIN(X) will always be COS(X) since the trig functions should presumably know how to auto-adjust for inputs that are properly tagged with units of angle measure (and assume radians otherwise).

I'm not so sure that's right.
If you use degrees, for example, SIN(r) = SIN(pi/180*x), and it's derivative is pi/180*COS(pi/180*x) = pi/180* COS(r), so you need that constant if you provide 'r' with a units of degree.
In a CAS expression, you don't know the units of r until you evaluate it, so you can't "fix" the derivative based on that. That's why the 50g CAS forces radians mode, but using SIND the parser knows all the time that the argument will come in degrees, and can produce the correct output.

BTW: I updated the ROM image with the bugs described by Helix fixed, and I also added the UFACT command.

[Claudio L.]

(10-04-2015 09:57 PM)Helix Wrote:  I've played a bit with the temperature units, and I think it's a nice improvement.
For example sometimes I read English texts in which the author says for example that at the beginning the ambient temperature was 68°F, then after a drop of 12°F he observed [A], after another drop of 9°F he observed [B], and so on. All these conversions in °C are boring to do…
With newRPL there is only one conversion to do: 70_°F gives 20_°C
Then it's straightforward:
12_Δ°F - gives 13.33_°C
9_Δ°F - gives 8.33_°C, and so on.
I like that feature a lot!

There's a couple other improvements that are cool too:
{ 1 2 3 } _m/s --> { 1_m/s 2_m/s 3_m/s }
[ 1 2 3]_m
also [ 1 2 3 ] _m
vectors and matrices with units are useful for analytic mechanics, where the vectors are actual distances, forces, angular velocities, etc.
Complex numbers aren't directly allowed as (0,1)_m is a syntax error for now (it will likely stay that way). However, you can still apply a unit to a complex:
(0,1) _m --> (0,1)_m
I don't have any physical meaning or use for this, but it's allowed and operations will proceed as usual (thanks to newRPL's use of overloaded operators, many objects can have units without much trouble).

[Han]

(10-06-2015 02:54 AM)Claudio L. Wrote:  

(10-05-2015 02:05 PM)Han Wrote:  Sometimes less is more. I find that after some point, having too many commands becomes cumbersome. We have units, including ° should we want degrees. The trig functions should always assume radians (in my opinion) or at the very most depend on the angle mode. Users who wish to explicitly use an angle measure that is invariant under angle mode should specify the units. A custom key can be set up to quickly add the appropriate units. In programs, the explicit unit only needs to be appended once as subsequent operations would inherit the initial unit.

Well, SIN will only accept radians, but if there's units, it has to use the units given. In that aspect your proposal is identical to mine. Mine just builds on top of that, adding the SIND and SING commands.
The problem with using units alone, is how to specify the units for the inverse functions.
ASIN(1) = ???
We'd have to provide a second argument with the units, and those functions have traditionally needed one argument. Or, we are back to square one, with a system-wide flag.

(10-05-2015 02:05 PM)Han Wrote:  EDIT: My proposal also does away with the derivative issue; e.g. the derivative of SIN(X) will always be COS(X) since the trig functions should presumably know how to auto-adjust for inputs that are properly tagged with units of angle measure (and assume radians otherwise).

I'm not so sure that's right.
If you use degrees, for example, SIN(r) = SIN(pi/180*x), and it's derivative is pi/180*COS(pi/180*x) = pi/180* COS(r), so you need that constant if you provide 'r' with a units of degree.
In a CAS expression, you don't know the units of r until you evaluate it, so you can't "fix" the derivative based on that. That's why the 50g CAS forces radians mode, but using SIND the parser knows all the time that the argument will come in degrees, and can produce the correct output.

BTW: I updated the ROM image with the bugs described by Helix fixed, and I also added the UFACT command.

You are quite right; I had not thought it through carefully.

[Han]

Some observations:

On the HP48, typing: 2XY would result in 2 and 'XY' but newRPL throws an error.

The pi symbol followed by ->NUM gives an error as it treats pi as an identifier and not constant. Is this because constants are not implemented yet? This naturally leads to questions on whether e and i will be allowed as identifiers, or if they will be reserved names.

[matthiaspaul]

(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

[Helix]

This time I've had difficulties in flashing the calculator with the last rom. I've tried two times, and the screen remained blank, with only the flashing transfer indicator. I've tried resetting with a paperclip, removing a battery, but nothing happened. The On-A-C procedure was available, but again, the right shift – left shift – clear mem (or reset) did not work, the screen was still blank, with the flashing indicator.

So I decided to return to the previous rom, and when I put again the battery for flashing the calculator, I saw a screen saying that the memory will be wiped, with a "cont" button, as it occurred often (but not always) with the previous rom. Now the calculator runs correctly with the new rom.
It seems that removing a battery produces some random behaviors…


About trig functions, I wonder if we are not doing some hair-spitting here. I am very satisfied with the current RPL. It's easy to insert DEG or RAD at the beginning of a program, and after some thought, I believe that in algebraic expressions I won't be very pleased with things like 'ASIND(COSD(A)+SIND(B))' instead of 'ASIN(COS(A)+SIN(B))'.

Other comments :

The new features of units are cool indeed, as well as the functions UDEFINE and UPURGE!

Is there a difference between 1. and 1? I think that 1. ENTER should give 1 on the stack.

-1 ENTER √x doesn't work (maybe it depends on flags).

In algebraic or program mode, the +/- key adds – or NEG after a number, instead of changing its sign.

[Claudio L.]

(10-07-2015 12:21 AM)Helix Wrote:  This time I've had difficulties in flashing the calculator with the last rom. I've tried two times, and the screen remained blank, with only the flashing transfer indicator. I've tried resetting with a paperclip, removing a battery, but nothing happened. The On-A-C procedure was available, but again, the right shift – left shift – clear mem (or reset) did not work, the screen was still blank, with the flashing indicator.

So I decided to return to the previous rom, and when I put again the battery for flashing the calculator, I saw a screen saying that the memory will be wiped, with a "cont" button, as it occurred often (but not always) with the previous rom. Now the calculator runs correctly with the new rom.
It seems that removing a battery produces some random behaviors…

I never had anything like that happen, but it seems that your memory got corrupted. If the calculator offered to wipe the memory, is because the firmware failed to detect the necessary variables in memory to start the core. Perhaps some discharge when pulling the battery crashed the CPU and corrupted your RAM, or perhaps your backup battery is weak and couldn't sustain the data.

(10-07-2015 12:21 AM)Helix Wrote:  About trig functions, I wonder if we are not doing some hair-spitting here. I am very satisfied with the current RPL. It's easy to insert DEG or RAD at the beginning of a program, and after some thought, I believe that in algebraic expressions I won't be very pleased with things like 'ASIND(COSD(A)+SIND(B))' instead of 'ASIN(COS(A)+SIN(B))'.

Perhaps, maybe I'll put the issue to sleep and keep the status quo. I'll probably implement the functions using the flags as it used to be.

(10-07-2015 12:21 AM)Helix Wrote:  Is there a difference between 1. and 1? I think that 1. ENTER should give 1 on the stack.

Yes, 1. is an approximated number, 1 is exact. Big difference in symbolics: exact numbers want to stay exact, while approx. numbers don't care.
'1/2' EVAL --> '1/2'
'1./2' EVAL --> 0.5.

(10-07-2015 12:21 AM)Helix Wrote:  -1 ENTER √x doesn't work (maybe it depends on flags).

None of the transcendental functions return complex results yet, or accept complex arguments. Complex mode is quite incomplete right now. Just compiling the objects and the 4 basic operators, nothing else.
Yes, it will depend on flags, but the flag in question is not yet implemented also.
This is also open for the same discussion as the trig functions, do we want these functions to return different values based on flags? While I came up with SIND, etc. for trig, I couldn't come up with something coherent for XROOT for example. XROOT(-8,3) could return an error (when not in complex mode), or the real root, or the principal root, but how to organize it without using system-level flags?

(10-07-2015 12:21 AM)Helix Wrote:  In algebraic or program mode, the +/- key adds – or NEG after a number, instead of changing its sign.

That's laziness on my part. No excuse, I'll implement that properly.

[Claudio L.]

(10-06-2015 07:15 PM)Han Wrote:  Some observations:

On the HP48, typing: 2XY would result in 2 and 'XY' but newRPL throws an error.

Yes, this is by design, but I could implement it relatively easily (designs can change).

(10-06-2015 07:15 PM)Han Wrote:  The pi symbol followed by ->NUM gives an error as it treats pi as an identifier and not constant. Is this because constants are not implemented yet? This naturally leads to questions on whether e and i will be allowed as identifiers, or if they will be reserved names.

There's no constants yet. Complex i and j should be implemented using Unicode U+2148 and U+2149 respectively. This way they will look different on the screen and don't get mixed with identifiers. I haven't found a good symbol for 'e' yet.

[matthiaspaul]

(10-07-2015 02:49 AM)Claudio L. Wrote:  I haven't found a good symbol for 'e' yet.

Perhaps U+212F "SCRIPT SMALL E" (or U+2147 "DOUBLE-STRUCK ITALIC SMALL E")?

Greetings,

Matthias