[newRPL] interested in RPN mode?

[Claudio L.]

Would there be any interest in a RPN mode in which the stack is limited to 4 levels, there's "proper" (from RPN point of view, don't kill me) T level duplication and stack lift behavior, etc.

It would be nearly trivial to add a library to newRPL to support RPN, but unless there's actual interest in having a classic RPN mode, then I'd rather not add "feature creep" to newRPL.

RPN and RPL on the same machine is possible and can work quite well actually, RPN users would also get access to all the newRPL commands and more advanced objects, so it would be a "newRPN" rather than a classic.

Feel free to voice your opinions here... but don't start a war!

[Massimo Gnerucci]

(10-18-2019 03:51 PM)Claudio L. Wrote:  Would there be any interest in a RPN mode in which the stack is limited to 4 levels, there's "proper" (from RPN point of view, don't kill me) T level duplication and stack lift behavior, etc.

It would be nearly trivial to add a library to newRPL to support RPN, but unless there's actual interest in having a classic RPN mode, then I'd rather not add "feature creep" to newRPL.

RPN and RPL on the same machine is possible and can work quite well actually, RPN users would also get access to all the newRPL commands and more advanced objects, so it would be a "newRPN" rather than a classic.

Feel free to voice your opinions here... but don't start a war!

I'd say a sound "YES", thank you Claudio.

[Don Williams]

Yes, Yes, absolutely YES!

[John Keith]

Not a priority as far as I'm concerned, I would rather see the effort go to the NewRPL language. Especially considering all the great options the classic RPN folks have available now. (DM42, 41CL, Woodstock and Spice low power, ...)

[rprosperi]

Would newRPN (w/4-level stack) be only for interactive use, or would normal RPL programming capabilities still apply (it seems they would be extremely hobbled with a 4-stack depth limit)?

[David Hayden]

Would this also include:
- RPN-like syntax for STO and RCL?
- RPN programming constructs (labels, GOTO, DSE, ISG)

To me, these things make RPN easier to learn and easier to program. But the come at the expense of much less functionality than RPL. To me, the stack behavior is of minimal value.

[Claudio L.]

(10-18-2019 07:55 PM)rprosperi Wrote:  Would newRPN (w/4-level stack) be only for interactive use, or would normal RPL programming capabilities still apply (it seems they would be extremely hobbled with a 4-stack depth limit)?

Good question, I guess we need to define exactly how this would behave.

The way I see it, I could implement RPN the following way:

* A flag (ok, 2 flags) would determine stack depth: 4-level, 8-level or infinite.
* The execution loop would test the flags, and check after executing each command if the stack has > 4 (or 8) levels and "trim" it, or if it has less it would get the last known "T" value and fill the stack with it to complete the 4/8 levels.
* The UI can be tweaked to make the Enter key behave more like an RPN machine.

This means that internally, existing newRPL commands will make use of the entire memory and infinite stack, but once the command ends, the response will "trim" the stack to 4 levels. For example, if you have a 5 element list and you do OBJ->, you'll get the last 3 elements and the number 5 on the stack (after a "trim" to only 4 values).
But, if you keep the list together, one list (or vector/matrix) takes ONE stack level, also one complex number takes ONE level, not 2 as in the classic RPN machines. So code could make more efficient use of the stack.

Programming would of course be plain RPL, implementing keystroke programming would require a much more detailed reimplementation of commands and UI.
If you are truly nostalgic, just write RPL using [Enter] after each command so it all lines up vertically like in keystroke programs .

In summary, the idea is to have not a completely new calculator called newRPN, but an RPN mode running on the same RPL engine. A couple of flags would allow any user or program to enable/disable RPN mode at will.

[Claudio L.]

(10-18-2019 08:54 PM)David Hayden Wrote:  Would this also include:
- RPN-like syntax for STO and RCL?
- RPN programming constructs (labels, GOTO, DSE, ISG)

To me, these things make RPN easier to learn and easier to program. But the come at the expense of much less functionality than RPL. To me, the stack behavior is of minimal value.

As a start I'd say no, you wouldn't have these. But nothing prevents adding new commands to newRPL within an RPN library, so you could have commands named DSE, ISG and make them perform exactly the same. But then you'd be defining a LARGE set of commands for RPN use only.

LBL and GOTO are hard to implement due to the structured nature of RPL. If it was easy I would've implemented GOTO for RPL already, I would say those 2 are a big "no".

[rprosperi]

(10-18-2019 08:54 PM)Claudio L. Wrote:  

