[34S] Proposal for Entry RPN mode with dynamic stack

[walter b]

(02-20-2015 12:35 AM)Thomas Klemm Wrote:  

(02-19-2015 05:37 PM)walter b Wrote:  (The response of Thomas K. to Didier's post isn't filed correctly but I gave up trying to teach Thomas - no use.)

Exactly! You hit the nail on its very head

d:-)

[Thomas Radtke]

(02-20-2015 06:03 AM)Paul Dale Wrote:  The big question is, how could it be done better today?

What's wrong with the method used by the 20b/30b calculators?

[matthiaspaul]

(02-19-2015 01:31 PM)Bit Wrote:  

(02-19-2015 10:10 AM)matthiaspaul Wrote:  However, some calculators support power operations on registers like RCL-arrow-^ and STO-arrow-^. It might be a good idea to reserve the key currently assigned to XEQ for this purpose (as it is in the same row as all those power functions and also above the ^ key, so it seems mnemo-technically the best choice).

RCL and the arrows are already used for the RCL combined with minimum/maximum operations, and you need the arrow keys to enter them. How would your proposal work in relation to that?

My statement wasn't really clear. What I meant was:

"RCL↑ n" ([RCL] [↑]) for maximum
"RCL↓ n" ([RCL] [↓]) for minimum
"RCL^ n" ([RCL] [XEQ] in current keyboard layout) for power
"RCLv n" ([RCL] [R↓] or [RCL] [RCL] in current keyboard layout) for stack-relative addressing

Greetings,

Matthias

[matthiaspaul]

(02-19-2015 01:51 PM)Bit Wrote:  I'd expect trouble with library and user programs. If they change the RPN mode and get paused or interrupted, it'd be a major source of confusion for the user if the ENTER key suddenly works differently, especially as it may not be noticed right away. If the mode change only affects the program (e.g. it's stored as a local flag), then what should happen if you single step a program? I can't think of a good solution other than rewriting all library routines so they work correctly in both RPN modes and warn users that their programs will break unless they pay attention to this.

Let's assume that the behavioural changes effect ENTER (and perhaps a few other functions), we could introduce a new opcode for it. Thereby, existing code would continue to function as is (interpreted in Classical RPN mode), without any necessary preconditions to be met or modes to be preserved and enforced for specific routines. If the calculator is in Classical RPN mode, it would store the old opcode in program memory, if it is in Entry RPN mode, it would use the new opcode instead. Programming outside the calculator, different mnemotics would have to be used for the two flavours, f.e. ENTER↑ and ENTER or something along that line, or the same mnemotic would translate to different opcodes depending on the mode of the assembler.

Greetings,

Matthias

[walter b]

Pauli will know for sure but IIRC the opcodes available are all spent for the WP 34S.

d:-/

[MarkHaysHarris777]

(02-20-2015 06:03 AM)Paul Dale Wrote:  Stack lift really is a legacy of the 1970's. So is LastX.

The big question is, how could it be done better today?

- Pauli

hi Pauli, we are enjoying the fruits of your labor; especially me, you have no idea-- again VERY nice job! Now to your question.

The answer is 'implicit' vs 'explicit'. Well, voilà.

Explicit is always better than implicit... always. Please allow some pedantic explanation, I think it will illustrate the point, and actually be helpful. [ENTER] should 'enter' from an input buffer, or command line, into the X register by default (and that's all). If a value needs to be placed into the Y register, the operation should be explicit; there should be a [STACK↑] operation that explicitly 'lifts' the stack; if the user wants it! But, and here is the BIG but, stack 'lift' should never be implicit (within an operation). Automatic stack 'lift' is ~ok, but unnecessary as long as we're processing from an (input buffer) command line.

There should be three enter keys (gold key enter) for 'entry' into Y directly (no implicit lift). There should be a (blue key enter) for 'entry' into Z directly (no implicit lift). And of course [ENTER] should 'enter' into X directly with no implicit lift of the stack.

There should be a set of buttons [↑] [↓] [↔] [↕] that change the 'relative position' within the stack of a given selected (displayed) register in the stack (this should always be explicit, never implicit).

Well, again, Voilà!

PS I thought everyone might enjoy reading, The ZEN of Python, by Tim Peters:

The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit. <=========== (my point)
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!



Cheers,
marcus

[MarkHaysHarris777]

As an addendum to my previous post, and to be complete:

Unary operators are 'explicit' special purpose 'enter' keys.

In other words, as an example, the [+] key does three things explicitly (by definition) in the new setup (internally):

1) presses the 'enter' key {command processing, 'enters' from input buffer into X}

2) operation {adds Y into X}

3) 'drops' the stack


PS There should be a key (op code) that toggles the auto 'lift' or 'drop' explicitly. We toggle auto drop 'off' for situations where we want constants (constant in Y). We toggle auto 'lift' off when we want explicit control over register manipulation (mostly in programming mode).



Cheers,
marcus

[Thomas Klemm]

(02-20-2015 09:03 PM)MarkHaysHarris777 Wrote:  2) operation {adds Y into X}

