DM-42 and WP-43S

[Luigi Vampa]

@Bob, as always, you've nailed it :0)

@c785, I love both, my ol'reliable HP28s, and Free42. Nevertheless, I have some mixed feelings about my HP48sx: somewhat cluttered for my taste, but one man's trash is another man's treasure. The good news is you always may find someone close to your thinking in this forum.

[Massimo Gnerucci]

(04-04-2017 03:43 PM)c785 Wrote:  I'm new to this forum, but not to HP, having got through university (and beyond) on an HP48G extended to 128kB.

I recently discovered WP34s, that's why I came here, and I'm in fact going to own one soon. Playing around with the simulator (as well as with Free42) I discovered that I don't quite understand why people love these machines so much, apart from the "geek factor": just those two lines in the display with X: and Y: on the 42 should put almost everybody off immediately. I'm not new to keypress programming, having had a chance to write some serious stuff in the 99 (cryptic!) steps offered on the HP20s, but that's another story because it isn't RPN.

What I don't get is why nobody considered actually adapting to the possibilities of new hardware. Faster processors and matrix LCDs would be ideal for:

1. fixing the RPN logic, which is somewhat weird on the 42 and WP34s (when exactly to press ENTER and when not); in fact, the HP48 has already done it.

2. fixing the fixed-size stack, also done on the HP48.

3. replacing keypress programming and its labels and gotos with RPL or similar for a much more robust and scalable programming experience. Again, the HP48 is miles ahead of everything else in this respect. Actually, it isn't even that different from keypress programming as far as program entry is concerned.

So, why isn't there any need for HP48-like features on the DM42, and why is exact HP42 compatibility such a high priority? I'm not talking about graphing, just the stack logic and programming.

Since you asked... Simple: RPL sucks.

;)

[c785]

Thanks for your answers, guys, I'm sure I'll be enjoying the WP34s. In fact, the prime reason for getting (well, making) it is to have something new to get used to, plus the "bling" factor of all those colours on the overlay, and of course the nobody-really-needs-this nerds' stuff I have a local reputation for.

I agree that in some aspects the 48G is rather cluttered, but I always found the hierarchial storage of variables and programs very useful, just to name one thing. Physical units (and the constants carrying them) are great as well, I use them all the time. Compared to this, the WP34s is a bunch of workarounds: complex numbers are dealt with by combining two levels of the stack, for instance.

Nevertheless, I can't wait to get the WP34s up and running, it'll be fun for very different reasons than the 48G.

[rprosperi]

(04-04-2017 07:58 PM)c785 Wrote:  Thanks for your answers, guys, I'm sure I'll be enjoying the WP34s...

Nevertheless, I can't wait to get the WP34s up and running, it'll be fun for very different reasons than the 48G.

