35S vs 30b Stack



#29

Hi all!

I have a question regarding 35S vs 30b stack operation.

If I am not totally confused, these two calcs do not have the same stack. 35S just has X, Y, Z and T levels, while 30b also has a "hidden" command line. For example:

In 35S, to add 1+2 you press:
1 [enter] 2 +

In 30b, you have two options:
1 [input] 2 +
OR
1 [input] 2 [input] +

So, 30b is like a 50g with just 4 levels??? Am I correct? This is confusing me a bit, any clarification would be most welcome.

Regards,

Alex


#30

Yes, the 20b and 30b calculators don't let you edit the x-register directly, i.e., there's an additional register.


#31

We had the discussion on the 34S recently. Internally it would have been easier for us to get rid of the whole stack lift business and do it the 30b way (which I actually prefer) but the community decided against this. 34S behaves like the old RPN calculators do. Maybe this is the reason why we spell it 34S and not 34s.


#32

We print WP 34S RPN SCIENTIFIC on it. So it simply must be 100% pure RPN :-)


#33

Quote:
So it simply must be 100% pure RPN :-)

It's got nothing to do with that.

It's simply because old peole want it the way they are used to it. Old habits die hard etc. etc.

It was implemented like that in the first 35 where the X-register is used as the input register as well, maybe because memory was expensive or because it fitted the CPU construction better. The 28/48/20/30 approach is actually a more sensible approach and easily implemented in modern technology. But because many had learned RPN the original 35 way, they are set in their ways and do not like change, so they feel they have the right to call it "true" RPN.

And this is my 2p worth ;-)


#34

I think that part of the issue here is the multi-line display of the RPL calculators. I can see what is on the stack and am not surprised by the resulting operation. This is not true for the 20b and the 30b and maybe it is just habit but I do make mistakes with those calculators. For example one of the operations I am very used to is something like 2 ENTER + to double a number or 2 ENTER * to square a number. These won't work on the 20b/30b or the 48 machines. As far as I am concerned that is ok for the 48 machines because I can see what is happening and I am not going to perform an ADD or MULTIPLY with one item on the stack. RPN is utterly different--the stack is always there and if not specifically set to a value will have all values set to 0. You can operate on an "empty" stack in RPN but not RPL. These differences mean that for (IMHO anyway) each type of calculator (multi-line vs. single-line display) the chosen paradigm works best.

I agree that stagnation does not benefit anyone and the 48 series are a great example of that. They moved to a new stack paradigm because they had a much more powerful unlimited stack available to them.

To each there own, but the way I see it is that a multi-line display makes better use of RPL while a single-line display makes better use of RPN. What the 20b and 30b appear to implement is a 4-level RPN stack with an RPL entry paradigm. I would also argue that an unlimited RPL stack with an RPN entry paradigm would also be "wrong".

Again, just my 2 cents.

Cheers,

-Marwan

#35

Interestingly, the 34S's input isn't true to the RPN ideal. The 34S has a command line buffer for input and keystrokes go there first and can be backspaced or deleted entirely with no impact on the X register. Once ENTER is press all the stack magic happens.

As Marcus noted, supporting stack lift/suppression of stack lift is a right pain to get just right.


- Pauli


#36

Quote:
The 34S has a command line buffer for input and keystrokes go there first [...]
Wouldn't it be easier to keep a copy of x (if really needed) and edit x directly? This would remove all inconsistencies. You're programming as if you would implement RPL but mimick RPN :-/.

#37

I don't think this is a harder path. In many ways it is simpler than editing values in X directly. The stack lift issues are mostly separate from the entry of data into X. Other things than ENTER (like Sigma+ e.g.) disable stack lift. Also, there are zero free states in our registers to store extra information like the second decimal for fraction entry.

The 34S maintains a text buffer of what the user has typed and only parses it at the end. This makes handling most anything pretty easy. Of course we've paid a RAM cost for this but that is in the LCD buffer memory and isn't cutting into the 2kb of persistent RAM.


If there are any inconsistencies apart from preserving X when the entry line is deleted, please let me know.


- Pauli

#38

Maybe this is asking too much, but is it possible to develop and release RPN and RPL firmwares for the 34S? Then people can pick what they want.


#39

Even better would be a user selectable RPN/RPL mode.
Then the RPN annunciator would actually have meaning. :-)

