Post Reply 
newRPL: [UPDATED April 27-2017] Firmware for testing available for download
10-03-2015, 06:15 PM
Post: #43
RE: newRPL: [UPDATED Oct-01-2015] Firmware for testing available for download
(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.
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 - Claudio L. - 10-03-2015 06:15 PM



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