3) 'drops' the stack

An now you've lost your result. I assume you want to add X to Y. Or then subtract X from Y.

Cheers
Thomas

[BarryMead]

(02-20-2015 09:42 AM)matthiaspaul Wrote:  

(02-19-2015 01:51 PM)Bit Wrote:  I'd expect trouble with library and user programs. If they change the RPN mode and get paused or interrupted, it'd be a major source of confusion for the user if the ENTER key suddenly works differently, especially as it may not be noticed right away. If the mode change only affects the program (e.g. it's stored as a local flag), then what should happen if you single step a program? I can't think of a good solution other than rewriting all library routines so they work correctly in both RPN modes and warn users that their programs will break unless they pay attention to this.

Let's assume that the behavioural changes effect ENTER (and perhaps a few other functions), we could introduce a new opcode for it. Thereby, existing code would continue to function as is (interpreted in Classical RPN mode), without any necessary preconditions to be met or modes to be preserved and enforced for specific routines. If the calculator is in Classical RPN mode, it would store the old opcode in program memory, if it is in Entry RPN mode, it would use the new opcode instead. Programming outside the calculator, different mnemotics would have to be used for the two flavours, f.e. ENTER↑ and ENTER or something along that line, or the same mnemotic would translate to different opcodes depending on the mode of the assembler.

Greetings,

Matthias

The deeper one gets into this proposed feature the more one realizes that it ISN'T TRIVIAL. A detailed specification of how the stack and it's lifting operations work is ESSENTIAL before any REAL progress can be made in implementing the code. Specifically every key on the keyboard, every shifted key on the keyboard, and every catalog accessed operation has a potential affect on the numbers in the stack and weather or not the next numeric key pressed should lift, or (not lift) the stack. These all need to be spelled out EXPLICITLY, and it isn't simple or trivial to evaluate and choose the correct behavior for each case. And asking the developers of all library and XROM functions to include special compatibility checks so that the new Entry modes won't break their existing programs is a big ASK.

[MarkHaysHarris777]

(02-20-2015 09:27 PM)Thomas Klemm Wrote:  

(02-20-2015 09:03 PM)MarkHaysHarris777 Wrote:  2) operation {adds Y into X}
3) 'drops' the stack

An now you've lost your result. I assume you want to add X to Y. Or then subtract X from Y.

In my system 'lift' and 'drop' do not include the accumulator X. In other words, X never drops away... T drops into Z, Z drops into Y, X is left alone.

Also, auto 'lift' is a state which is 'on' by default and must be explicitly 'silenced' or turned 'off'. There are times when the user will want to turn of auto 'lift' and enter into X leaving the Y,Z, & T regs alone. There are other times when the user will want the stack to 'lift' -- that is X replicates into Y, Y into Z, Z into T, and T into oblivion. Auto 'lift' should be configurable on|off and it should have a [key] to toggle it on|off as well.


The entire system should be 'explicit' and the entire system should be fully integrated... that is, the entire system (all op codes) should have ONE consistent interface to the stack... NO SPECIAL CASES or HIDDEN POLICIES. NO EXCEPTIONS.

Cheers,
marcus

[eri]

Been away from this site for a while and came by to see what was going on on the 'rpl style' front. Found this recent thread and figure it can't hurt to give it a +1.

I've been using the rpl style for a while on 48 and now 50 and have a habit of clicking enter and then realizing I want an intermediate value. Yeah I can put in a '0 +' but it sort of freaks me out when I'm in the zone and am remembering the state of the stack. It would be nice to have back the choice of hitting enter or not.

To my compiler-writer mind the rpl style seems so natural but reading this thread there's others that disagree with more passion than I've got in me.

I'm hugely impressed with the wp34s. Fantastic software, its really the strict rpn that irks me every so often.

Thanks I love you all!

PS, here's my old thread wondering why there isn't an rpl mode:

http://www.hpmuseum.org/forum/thread-159.html

[walter b]

(02-28-2015 12:56 AM)eri Wrote:  I'm hugely impressed with the wp34s. Fantastic software, its really the strict rpn that irks me every so often.
...

PS, here's my old thread wondering why there isn't an rpl mode:
http://www.hpmuseum.org/forum/thread-159.html

Eri, thanks for your kind words. Reasons, however, didn't change in the last 12 months. WP 34S is strictly classic RPN. WP 31S as well. They will remain this way as long as I'm responsible for their UI.

Anyone prefering RPL feel free to create an RePeLlent calculator. I won't.

d:-)

[BarryMead]

(02-28-2015 08:18 PM)walter b Wrote:  Eri, thanks for your kind words. Reasons, however, didn't change in the last 12 months. WP 34S is strictly classic RPN. WP 31S as well. They will remain this way as long as I'm responsible for their UI.

Anyone prefering RPL feel free to create an RePeLlent calculator. I won't.

d:-)

