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

[Claudio L.]

(10-08-2015 12:37 AM)matthiaspaul Wrote:  Perhaps U+212F "SCRIPT SMALL E" (or U+2147 "DOUBLE-STRUCK ITALIC SMALL E")?

Thank you! That's a good one, Wikipedia lists U+212F as a symbol for mathematical constant e here.
So I think that's the way to go.

[Helix]

More comments about unit functions:

1_a 1_ca CONVERT gives "inconsistent units", instead of 100_ca

20_°C 1_°F CONVERT gives 68._°F (I don't understand the dot here)

68_°F 1_°C CONVERT gives 19.99:._°C instead of 20_°C

In program mode, typing the "_" character switches to algebraic mode. I don't understand why.

[Helix]

(10-08-2015 12:37 PM)Claudio L. Wrote:  

(10-08-2015 12:37 AM)matthiaspaul Wrote:  Perhaps U+212F "SCRIPT SMALL E" (or U+2147 "DOUBLE-STRUCK ITALIC SMALL E")?

Thank you! That's a good one, Wikipedia lists U+212F as a symbol for mathematical constant e here.
So I think that's the way to go.

It is confirmed in this page:
http://xahlee.info/comp/unicode_math_operators.html

But these characters seem not very common. On my PC, I've found the characters U+2147, U+2148 and U+2149 only in the fonts "Segoe UI symbols" and "Cambria Math". I don't know if this is a problem when transferring or writing a program on the PC.

Also, does that mean that you need new glyphs for these characters?

[Han]

(10-08-2015 09:26 PM)Helix Wrote:  In program mode, typing the "_" character switches to algebraic mode. I don't understand why.

Perhaps this is because complex units (products and quotients of units) are entered generally in algebraic form. On the other hand, I am not sure if the command line knows when a unit has "ended" so that it properly returns to RPN mode. Or does it?

[Claudio L.]

(10-08-2015 10:37 PM)Helix Wrote:  But these characters seem not very common. On my PC, I've found the characters U+2147, U+2148 and U+2149 only in the fonts "Segoe UI symbols" and "Cambria Math". I don't know if this is a problem when transferring or writing a program on the PC.

Also, does that mean that you need new glyphs for these characters?

That's a problem. Even the free STIX fonts don't have all those glyphs at once. The general font has U+2147/48/49, but only the italic font has U+212F, so you can't take plain text, and get it to display properly just by changing the font.
I think we might have to use just regular letters, unless more common symbols are found.

Don't add the glyphs to the fonts yet, let's see if there are better alternatives first. Ideally, you'd take newRPL code, open it in your favorite editor and work like nothing happened, using very rare characters will make this just as bad as the custom code page in the hp48 did.

[Claudio L.]

(10-08-2015 11:39 PM)Han Wrote:  

(10-08-2015 09:26 PM)Helix Wrote:  In program mode, typing the "_" character switches to algebraic mode. I don't understand why.

Perhaps this is because complex units (products and quotients of units) are entered generally in algebraic form. On the other hand, I am not sure if the command line knows when a unit has "ended" so that it properly returns to RPN mode. Or does it?

This was on purpose, I thought if you are planning to write a unit you might want the algebraic mode, so it doesn't add spaces when you multiply/divide units.
EDIT: This is how the 50g does it, by the way.
The command line doesn't scan and automatically change mode (this is in my "nice to have" list, together with auto-completion of commands), the ENTRY key is functional just like it was on the 50g.

But if this makes it cumbersome, I can remove it and leave it without mode change. Let me know.

[Helix]

(10-09-2015 01:46 PM)Claudio L. Wrote:  That's a problem. Even the free STIX fonts don't have all those glyphs at once. The general font has U+2147/48/49, but only the italic font has U+212F, so you can't take plain text, and get it to display properly just by changing the font.
I think we might have to use just regular letters, unless more common symbols are found.

This question will probably arise with other characters too, which are not present in each font, like superscripts, subscripts, and some mathematical symbols. But I think we have no other choice here.

(10-09-2015 01:50 PM)Claudio L. Wrote:  EDIT: This is how the 50g does it, by the way.

My HP50g is different, but I realized that I had reassigned the right shift "_" key! Without this reassignment, both calculators switch to algebraic mode, and that makes sense indeed.
The main difference in newRPL, is that I have to do ENTRY twice to return to the Program mode, which represents 4 key presses, and it's not very convenient. Could it be changed to one ENTRY only?

[Claudio L.]

(10-09-2015 10:09 PM)Helix Wrote:  

(10-09-2015 01:46 PM)Claudio L. Wrote:  That's a problem. Even the free STIX fonts don't have all those glyphs at once. The general font has U+2147/48/49, but only the italic font has U+212F, so you can't take plain text, and get it to display properly just by changing the font.
I think we might have to use just regular letters, unless more common symbols are found.

This question will probably arise with other characters too, which are not present in each font, like superscripts, subscripts, and some mathematical symbols. But I think we have no other choice here.

I think all the characters I used are present in the Arial Unicode that comes with all Windows OS, and I believe Linux and other OS's have an equivalent one.
The math symbols are more specialized, though, it's harder to find a good font.

(10-09-2015 10:09 PM)Helix Wrote:  My HP50g is different, but I realized that I had reassigned the right shift "_" key! Without this reassignment, both calculators switch to algebraic mode, and that makes sense indeed.
The main difference in newRPL, is that I have to do ENTRY twice to return to the Program mode, which represents 4 key presses, and it's not very convenient. Could it be changed to one ENTRY only?

I'll see if I can make it better. Ideally, it should switch modes automatically, but that could make it slower, since for instance a long program might need to be analyzed completely to determine if programming mode needs to be active (the opening bracket could be quite far).

[Claudio L.]

(10-08-2015 09:26 PM)Helix Wrote:  More comments about unit functions:

1_a 1_ca CONVERT gives "inconsistent units", instead of 100_ca

20_°C 1_°F CONVERT gives 68._°F (I don't understand the dot here)

68_°F 1_°C CONVERT gives 19.99:._°C instead of 20_°C

In the first case, I had forgotten to enable SI prefixes on the are unit, so 'ca' was an unknown unit for the system.

The dot in the 2nd conversion is because the conversion factors are not applied in the best order possible, especially for inverse operations, the conversion factor is inverted and then multiplied by the result. The inverse of the factor might not be an exact number, even if the final result would be. Numerically it all works with the usual minimal rounding errors, but the order of operations might make an otherwise exact conversion to become approximated.
In any case, exact numbers don't make much sense with units, since all measurements are approximated by their own nature.

The third case is a bug in the displaying routine. It shows bad rounding of the last digit, from a 9 into a ':' which is the ASCII character that follows 9, when it should actually propagate the carry to the next digit. I'll work on that.

As usual, thanks for the bug reports.

[Claudio L.]

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

[Han]

Sounds exciting (esp. the auto-complete)! Will have to test it out this weekend.

[m@x]

Hello Claudio,

Sorry for interrupting this thread, but I would like to know if you have any plans to port newRPL to an emulator so that we can use it without actual device, on our PC-s, and, preferably, smartphones (something like emu48).

Regards,
Martin

[Claudio L.]

(10-21-2015 11:57 PM)Han Wrote:  Sounds exciting (esp. the auto-complete)! Will have to test it out this weekend.

There's a few things to consider about the current status of autocomplete:
* It lists all the commands that libraries declare, that doesn't mean I had the time to actually implement that command, so many commands might be suggested but give "Invalid Opcode" error when executed, this is expected.
* I enabled all libraries to expose all commands, but I haven't had the time to review one by one the special cases. Some libraries use internal words, which might be offered for suggestion, but cannot be decompiled by themselves. Until I scan through every library and un-list those special cases, you might see "INVALID_COMMAND" being suggested from time to time. This is expected.

I'm thinking of implementing a temporary full-width status area, perhaps with alpha-hold left cursor (similar to the way errors are displayed now), which provides 2 lines of text to display help about the suggested command. I'm not sure if two lines will be enough to show anything meaningful, though.
What do you think?

[Claudio L.]

(10-22-2015 12:47 PM)m@x Wrote:  Hello Claudio,

Sorry for interrupting this thread, but I would like to know if you have any plans to port newRPL to an emulator so that we can use it without actual device, on our PC-s, and, preferably, smartphones (something like emu48).

Regards,
Martin

That's already done, I just don't have the time to publish updated versions all the time, generating proper installers for all major operating systems is a big task. The ROMs in this thread are very informal and incomplete, for the early-adopter, hard-core RPL fans.

You can easily install the Qt libraries with Qt Creator on your operating system of choice, use git to checkout the sources from sourceforge, open the project file newrpl-ui.pro from within Qt Creator and hit "Run".
That will give you an emulated screen, and you can open and save sessions.
I have confirmed it builds fine on Windows, Linux and FreeBSD. I have no plans to make an android version for now, but it's not discarded for the future.

This is a one-time setup. After that, you'll be able to simply "git pull" updated versions and rebuild in one click.

[Werner]

(10-11-2015 01:27 AM)Claudio L. Wrote:  

(10-08-2015 09:26 PM)Helix Wrote:  More comments about unit functions:

1_a 1_ca CONVERT gives "inconsistent units", instead of 100_ca

20_°C 1_°F CONVERT gives 68._°F (I don't understand the dot here)

68_°F 1_°C CONVERT gives 19.99:._°C instead of 20_°C

The third case is a bug in the displaying routine. It shows bad rounding of the last digit, from a 9 into a ':' which is the ASCII character that follows 9, when it should actually propagate the carry to the next digit. I'll work on that.

As usual, thanks for the bug reports.

Claudio, 68 F° is exactly 20°C, so there should be no rounding?
Cheers, Werner

[Claudio L.]

(10-22-2015 02:12 PM)Werner Wrote:  

(10-11-2015 01:27 AM)Claudio L. Wrote:  The third case is a bug in the displaying routine. It shows bad rounding of the last digit, from a 9 into a ':' which is the ASCII character that follows 9, when it should actually propagate the carry to the next digit. I'll work on that.

As usual, thanks for the bug reports.

Claudio, 68 F° is exactly 20°C, so there should be no rounding?
Cheers, Werner

But there is, because the order of operations when the unit conversion takes place is not altered in any way, operations are done as they come and that can cause inexact operations to take place.

68_°F is first converted to absolute scale by adding 459.67. Then the unit is scanned for replacement, and 1_°R = 5/9_K, so there's 527.67*(5/9), and there's where the rounding happens: 5/9 is a real and cannot be represented exactly, so it's .555555555..... and that multiplication produces 293.149999999999999999999....
Last, the scale is converted back to Celsius by subtracting 273.15, resulting in 19.999999999999999999999....
After I fixed a normalization bug, it now gets correctly rounded to 20., but I can't get rid of the dot (approximated), since the number is not exact. It's 20 up to the system precision (not just displayed as 20, it's internal representation is exactly 20), but because it is the result of operating with an approximated number, the system marks it with the trailing dot.

[Werner]

But 527.67 x (5/9) does produce 293.15 ...
on a 12-digit machine:

527.67 x 0.555555555556
= 293.15000000023452

I see you multiply by 0.555555555555, that is not the correctly rounded 5/9
Alternatively you may multiply by 5 and then divide by 9 - only the latter will produce a rounding error.

Cheers, Werner

[matthiaspaul]

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

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

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

[matthiaspaul]

(10-22-2015 05:56 PM)Claudio L. Wrote:  After I fixed a normalization bug, it now gets correctly rounded to 20., but I can't get rid of the dot (approximated), since the number is not exact. It's 20 up to the system precision (not just displayed as 20, it's internal representation is exactly 20), but because it is the result of operating with an approximated number, the system marks it with the trailing dot.

Are there some easy (interactive and programmatical) means to declare an approximated number as exact again?

Greetings,

Matthias

[Claudio L.]

(10-22-2015 06:16 PM)Werner Wrote:  But 527.67 x (5/9) does produce 293.15 ...
on a 12-digit machine:

527.67 x 0.555555555556
= 293.15000000023452

I see you multiply by 0.555555555555, that is not the correctly rounded 5/9
Alternatively you may multiply by 5 and then divide by 9 - only the latter will produce a rounding error.

Cheers, Werner

I never said there's a rounding error, the number is computed properly. But 5/9 is not exact, and it's therefore marked as approximated. The "19.9:" was a normalization bug, the number was not normalized and confused the text conversion routine.
When I show the number 0.55555555... I always add the ellipsis because there's a variable number of digits, up to 2000 digits but you are right, the last one is a 6.
Anyway, the bug is fixed, and the calculation returns exactly 20. (or should I say exactly-approximatedly 20. :-)