Suggest you also order the V3.3 book (search old threads here, you'll find the links). In addition to being almost necessary to learn to use many of the 34S's enormous catalog of features, it also includes RPN and HP machines' history and other topics of interest to any user of this machine. Also, look for the 34S Quick Ref Guide; you can download and print/make your own.

[c785]

Thanks, Rob, for the suggestions. In fact, I've read most of what you referred to, in particular, I'm aware of the history of RPN.

Now what I don't get is this, on Free42 (and I don't think it's a bug in Free42): I'd like to divide a number (100) by another (5), then divide that further by another (2), but make sure that the first result (100/5) is kept on the stack for further processing.

So I do this: 100 ENTER 5 / ENTER 2 /

Which, incidentally, results in exactly the same stack as doing this: 100 ENTER 5 / 2 /

Neither keeps the intermediate result.

In order to get what I need, I need another ENTER: 100 ENTER 5 / ENTER ENTER 2 /

To be honest, I really don't get it. This has nothing to do with the (controversial) logic of dialing new numbers directly into X, which is probably easy to get used to. Note that the final division starts out with different stacks in the first two cases but delivers the same result. If this isn't a bug, what good is this "feature"?

Am I missing something really important?

[bhtooefr]

Yeah, that's not a bug in Free42 - my 41CX behaves the same way.

Actually that does seem somewhat logically inconsistent that Enter isn't causing a stack lift when done after, say, a division...

[c785]

Another one: apparently, there's no easy way of telling what's going to happen when you enter a number and the currently displayed value of X is 0.

Do this: 1 2 - 5

Or this: 1 2 - BACK 5 (BACK is the "<-" key)

Before typing 5, the stack looks exactly the same, nevertheless the first example results in 5, 0, and 1 on the stack, the second one results in 5 and 1 only.

Whoever said RPL is rubbish is absolutely right: it's no match for this geeky incosistent logic. Any idiot can use an HP48, real men use the 42.

[Paul Dale]

The stack lift flag is a residual from the early days when there wasn't enough memory to allow the entry of a new number without destroying one of the registers. You were entering the number directly in the X register.

It isn't a bug, it is as designed and intended. It isn't the enter after the division that isn't causing the stack lift, it is the digit entry after the enter.

After the divide, the stack will contain 20 and the stack lift flag is set.
After the enter, the stack will contain 20 20 and the stack lift flag is clear.
After the 2, the stack will contain 20 2 (the 2 replaces the 20 because of the clear stack lift flag).
After the divide, the stack will contain 10 and the stack lift flag will be set.

The stack operation is logically consistent, just with a rule or two you weren't aware of. The system works well which is why people still want it. The number of operations that clear the stack lift flag are small: enter, %, sigma+, clx and each one makes sense preventing stack lift.

The 34S does have an input buffer which allows you to begin digit entry and backspace out without changing the stack but in all other ways it supports the stack lift flag's operation.


- Pauli

[Paul Dale]

(04-05-2017 09:34 AM)c785 Wrote:  Do this: 1 2 - 5

Or this: 1 2 - BACK 5 (BACK is the "<-" key)

Are you pressing ENTER after each digit?
1 enter 2 enter - 5 would leave 5 0 1 on the stack.
1 enter 2 enter - Clx 5 would leave 5 1 on the stack.

This is sensical, Clx (backspace) zeroes the X register and disable stack lift. When you enter 5 it replaces the 0. Without this, you'd never be able to make a correction to an input.


- Pauli

[bhtooefr]

Aha - it'd require more code to leave the stack lift flag set if the enter is after an operation, instead of after digit entry - a test to see which happened - so that's why it always clears it. Fair enough.

In any case, it does feel logically inconsistent with the idea that Enter should duplicate whatever's in X, but there's an understandable technical reason for it on the older calcs. (That said, now I kinda want to see something that isn't trying to be implementation quirk-exact with HP calcs try stack lifting if Enter is used after an operation, but otherwise follow classic RPN behavior - I suspect that'd be faster to use than either classic RPN or Entry RPN/RPL.)

[c785]

(04-05-2017 09:48 AM)Paul Dale Wrote:  Are you pressing ENTER after each digit?
1 enter 2 enter - 5 would leave 5 0 1 on the stack.
1 enter 2 enter - Clx 5 would leave 5 1 on the stack.

This is sensical, Clx (backspace) zeroes the X register and disable stack lift. When you enter 5 it replaces the 0. Without this, you'd never be able to make a correction to an input.


- Pauli

Yes, sorry, there should be ENTER after the "1" in both cases, but not after the "2".

Still, given a 42 with "X: 0" in the bottom line, you can't tell what's going to happen when you start typing. I was aware that there must be a flag for that, but that flag is invisible.

[Paul Dale]

(04-05-2017 11:02 AM)c785 Wrote:  Still, given a 42 with "X: 0" in the bottom line, you can't tell what's going to happen when you start typing. I was aware that there must be a flag for that, but that flag is invisible.

Being expected to remember your last operation isn't a big ask


Pauli

[emece67]

Pressing x<>y twice you get the stack untouched and you do know what will happen after the next keystroke.

I use it frequently.