I completely agree with Walter on this one. I own a TI-85, an HP-50g and several WP-34s calculators. I personally never use the HP-50g because it's interface is not as logical, intuitive, clean, and well planned as the WP-34s's user interface. Walter and Palui did a superb job of making the WP-34s capable, and intuitive! This is no small task. Sure the HP-50g has tons of functions, but they are not easy to remember or use. I know I am going to catch hell for saying this, but it seems to me that the HP-50g was designed by a committee rather than a single well organized mind. They threw everything but the kitchen sink into the HP-50g calculator, but it isn't consistent, logical, well organized, or intuitive. I have to watch training videos and read the manual for hours just to make it do simple things. With the WP-34s you can make it do all of the standard simple things without even opening the manual, and the well organized IOP in the manual makes it easy to look up the exotic functions when you need them. When I really need a graphing calculator, I prefer to use the less capable TI-85 to the HP-50g, because it has a logical intuitive user interface. Also I have a Linux desktop emulator for the TI-85 and can't find one for the HP-50g.

[Marcio]

With all due respect but, I could say the same about all HP pocket calculators. They are just too hard for me. I have tried to use a few (the emulator version) but nothing came out of it. I could not even do simple things. On the 50g, on the other hand, which I have had since 2009, I can do lots of stuff and cook at the same time.

So I guess it all depends on how committed you are willing to be, and of course, what kind of math you deal with.

Marcio

[BarryMead]

(02-28-2015 10:56 PM)Marcio Wrote:  With all due respect but, I could say the same about all HP pocket calculators. They are just too hard for me. I have tried to use a few (the emulator version) but nothing came out of it. I could not even do simple things. On the 50g, on the other hand, which I have had since 2009, I can do lots of stuff and cook at the same time.

So I guess it all depends on how committed you are willing to be, and of course, what kind of math you deal with.

Marcio

And perhaps it depends on how one's mind is wired. To me the HP-50g seems illogical and non-intuitive, and is just as hard to use when I go back to it as it was the first time I tried to use it. To those who love it, it is wonderful. I grew up with the HP-35 and fell in love with RPN. So my mind is wired that way. For us old timers the WP-34s is a welcome return to the olden days, and provides a familiar user interface that has long been missed. I am sure that when the RPL calculators have been missing from the scene for a while enthusiasts will revisit their favorite user interface with a custom community organized open source project.

[Marcio]

(02-28-2015 11:34 PM)BarryMead Wrote:  And perhaps it depends on how one's mind is wired.

Certainly Sir. And if you don't mind my asking: Are you a mathematician?

Marcio

[BarryMead]

(02-28-2015 11:42 PM)Marcio Wrote:  

(02-28-2015 11:34 PM)BarryMead Wrote:  And perhaps it depends on how one's mind is wired.

Certainly Sir. And if you don't mind my asking: Are you a mathematician?

Marcio

No, I am a digital electronics engineer, and software developer. I spend most of my time designing real-time automatic control systems utilizing micro-controllers combined with custom digital/analog hardware to interface with the real world.

[Thomas Radtke]

Interesting view on the RPL operating system and the G-UIs. Apart from the programming language used, I find them rather easy and straight forward. E.g., on a 48G, you have integral, derivative and sum on the keyboard and enter arguments as you would write them down. The shift key functionality is also easy to remember, e.g. in unit calculations, I look at them as kind of nominator (top) and denominator (bottom). Not sure if anyone understands what I mean .

The dynamic stack is a little disturbing, but the extra entry line register makes operating it much easier. I bet it is also easier to implement.

But then I had a 50G in my hands for entering a single program only. They might have weaken the rigor of the UI, don't know.

[Marcio]

(03-01-2015 07:46 AM)Thomas Radtke Wrote:  The dynamic stack is a little disturbing, but the extra entry line register makes operating it much easier. I bet it is also easier to implement.

The very reason I prefer graphing over non-graphing calcs. Even the 50g's RPL can be a little tricky at times. Nothing compared to HPPPL which is a breeze. Combine that with a powerful processor and lots of RAM you'll see what I am talking about.

[MarkHaysHarris777]

(03-01-2015 01:02 AM)BarryMead Wrote:  

(02-28-2015 11:42 PM)Marcio Wrote:  Certainly Sir. And if you don't mind my asking: Are you a mathematician?

No, I am a digital electronics engineer, and software developer.

This is really the crux of the debate (how one's mind is wired, and I mean this respectfully).

Mathematicians will prefer a calc (if at all) that is algebraic (AOS or equiv) with pretty print which displays equations as they are written in a text book, or out on the whiteboard, with perfects preferably (absolute symbols like PI/2 rather than approximate decimals).

Engineers, on the other hand, are going to prefer RPN; especially OCD engineers (like me). We want control over our intermediate results, and we want to be able to verify what happened, and did it happen reasonably, and can be be sure of this! Also, we want it to be fast and as error free as possible--- RPN rules; if you're an engineer.

On the other hand, if you're a mathematician (if you want a calculating machine at all) it will be one that represents things automatically and mathematically (you're probably wanting to see parenthesis, if you're a mathematician). RPN would just drive a mathematician crazy... they might even think an RPN calculator was broken, and send it in for repair. :-}

Cheers,
marcus