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

[Francois Lanciault]

Hi,

Thank you for the update!

I find that I cannot create local variables in a program like on the standard firmware. In the newRPL doc, it is said that local variables are supported so I must do something wrong.

For example a simple program like:

<< 1 2 -> A B << A B + >> >>

Will be accepted but translated to

<< 1 2 -> 'A' 'B' INVALID_COMMAND A B + >> INVALID_COMMAND

Where -> is obtained with "rightshift zero" and << >> is obtained with "rightshift +"

Must be common knowledge for everyone but me...

François

[Claudio L.]

(12-03-2015 10:16 PM)Francois Lanciault Wrote:  Hi,

Thank you for the update!

I find that I cannot create local variables in a program like on the standard firmware. In the newRPL doc, it is said that local variables are supported so I must do something wrong.

For example a simple program like:

<< 1 2 -> A B << A B + >> >>

Will be accepted but translated to

<< 1 2 -> 'A' 'B' INVALID_COMMAND A B + >> INVALID_COMMAND

Where -> is obtained with "rightshift zero" and << >> is obtained with "rightshift +"

Must be common knowledge for everyone but me...

François

If you EVAL the program, you'll see that it will run fine (it was accepted because it was compiled properly).
I know for a fact this was decompiling fine last time I checked. It seems I must've broken something in the decompiler last time I touched it (for units), hence it's decompiling some items to INVALID_COMMAND's.
I'll take a look. Thanks for the bug report.

EDIT: Yes, confirmed broken, and fixed it. Will come out fixed on the next update.

[Francois Lanciault]

(12-03-2015 11:13 PM)Claudio L. Wrote:  If you EVAL the program, you'll see that it will run fine (it was accepted because it was compiled properly).
I know for a fact this was decompiling fine last time I checked. It seems I must've broken something in the decompiler last time I touched it (for units), hence it's decompiling some items to INVALID_COMMAND's.
I'll take a look. Thanks for the bug report.

EDIT: Yes, confirmed broken, and fixed it. Will come out fixed on the next update.

You are right, it does works with EVAL nevertheless.

BTW the "END" of a WHILE - REPEAT is also decompiled as a "INVALID_COMMAND"

François

[Claudio L.]

(12-05-2015 03:23 AM)Francois Lanciault Wrote:  You are right, it does works with EVAL nevertheless.

BTW the "END" of a WHILE - REPEAT is also decompiled as a "INVALID_COMMAND"

François

It's the same thing, it's already fixed and will come out in the next update.

[Guenter Schink]

Is it by purpose?

Code:

<< 1 10 START 10 + NEXT >>

Works o.K But if, for what reason ever, you either delete the space following the opening or preceeding the closing program delimeter, you'll get a syntax error.

Code:

<<1 10 START 10 + NEXT>>

"Syntax error"

Günter

[rprosperi]

(12-08-2015 03:30 PM)Guenter Schink Wrote:  Is it by purpose?

Code:

<< 1 10 START 10 + NEXT >>

Works o.K But if, for what reason ever, you either delete the space following the opening or preceeding the closing program delimeter, you'll get a syntax error.

Code:

<<1 10 START 10 + NEXT>>

"Syntax error"

Günter

The original 50g is smart enough to check if the leading "<<1" really should be "<< 1" and changes it automatically for you (same with closing >>). It would be good if newRPL did the same as this no doubt avoids MANY typo errors.

[Claudio L.]

(12-08-2015 06:01 PM)rprosperi Wrote:  The original 50g is smart enough to check if the leading "<<1" really should be "<< 1" and changes it automatically for you (same with closing >>). It would be good if newRPL did the same as this no doubt avoids MANY typo errors.

I did it for the { } and [ ], and also for ( ) in complex numbers. I honestly didn't know that << >> also had the same feature. It simply never happened to me before since the space is added automatically.
It's easy to do, it will come out in the next update.

[Helix]

{ A B } PURGE leaves { } on the stack, instead of nothing with the 50g.

I find that with long variable names, the menus appear a bit cluttered, especially the black menu. The main reason is that the first and last columns of pixels are used to display characters, contrary to the 50g.
A more pleasing look (at least for me), could be produced in several ways:
- returning to the system used by HP for the menus (which shortens the displayed names by two pixels)
- inserting gray separators between the black menus, similar to the blank menus
- using only blank menus

[rprosperi]

(12-08-2015 09:18 PM)Claudio L. Wrote:  I did it for the { } and [ ], and also for ( ) in complex numbers. I honestly didn't know that << >> also had the same feature. It simply never happened to me before since the space is added automatically.
It's easy to do, it will come out in the next update.