I'm fine with things as they are, but clearly there are those that would prefer the RPL method. Given the limited available memory I doubt we'll see such a user selection appear.

I don't know if the code is such that the evaluation and stack lift logic is centralized thereby making a conditional compile even feasible, or if the RPN/RPL impact is more scattered. Only the WP-34S developers can tell us that.

Something tells me that if this had been easy that it would probably already be there.

Edited: 14 Sept 2011, 10:50 a.m.


#40

Quote:
Even better would be a user selectable RPN/RPL mode.
Then the RPN annunciator would actually have meaning. :-)


Second that! I'd like if I could just disable the whole "stack lift disabling" thing... I really make many mistakes with "pure RPN" because I'm used to RPL...

Cristian

#41

It would be possible if we had another state bit left in memory for the purpose. I'd prefer to get rid of all the stack lift business altogether which would save some code space.

The RPN annunciator has recently acquired a new use: It goes off for any temporary display.

#42

Quote:
Interestingly, the 34S's input isn't true to the RPN ideal. The 34S has a command line buffer for input and keystrokes go there first and can be backspaced or deleted entirely with no impact on the X register.

How is this different from any HP that has the <= (backspace) key?

#43

One difference: Take an HP-41 or your new HP-15C LE and enter a number onto the stack. Then start entering a second number. Change your mind and back-space all the way. On the 41, 42, 15, you get '0' on the stack. On the WP34S you get the number you entered first.

Cheers,

-Marwan

Edited: 14 Sept 2011, 11:02 a.m.

#44

Why is the RPL approach easier? It is inconsistent, imo.


#45

:-) That's what I think as well. Now duck and cover [:-)


#46

Well said! Being consequent with one's ideas is what distinguishes great products from the pack, and this is an RPN fundamental I'm afraid.


#47

Quote:
Well said! Being consequent with one's ideas is what distinguishes great products from the pack, and this is an RPN fundamental I'm afraid.

And unwillingness to change has been the downfall of many a great company too.

#48

Quote:
And unwillingness to change has been the downfall of many a great company too.
Hi Bart,

the problem with PRL is you don't know *how* things are implemented. 1 ENTER 2 + gives the same result as 1 ENTER 2 ENTER +. This is very confusing, since you would assume from the first action that x is edited, and thus the latter should give 4, which is not the case on RPL machines.

Sometimes a secret stack lifting has to happen in RPL, such as when an operator is used while editing a number. *That's* inconsistent.

I see no disadvantage with RPN, but one huge advantage: Transparency of operation.

Thomas


#49

I am no big fan of RPL, but come on! The RPL stack is not strange at all, it is just different to a 4-level RPN stack.

ENTER ends input (and checks that it is correct). If you perform a operation, it terminates entry (performs an implicit ENTER) before performing the operation. I cannot see how that is strange. What else should it do, throw the value just entered away?

In addition to this, you have visual feedback of the top levels of the stack and can see what is going on, something you seldom have on an RPN machine.

I have seen more than one newbie to RPN typing 1 ENTER 2 ENTER + only to get 4 (wrong result). You ENTER the first number, why should you not ENTER the second? Instead, ENTER makes an extra transient copy of the number, now that is confusing to a newcomer.


#50

Quote:

I have seen more than one newbie to RPN typing 1 ENTER 2 ENTER + only to get 4 (wrong result).


That happened to me many times! :) Unluckily many times it wasn't obvious what had happened, and it took me some time to track back the error in my calculation...

Cristian

#51

I started HP life with the 28S, and there's nothing inconsistent in the RPL stack operation. Actually it is more consistent.



Sorry Thomas, you don't seem to understand the fundamental difference. As I said in my reply to Walter's post, the old RPN stack used the X-regiter as an input register as well. Therefore, when you hit Enter, the value is copied into the Y-register, why?, because for the next entry, the X-register is overwritten because it is the input register. The so-called RPL stack has a separate input register, that is why the need to copy the input value to the Y-register is not necessary when hitting Enter. The input register only exists during input (for obvious reasons), so hitting '+' operator with an input active, operates on the input and first stack item. When there is no active input, hitting '+' operator operates on the first stack item and second stack item.

Quote:
This is very confusing, since you would assume from the first action that x is edited, and thus the latter should give 4, which is not the case on RPL machines.