(10-18-2019 07:55 PM)rprosperi Wrote:  Would newRPN (w/4-level stack) be only for interactive use, or would normal RPL programming capabilities still apply (it seems they would be extremely hobbled with a 4-stack depth limit)?

Good question, I guess we need to define exactly how this would behave.

The way I see it, I could implement RPN the following way:

* A flag (ok, 2 flags) would determine stack depth: 4-level, 8-level or infinite.
* The execution loop would test the flags, and check after executing each command if the stack has > 4 (or 8) levels and "trim" it, or if it has less it would get the last known "T" value and fill the stack with it to complete the 4/8 levels.
* The UI can be tweaked to make the Enter key behave more like an RPN machine.

This means that internally, existing newRPL commands will make use of the entire memory and infinite stack, but once the command ends, the response will "trim" the stack to 4 levels. For example, if you have a 5 element list and you do OBJ->, you'll get the last 3 elements and the number 5 on the stack (after a "trim" to only 4 values).
But, if you keep the list together, one list (or vector/matrix) takes ONE stack level, also one complex number takes ONE level, not 2 as in the classic RPN machines. So code could make more efficient use of the stack.

Programming would of course be plain RPL, implementing keystroke programming would require a much more detailed reimplementation of commands and UI.
If you are truly nostalgic, just write RPL using [Enter] after each command so it all lines up vertically like in keystroke programs .

In summary, the idea is to have not a completely new calculator called newRPN, but an RPN mode running on the same RPL engine. A couple of flags would allow any user or program to enable/disable RPN mode at will.

As long as the stack is 'trimmed' to 4 levels after processing, it sounds interesting.

And by 'check after executing each command' does this mean each newRPL-native command, or would it include previously-defined newRPL prograns/commands already in the user's path? If the latter, then I suppose one could mix newRPL commands into newRPN commands and programs, so extended-stack manipulation components can be used (Matrices, Lists, etc.) as needed, returning simpler results to be consumed in the newRPN program.

Is that what you're thinking?

[Claudio L.]

(10-18-2019 10:17 PM)rprosperi Wrote:  As long as the stack is 'trimmed' to 4 levels after processing, it sounds interesting.

And by 'check after executing each command' does this mean each newRPL-native command, or would it include previously-defined newRPL prograns/commands already in the user's path? If the latter, then I suppose one could mix newRPL commands into newRPN commands and programs, so extended-stack manipulation components can be used (Matrices, Lists, etc.) as needed, returning simpler results to be consumed in the newRPN program.

Is that what you're thinking?

When I say each command, I mean each step in a program.
<< 1 2 3 4 5 >> would push a 1, then check, then push 2, check, 3, check, 4, check, then when pushing 5 there will be 5 elements on the stack, and the next check will trim the stack back to 4 elements. This allows all commands to work the same way in RPN or RPL mode.
User programs would always have the stack trimmed after each step, internal commands (which take a single step) have access to the infinite RPL stack internally,and they may return more than 4 elements in the stack, but there will be a stack check and trim happening.
So if a command returns more than 4 elements, you can simply switch to RPL or 8 level stack to get the full results.
In the background it's RPL commands doing the job, so you can work with large matrices, lists, etc.

[toml_12953]

(10-19-2019 06:45 PM)Claudio L. Wrote:  

(10-18-2019 10:17 PM)rprosperi Wrote:  As long as the stack is 'trimmed' to 4 levels after processing, it sounds interesting.

And by 'check after executing each command' does this mean each newRPL-native command, or would it include previously-defined newRPL prograns/commands already in the user's path? If the latter, then I suppose one could mix newRPL commands into newRPN commands and programs, so extended-stack manipulation components can be used (Matrices, Lists, etc.) as needed, returning simpler results to be consumed in the newRPN program.

Is that what you're thinking?

When I say each command, I mean each step in a program.
<< 1 2 3 4 5 >> would push a 1, then check, then push 2, check, 3, check, 4, check, then when pushing 5 there will be 5 elements on the stack, and the next check will trim the stack back to 4 elements. This allows all commands to work the same way in RPN or RPL mode.
User programs would always have the stack trimmed after each step, internal commands (which take a single step) have access to the infinite RPL stack internally,and they may return more than 4 elements in the stack, but there will be a stack check and trim happening.
So if a command returns more than 4 elements, you can simply switch to RPL or 8 level stack to get the full results.
In the background it's RPL commands doing the job, so you can work with large matrices, lists, etc.

Wouldn't that slow it down considerably? I'd like to see an eight level stack machine that works just like a 4-level machine other than the number of levels. Back in the '70s, just before introducing the Altair 8800, MITS had a 7-level stack desktop calculator that you could add an external octal programmer to. I was about to buy one when the Altair came out and my plans changed. With 8 levels, you should be able program almost any practical engineering equation without using intermediate storage registers.