Me neither. I was getting ready to reply to Guenter's post, saying 'of course it's an error, there must be space between...' but decided to verify on a real 50g first and to my surprise, discovered this subtle little feature. It has probably saved my from hundreds of errors, and I never even knew (or appreciated) it.

[Claudio L.]

(12-08-2015 10:40 PM)Helix Wrote:  { A B } PURGE leaves { } on the stack, instead of nothing with the 50g.

This is temporary. Right now many commands that operate on lists simply use MAP (like PURGE). However, MAP returns a list with the results of the individual commands, therefore no result leaves an empty list on the stack.
I need to implement it slightly better, with a << MAP DROP >>. If I have time I'll do that for the next update, but I may push it for later.

(12-08-2015 10:40 PM)Helix Wrote:  I find that with long variable names, the menus appear a bit cluttered, especially the black menu. The main reason is that the first and last columns of pixels are used to display characters, contrary to the 50g.
A more pleasing look (at least for me), could be produced in several ways:
- returning to the system used by HP for the menus (which shortens the displayed names by two pixels)

This would be easy to do.

(12-08-2015 10:40 PM)Helix Wrote:  - inserting gray separators between the black menus, similar to the blank menus
- using only blank menus

I'll test the gray separators and see how they look.
The different color helps visualize that they are different menus, so I'm not sure about using all white, they need to be different somehow.
I'll work on a more polished look once the menus are fully functional, and we can test many different cases using TMENU.
I even thought of having the text slowly scroll on items that are longer than it fits on screen, but it might be too distracting, we'll see.

[Han]

(12-09-2015 02:15 AM)Claudio L. Wrote:  

(12-08-2015 10:40 PM)Helix Wrote:  I find that with long variable names, the menus appear a bit cluttered, especially the black menu. The main reason is that the first and last columns of pixels are used to display characters, contrary to the 50g.
A more pleasing look (at least for me), could be produced in several ways:
- returning to the system used by HP for the menus (which shortens the displayed names by two pixels)

This would be easy to do.

(12-08-2015 10:40 PM)Helix Wrote:  - inserting gray separators between the black menus, similar to the blank menus
- using only blank menus

I'll test the gray separators and see how they look.
The different color helps visualize that they are different menus, so I'm not sure about using all white, they need to be different somehow.
I'll work on a more polished look once the menus are fully functional, and we can test many different cases using TMENU.
I even thought of having the text slowly scroll on items that are longer than it fits on screen, but it might be too distracting, we'll see.

What about just drawing the "corners" of each menu item? So rather than using a complete open border (bottom menu) or completely filled in pixels (top menu), why not just draw enough to delineate the corners of the each menu item. As for coloring, I think it would not look too bad if they were all on white background, since the geometry of the menus would make it clear which is which.

Whatever you do, please don't put scrolling in... I don't want to be reminded of the old days when people where just learning how to create HTML and placed blink tags all over the place.

[Helix]

I don't know if this is a known issue, but the sequence: OFF ON doesn't preserve the state of the calculator:
- If there is more than one page of variables, the calculator returns to the first page of the menus.
- The precision returns to the default value of 32 digits.

When writing a program, HIST doesn't register as STO (but when editing a program, it works correctly).

Editing a program with the down cursor doesn't open the multiline editor.

(12-09-2015 02:15 AM)Claudio L. Wrote:  

(12-08-2015 10:40 PM)Helix Wrote:  I find that with long variable names, the menus appear a bit cluttered, especially the black menu. The main reason is that the first and last columns of pixels are used to display characters, contrary to the 50g.
A more pleasing look (at least for me), could be produced in several ways:
- returning to the system used by HP for the menus (which shortens the displayed names by two pixels)

This would be easy to do.

Maybe leaving inactive only the first column of pixels in each menu item can be a good compromise, too.

(12-09-2015 02:15 AM)Claudio L. Wrote:  I even thought of having the text slowly scroll on items that are longer than it fits on screen, but it might be too distracting, we'll see.

The scrolling texts in the menus sound weird, unless this can be activated on demand. But it's probably not necessary if we have a way to visualize the entire names, like in the 50g with right shift + down cursor.

[Francois Lanciault]

Very impressive!

newRPL is more than 1.5X faster than the HP-Prime running my benchmark. Also 245X faster than a normal HP-50G.

I was not expecting performance would be that good!

F.

[Claudio L.]

(12-15-2015 03:51 PM)Francois Lanciault Wrote:  Very impressive!

newRPL is more than 1.5X faster than the HP-Prime running my benchmark. Also 245X faster than a normal HP-50G.