I hope my explanation makes it clear that X is not edited, why it's not necessary & what it is doing.
Quote:
Sometimes a secret stack lifting has to happen in RPL, such as when an operator is used while editing a number.

How so? As I explained, when input is active, the input register is used as the first argument (or the only argument in a 1 argument operation).
Unless you are actually referring to editing the first stack line after it was entered - then you have effectively removed the item from the stack and it will only be put back when you finish editing. SO, if you use an operator while edit is active, it will work on whatever was above the item being edited, because that item was removed from the stack while editing. You can't complain about this behaviour, because such a mode did not exist on RPN calculators anyway.
Quote:
I see no disadvantage with RPN, but one huge advantage: Transparency of operation.

You ENTER two numbers that you want to operate on, but end up operating on the last number AND a copy of the last number. That's transparent? I want numbers A and B, whether I hit ENTER or not. BEFORE hitting ENTER, a number is not on the stack. Now I to put both A and B on the stack, then operate. So after actually putting B on the stack (by hitting ENTER - it is not officially ON the stack until then), I now have a COPY of B in Y??? Now THAT's inconsistent, but because people have learnt to live with it, they call it consistent? or "the way"?

As you rightly commented, Pauli has to mimic the "RPN" behaviour using "RPL" type stack because people don't want to change, are unwilling to adapt, not moving with modern technology, etc. etc.

Again, as always, just my 2p worth.

Edited: 14 Sept 2011, 8:55 a.m.


#52

I never thought that I would start a holly war with this question, nevertheless, if you care about a beginner's point of view, and after having read all your thoughts, RPL now seems a bit more "logic" to me, since it can also work as RPN (by omitting the 2nd Enter, so no extra keystrokes are necessary). I find Bart's explanation quite reasonable, but I guess that since this has not been resolved in this forum for so many years, it will not be resolved now.


#53

Quote:
I never thought that I would start a holly war with this question...

It always does, and regardless of how many times it has been fought, a new post always gets it flared up again. That's passion for you :-)
#54

Wow. Now I think I finally understand this "stack lift" business. And I have to agree with Alex: the RPL method does make more sense. Thanks, Bart!


#55

RPL causes a waste of keystrokes. 2 ENT 2 X required to square a number (versus 2 ENT X). But it is also confusing, because the command line in RPL also functions just as it does in RPN for most things--in other words you don't have to do 2 ENT 2 ENT X.

I think really, they both are good. Nothing can be all things to all situations.


#56

Quote:
2 ENT 2 X required to square a number (versus 2 ENT X)

I think x2 is present on RPL calcs? It's usually a shifted function, so 2 SHIFT x2 is also 3 keypresses. :-)

#57

How about 2 ENT +?

#58

Quote:
Pauli has to mimic the "RPN" behaviour using "RPL" type stack because people don't want to change, are unwilling to adapt, not moving with modern technology, etc. etc.


Well I think you're giving a biased selection of reasons why people won't embrace the RPL stack style. I can also come up with some good reasons to STAY with the RPN stack.

BTW I faced many of these considerations implementing the 41Z Complex Stack - didn't have an easy life from the developper's standpoint either but I'm very happy with the result.


#59

Quote:
Well I think you're giving a biased selection of reasons why people won't embrace the RPL stack style.

Of course, I am always biased to my own liking ;-). And I just like to give the "oldies" a hard time ;-))

Each to his own actually, and though the WP-34S has the "older" style implementation, I still play with it.
#60

Quote:
Sorry Thomas, you don't seem to understand the fundamental difference. As I said in my reply to Walter's post, the old RPN stack used the X-regiter as an input register as well.
I wrote:

"Yes, the 20b and 30b calculators don't let you edit the x-register directly, i.e., there's an additional register."

It should be clear what that means. You just need to read what I wrote, Bart. It's not really kind to ignore or invert my contributions to come to your conclusions about my knowledge :-(.

To the point, and please w/o any rants:

RPN is competely consistent about ENTER where RPL is not. If, in my example above, a second ENTER is a NOP in the RPL world, something's wrong. It indicates special treatment where the internals of RPN are quite straight forward.

I think I'm done here in this thread. To discuss something isn't worth it if I'm (maybe deliberately) mistaken.


#61

RPL has a command DUP. RPN has not. Instead it has ENTER which makes a DUP and then causes the next entry to replace the lower stack level. This is kind of strange, isn't it?