[Claudio L.]

(10-21-2019 08:12 PM)toml_12953 Wrote:  Wouldn't that slow it down considerably? I'd like to see an eight level stack machine that works just like a 4-level machine other than the number of levels. Back in the '70s, just before introducing the Altair 8800, MITS had a 7-level stack desktop calculator that you could add an external octal programmer to. I was about to buy one when the Altair came out and my plans changed. With 8 levels, you should be able program almost any practical engineering equation without using intermediate storage registers.

Well, not considerably but yes, RPN mode would execute with a slight penalty compared to RPL because of the stack trimming. Now in RPN you always have to copy the T register when you drop arguments, or move up all elements when you insert, so compared to other RPN machine no, it wouldn't be any slower.
RPL would also suffer a tiny penalty because the main loop would have to check for the RPN flag to decide which mode is in, but probably too small to measure.

[compsystems]

Another interesting mode would be a "natural notation" view with the µPtyhon engine, I think there is no memory in the physical calculator hp50, but the PC version could run this third mode.

Entry:
1: NewRPL
2: RPN
3: Natural notation: µPtyhon engine

[grsbanks]

(10-30-2019 10:20 PM)compsystems Wrote:  I think there is no memory in the physical calculator hp50, but the PC version could run this third mode.

What makes you say that? The PC version is an emulator that runs the ROM of the hardware 50g. It is subject to the same limitations as the physical machine.

[Paul Dale]

This seems like a workable suggestion. There might be some difficulties figuring out the semantics of what should be done in order to stay consistent.


Pauli

[Claudio L.]

(10-31-2019 09:50 AM)grsbanks Wrote:  

(10-30-2019 10:20 PM)compsystems Wrote:  I think there is no memory in the physical calculator hp50, but the PC version could run this third mode.

What makes you say that? The PC version is an emulator that runs the ROM of the hardware 50g. It is subject to the same limitations as the physical machine.

Actually, the PC version, which is called newRPL Desktop, is not an emulator. It is a native Qt application, it merely simulates the screen of the 50g because it was initially created as a testing and debugging tool, but now it's a full application with connectivity kit functionality.
It is configured with more RAM than the ARM version, currently 1MB but I can change it at will.

However, there's nothing RPx in Python, or micropython, so it's completely unrelated, it's a different environment with different requirements, memory management, etc. They don't work well together, and there's no plans to even review the feasibility, much less try to modify micro python to interwork with the RPL environment.

[grsbanks]

(11-01-2019 03:41 AM)Claudio L. Wrote:  Actually, the PC version, which is called newRPL Desktop, is not an emulator. It is a native Qt application

My bad, I should have looked at the thread title... I didn't realize at the time that newRPL was what was under discussion!

[compsystems]

(11-01-2019 03:41 AM)Claudio L. Wrote:  However, there's nothing RPx in Python, or micropython, so it's completely unrelated, it's a different environment with different requirements, memory management, etc. They don't work well together, and there's no plans to even review the feasibility, much less try to modify micro python to interwork with the RPL environment.

What I propose is that upython be run independently from NewRPL, just open it to add a graphical interface of input and output data with menus at the bottom

[Claudio L.]

(11-01-2019 03:44 PM)compsystems Wrote:  

(11-01-2019 03:41 AM)Claudio L. Wrote:  However, there's nothing RPx in Python, or micropython, so it's completely unrelated, it's a different environment with different requirements, memory management, etc. They don't work well together, and there's no plans to even review the feasibility, much less try to modify micro python to interwork with the RPL environment.

What I propose is that upython be run independently from NewRPL, just open it to add a graphical interface of input and output data with menus at the bottom

<< IF it runs completely independent AND is unrelated AND doesn't share memory management OR math objects OR routines OR anything else... THEN it's a different project END >>

[Claudio L.]

RPN mode is ready for initial testing!

Flags to enable RPN mode:

-28 SF --> Set RPN mode when set, back to regular RPL mode when clear
-29 SF --> Extended RPN mode when set (8-level), or regular 4-level RPN when clear


Now to make it more attractive to coders of classic RPN machines, a few simple instructions were added to RPL that will hopefully simplify porting RPN algorithms to the newPRL.

This assembly-like syntax for newRPL can be used intermixed with regular RPL. It's oriented towards simplifying stackrobatics and making numeric algorithms clearer and easier to read.
Please refer to Chapter 5 of the newRPL wiki.

For those new to newRPL, please see the first post on the main newRPL thread for download links and installation instructions.