I was not expecting performance would be that good!

F.

I'd love to hear more about your benchmark. Can you show the code here?
I did some benchmarks in the past against the stock rom of the 50g, but never against the Prime, so I'm very interested to see which areas your benchmark impacts more (integers? reals? loops? variables?).

Here are some of my old results:
Old benchmark using mpdec library
Newer results with new decimal library

[Francois Lanciault]

(12-15-2015 07:06 PM)Claudio L. Wrote:  

(12-15-2015 03:51 PM)Francois Lanciault Wrote:  Very impressive!

newRPL is more than 1.5X faster than the HP-Prime running my benchmark. Also 245X faster than a normal HP-50G.

I was not expecting performance would be that good!

F.

I'd love to hear more about your benchmark. Can you show the code here?
I did some benchmarks in the past against the stock rom of the 50g, but never against the Prime, so I'm very interested to see which areas your benchmark impacts more (integers? reals? loops? variables?).

Here are some of my old results:
Old benchmark using mpdec library
Newer results with new decimal library

The program computes the quantity of primes numbers less than a given number. So it is mostly integer, with a few square-root and modulo division. It does not used any advanced functions (like ISPRIME or such). It is not the fastest algorithm to do that job but it is faster than checking the primality of every numbers. I have implemented the program on about 100 calculators/computers so I have a good database of results!

I will try to post the code tonight.

François

[Francois Lanciault]

(12-15-2015 07:23 PM)Francois Lanciault Wrote:  The program computes the quantity of primes numbers less than a given number. So it is mostly integer, with a few square-root and modulo division. It does not used any advanced functions (like ISPRIME or such). It is not the fastest algorithm to do that job but it is faster than checking the primality of every numbers. I have implemented the program on about 100 calculators/computers so I have a good database of results!

I will try to post the code tonight.

François

Hi Claudio,

Here is the code :

For HP-50G

The main program

newma

Code:


%%HP: T(3)A(R)F(.);
\<< TIME SWAP DUP 1. - 2. / IP DUP 1. - 3. / IP - SWAP 0. 0. \-> N J C
  \<< 5. N \v/
    FOR I
      IF I ISPA
      THEN 1. - I 2. * 'C' STO C I I * + 'J' STO
        WHILE J N \<=
        REPEAT 3. I 2. -
          FOR K
            IF J K MOD 0. ==
            THEN 1. SF I 'K' STO
            END 2.
          STEP
          IF 1. FC?C
          THEN 1. -
          END C 'J' STO+
        END
      END 2.
    STEP
  \>> 1. + SWAP TIME SWAP HMS- 100. *
\>>

This program uses a subroutine: ISPA as follow

Code:


%%HP: T(3)A(R)F(.);
\<< DUP \v/ IP \-> N R
  \<< 1.
    DO 2. + DUP DUP
    UNTIL R > SWAP N SWAP MOD NOT OR
    END R >
  \>>
\>>

This is the version for the standard HP-50G. For newRPL, I made the following changes:

- removed the dot after each constant (the dot was there because HP-50G is faster in float than in exact arithmetic. I believe newRPL is faster without trailing dot)
- changed "TIME" for "TICKS"
- changed the "C 'J' STO+" sequence to "C J + 'J' STO"

And the corresponding HP-Prime program:

Code:


ISPR();
EXPORT NEWM(NOM)
BEGIN
LOCAL II,J,U,K,COMP,TT;
LOCAL INC,NBP,RAC;
TT:=TICKS;
RAC:=IP(√NOM);
NBP:=IP((NOM-1)/2);
NBP:=NBP-IP((NBP-1)/3);
FOR II FROM 5 TO RAC STEP 2 DO
IF ISPR(II) THEN
NBP:=NBP-1;
INC:=2*II;
FOR J FROM II²+INC TO NOM STEP INC DO
COMP:=0;
FOR K FROM 3 TO II-2 STEP 2 DO
IF J MOD K == 0 THEN
COMP:=1;
BREAK;
END;
END;
IF COMP==0 THEN
NBP:=NBP-1;
END;
END;
END;
END;
NBP+1▶NBP;
TT:=(TICKS-TT)/1000;
PRINT(NBP+" PRIMES IN "+TT+" SEC.");
END;

ISPR(V)
BEGIN
LOCAL I;
LOCAL RAC;
RAC:=√V;
FOR I FROM 3 TO RAC STEP 2 DO
IF V MOD I==0 THEN
RETURN 0;
END;
END;
RETURN 1;
END;

Have fun.

Francois

[Claudio L.]

(12-16-2015 05:02 AM)Francois Lanciault Wrote:  This is the version for the standard HP-50G. For newRPL, I made the following changes:

- removed the dot after each constant (the dot was there because HP-50G is faster in float than in exact arithmetic. I believe newRPL is faster without trailing dot)

The trailing dot means an approximated number in newRPL, but still an integer so it won't really be any faster with or without the dot. The only difference is the result will have a dot too.

(12-16-2015 05:02 AM)Francois Lanciault Wrote:  - changed "TIME" for "TICKS"

I guess you figured out for yourself that TICKS gives you the time in microseconds, so instead of dividing by 8192 like the old days, just use 1e6.
Time is in microseconds but the clock resolution is actually 100 kHz, so you'll see a granularity of 10 in the resulting number. Still much more accurate than the old TICKS.
I don't think it's documented anywhere yet.

(12-16-2015 05:02 AM)Francois Lanciault Wrote:  - changed the "C 'J' STO+" sequence to "C J + 'J' STO"

Yes, I'm yet to implement those.

So your code is just integers and loops, 2 things that newRPL excels at, which justifies the high multiples you got. When you start throwing in floating point operations, the decimal library brings the speed more in line with reality (about 100x vs the 50g).
In that case I think the Prime will be much faster. newRPL beating the Prime is little more than an optical illusion, as the Prime runs at 400 MHz, vs. 192 MHz of newRPL. So don't expect newRPL to beat the Prime in general, but if the codes are equally efficient, you should see a 0.5x more or less. Anything above that is a reason to celebrate!

[Francois Lanciault]

(12-16-2015 12:12 PM)Claudio L. Wrote:  I guess you figured out for yourself that TICKS gives you the time in microseconds, so instead of dividing by 8192 like the old days, just use 1e6.
Time is in microseconds but the clock resolution is actually 100 kHz, so you'll see a granularity of 10 in the resulting number. Still much more accurate than the old TICKS.
I don't think it's documented anywhere yet.

Yes I used 1E6 as it was what looked like the right value, but thanks to confirm this.

(12-16-2015 12:12 PM)Claudio L. Wrote:  So your code is just integers and loops, 2 things that newRPL excels at, which justifies the high multiples you got. When you start throwing in floating point operations, the decimal library brings the speed more in line with reality (about 100x vs the 50g).
In that case I think the Prime will be much faster. newRPL beating the Prime is little more than an optical illusion, as the Prime runs at 400 MHz, vs. 192 MHz of newRPL. So don't expect newRPL to beat the Prime in general, but if the codes are equally efficient, you should see a 0.5x more or less. Anything above that is a reason to celebrate!

Yes but newRPL computes by default with a lot more decimals than the Prime... So speed comparison needs to be performed with roughly equal accuracy.
I do have a floating point benchmark also (only tested on about 30 calculators) so I will try this one too and report.
What is the command on newRPL to switch to 12 digits or so accuracy ?

François

[Francois Lanciault]

(12-16-2015 02:49 PM)Francois Lanciault Wrote:  I do have a floating point benchmark also (only tested on about 30 calculators) so I will try this one too and report.
What is the command on newRPL to switch to 12 digits or so accuracy ?

François

Hi again Claudio,

I entered this new floating point benchmark in newRPL and to my surprise the end result was different than on all other calculator. After a few debugging minutes, I found the bug: Because new RPL does not return exactly 0 for LN(1) as it should, the program was doing one additional iteration.

Something you intent to correct ? Any easy way out beside testing for a results smaller than 1e-40 and replacing with zero ?

François

[Claudio L.]

(12-16-2015 04:55 PM)Francois Lanciault Wrote:  

(12-16-2015 02:49 PM)Francois Lanciault Wrote:  I do have a floating point benchmark also (only tested on about 30 calculators) so I will try this one too and report.
What is the command on newRPL to switch to 12 digits or so accuracy ?

François

Hi again Claudio,

I entered this new floating point benchmark in newRPL and to my surprise the end result was different than on all other calculator. After a few debugging minutes, I found the bug: Because new RPL does not return exactly 0 for LN(1) as it should, the program was doing one additional iteration.

Something you intent to correct ? Any easy way out beside testing for a results smaller than 1e-40 and replacing with zero ?

François

Sorry about that, looks like I'll need to handle 1 as a special case to return exactly zero.
To change the precision just use the SETPREC command with the desired number of digits in the stack.
Any number up to 2000 is fine. However, newRPL is more efficient when the number of digits is a multiple of 8. In other words, if you select 12 digits, it will use 16 internally, then results will be rounded to 12 figures, wasting some computing power. But for a benchmark, I think it's fine if you select 12 digits, the difference won't be too much.