#62

Quote:
"Yes, the 20b and 30b calculators don't let you edit the x-register directly, i.e., there's an additional register."



It should be clear what that means. You just need to read what I wrote, Bart. It's not really kind to ignore or invert my contributions to come to your conclusions about my knowledge :-(.

OK, I am sorry, I did not quite pick up on that.

Edited: 14 Sept 2011, 5:24 p.m.


#63

Ok, thank you, Bart.

#64

Quote:
Now duck and cover [:-)

Yep, see my comments to your earlier post :-)
#65

Thank you all for your answers.

I am not ready to form a definitive opinion about this, I am not sure which approach I actually prefer. The 30b approach subsumes the 35S way of operating (in all cases, I wonder?), therefore one would say: why not have both and choose?
On the other hand the 30b approach sometimes is confusing; do I press input for a second time or not? While in 35S you know you do NOT have to press Enter again.

Thank you again...


#66

There is one less keystroke, the 35s is nice, but I am suprised how nice the 42s is (ive had 1 day with it). I didnt think matrices could be so easy on a 2 line screen.

Hmmmmm

Quote:
Thank you all for your answers.

I am not ready to form a definitive opinion about this, I am not sure which approach I actually prefer. The 30b approach subsumes the 35S way of operating (in all cases, I wonder?), therefore one would say: why not have both and choose?
On the other hand the 30b approach sometimes is confusing; do I press input for a second time or not? While in 35S you know you do NOT have to press Enter again.

Thank you again...



#67

So, the 42s works like the 30b? You could optionally press the Enter key after inputting the 2nd argument? I only have a 32Sii, so I cannot know...


#68

Quote:
So, the 42s works like the 30b?

No.
#69

Quote:
So, the 42s works like the 30b? You could optionally press the Enter key after inputting the 2nd argument?

No, it has the "old" stack, like your 32Sii, except there is a two line display so you can see the Y-register. (Try Thomas Okken's Free42).
#70

Don't be surprised by the 42S it is (one of) the best RPN calculator.


- Pauli


#71

Bought it, couldn't get on with it, sold it.

Edit: my opinion as always :-)

Edited: 14 Sept 2011, 9:34 a.m.


#72

A real pity, you could have made many people happy here - well, just one of them, I admit ;-)

#73

I like both!


#74

How utterly unreasonable :)!

As do I actually, per an earlier post, I just don't like the RPN/RPL mix of the 20b/30b it is nether fish nor fowl.

To reiterate my earlier posting: A multi-line display using RPL entry syntax works fine for me. A 4-element stack machine (dare I say an RPN stack machine?) using RPN entry syntax also works fine for me. A 4-element (RPN?) stack using RPL syntax--not so much.

Again, as always, my 2c...

Cheers,

-Marwan


Possibly Related Threads...
Thread Author Replies Views Last Post
  HP 50g - select characters on the stack, copy/paste Sean Freeman 7 475 11-20-2013, 07:11 AM
Last Post: Sean Freeman
  Prime: Placing more than 1 item on the RPN stack in a single program? John Colvin 4 333 11-19-2013, 08:59 AM
Last Post: Miguel Toro
  emu48 - copy stack doesn't work (as expected) Thomas Radtke 2 344 11-11-2013, 02:19 PM
Last Post: Thomas Radtke
  HP Prime Stack operations from within a program John Colvin 1 215 11-08-2013, 09:45 PM
Last Post: Helge Gabert
  Prime: Anyway to refresh stack? kris223 5 332 10-16-2013, 05:09 PM
Last Post: kris223
  hp prime - sending program results to the stack giancarlo 6 384 10-15-2013, 02:00 AM
Last Post: Giancarlo
  HP Prime - RPN stack access from programs? Mike Mander (Canada) 10 427 09-30-2013, 11:20 AM
Last Post: steindid
  Flashing cable for HP 20 / 30B Stefan Koenig 3 304 09-19-2013, 05:53 AM
Last Post: Marcus von Cube, Germany
  Any 30b cables left? patryk 7 400 09-16-2013, 02:54 PM
Last Post: Marcus von Cube, Germany
  HP-30B (WP-34S) Technical Documentation Barry Mead 3 256 09-09-2013, 03:07 PM
Last Post: Harald

Forum Jump: