Free42 NSTK ENTER behavior

[fqz]

Is there a reason for the modified ENTER behavior in NSTK mode other than that NSTK resembles RPL and ENTER behaves this way in RPL?

Off hand I can't think of an example that the RPL ENTER behavior performs more efficiently, though examples where the 42S ENTER is more efficient are obvious. Moreover, switching the behavior seems like it's more likely to cause programs to break between modes, and confuse people that have gotten used to the default Free42/HP-42S operation already. So unless there's a compelling reason for the behavior to be different in NSTK mode (e.g. as is definitely the case for ←), I'd expect it to be preferable to mirror the 4STK mode behavior.

[fqz]

Scratch what I said about program compatibility. I see now that it's not the functions that have changed, just the key mappings. But for the other reasons I'm still wondering if I'm missing something or if it would be better to keep [ENTER] mapped to ENTER to keep manual operation in NSTK mode consistent with 4STK mode.

[DM48]

I prefer the RPL enter. It makes it easier on me, a 48G user.

[fqz]

If I understand correctly, the reasoning for that behavior in RPL is that ENTER evaluates any RPL programs in the input buffer before placing the result on the stack. That's a convincing reason for the switch historically. Unless there's a plan to do something similar in Free42, I can't think of a need to make the same change. To be clear, I think being consistent with RPL users' expectations is a fair and good enough reason on it's own. I'm just wondering if I'm missing something deeper.

If I'm not mistaken, the choice of how to map [ENTER] could be offered in an app setting without causing any problems. I haven't thought about it much, but I think both mappings should be compatible with both 4STK and NSTK modes. Not that Thomas needs more feature requests

[Thomas Okken]

I'm not saying it would, but it might help if the request were accompanied by one or two actual examples of how ENTER is "more efficient" than DUP.

If it weren't for backward compatibility, I'd personally prefer the [ENTER] key to perform "end number entry if it is active, DUP otherwise" in both modes. ENTER requires one fewer keystroke if you want to type a number and then fill the stack with it, but DUP requires one fewer keystroke if you want to duplicate the number in X in order to start a new calculation with it, while keeping the old number as well, and that is something I do all the time.

Which mapping is better is a matter of taste and usage patterns. I'm sure a good case, apart from compatibility, could be made for the old mapping, although I haven't seen it here. But there is also the "I don't need more feature requests" angle: if I were to satisfy every request for UI customizability, the Preferences screen would have dozens of additional settings, which would have taken a lot of effort to implement. Even if the impact of a new setting on the simulator core is just to add a check for some flag somewhere, the impact on the simulator shell is to add a check box, maybe change the dialog's layout or placement, test the new layout to make sure there are no unforeseen side effects, test that the change of the state file layout is handled correctly, and then, repeat the whole dance four more times because the user interfaces for Android, iOS, Windows, MacOS, and Linux are all different and share almost no code.

If the UI were based on Qt, I'm sure a lot of the hassle would go away, but that would be a big project on its own, and I am sure it wouldn't eliminate platform-specific issues completely. I've done cross-platform UIs in Java, which has a very mature UI toolkit, and still there were OS-specific issues to deal with.

Adding preferences settings could also be made easier by implementing something like the about:config view in Firefox. Not visually attractive, but it gets the job done, and designed for programmers, enabling them to add settings by just writing a couple of lines of code linking a variable to a UI widget. But implementing that view would be a big effort too.

In short, the unsatisfactory but workable compromise is for me to be guided by my own ideas in these matters, and just say no to user requests most of the time, not because I don't sympathize but because life is too short. I do make exceptions but unless I agree with a request from the outset, I tend to be very hard to convince. The only occasions I specifically remember implementing preferences settings that I didn't personally care about were for turning off auto-repeat (because of a user with arthritic hands who simply couldn't tap keys quickly and so was getting unwanted auto-repeating all the time) and haptic feedback (which for some people is a hard requirement while for me it is something I hate with a fiery passion).

I hope that clears things up. No hard feelings!

[fqz]

(03-07-2021 03:45 PM)Thomas Okken Wrote:  I'm not saying it would, but it might help if the request were accompanied by one or two actual examples of how ENTER is "more efficient" than DUP.

I'm talking about pretty small day to day stuff I thought was well known in the RPN/RPL debate:

Math: 2+2
RPN: [2] [ENTER] [+]
RPL: [2] [ENTER] [ENTER] [+]

Math: 2*Sin(2)
RPN: [2] [ENTER] [SIN] [*]
RPL: [2] [ENTER] [ENTER] [SIN] [*]

Quote:but DUP requires one fewer keystroke if you want to duplicate the number in X in order to start a new calculation with it, while keeping the old number as well, and that is something I do all the time.

Interesting! I thought with a calculator like the 42 where every function auto-terminates entry, there was no advantage to terminating entry without duplication. I don't track exactly what you're saying, but you've got me intrigued. Can you provide a keystroke example like above where the RPL-style [ENTER] behavior has less keystrokes?

[Thomas Okken]

The examples you give only take one fewer keystroke with ENTER than with DUP if you do them right after entering a new number. If you want to double an already existing number, it's DUP +, no different from ENTER +. If you want to multiply an already existing number by its sine, it's DUP SIN *, no different from ENTER SIN *.

Conversely, converting an already existing number from Fahrenheit to Celsius while also keeping the original: with DUP, it's DUP 32 - 1.8 /, while with ENTER, it's ENTER ENTER 32 - 1.8 /.

[fqz]

(03-07-2021 04:29 PM)Thomas Okken Wrote:  The examples you give only take one fewer keystroke with ENTER than with DUP if you do them right after entering a new number. If you want to double an already existing number, it's DUP +, no different from ENTER +. If you want to multiply an already existing number by its sine, it's DUP SIN *, no different from ENTER SIN *.

Conversely, converting an already existing number from Fahrenheit to Celsius while also keeping the original: with DUP, it's DUP 32 - 1.8 /, while with ENTER, it's ENTER ENTER 32 - 1.8 /.

Ho! That's what I was looking for, thanks!

Now that you mention it, I do remember being annoyed by this before when I first switched to the 42. I guess it's been a while since I've run into it.

It occurs to me that you could reap the benefits of both behaviors by having [ENTER] perform ENTER when entry is not terminated but perform DUP when it is (i.e. it always duplicates, and it decides whether or not to clear stack lift depending on if there was unterminated input), but then we're sure to confuse someone!

I hear you on the feature requests. It's gotta be a nightmare keeping this project up and running solo on the side. Thanks again, and keep up the good work!

[Thomas Okken]

(03-07-2021 05:38 PM)fqz Wrote:  It occurs to me that you could reap the benefits of both behaviors by having [ENTER] perform ENTER when entry is not terminated but perform DUP when it is (i.e. it always duplicates, and it decides whether or not to clear stack lift depending on if there was unterminated input), but then we're sure to confuse someone!

I think that's a brilliant idea, but yes, I can also see it causing a lot of confusion. I have a feeling it would take me quite some time to get used to it myself.

[fqz]

(03-08-2021 12:03 AM)Thomas Okken Wrote:  I think that's a brilliant idea, but yes, I can also see it causing a lot of confusion. I have a feeling it would take me quite some time to get used to it myself.

I don't fully understand how the input cursor, stack lift flag, and such really work at a low level, but I think it actually works out pretty elegant: [ENTER] would just execute a function that duplicates and pushes onto the stack, leaving the stack lift flag unchanged from whatever it was.

The devil is that no RPN calculator I can think of, hardware nor software, implements such a behavior! It's funny, because the two primary alternatives we've discussed both seem to create redundant situations where a keypress that has no useful application of its own is required at some point. In Classic RPN there's no reason I can think of to execute ENTER only once on a terminated stack (existing result / stack lift enabled) as opposed to DUP. Meanwhile in Entry RPN / buffered input / RPL, there's no reason to terminate a final input with [ENTER] except for comfort unless you're working on a machine that is going to evaluate code in your input or offers some other special functionality I'm not considering. But, I've been shown to overlook things already! Haha

[Werner]

ENTER and DUP are available in both 4STK and NSTK mode.
The point is: why make the ENTER key perform DUP in NSTK mode? The same 4-level stack calculation cannot be carried out the same way now, as you have demonstrated with the °C-°F conversion.
Why not make it a setting? NSTK ENTER key = ENTER or DUP.. everybody happy ;-)
Werner

[rprosperi]

I get the point Thomas made about the tendency to add too many options and generally agree, as you don't want to end up like the Prime where most examples can't be followed without first confirming 5-10 settings, but in this case I agree with Werner. NSTK really needs Enter/DUP behavior to feel like proper RPL entry, and the same is true for pure Enter for RPN.

OTOH, perhaps Enter/DUP behavior should automatically be enabled when NSTK is selected, and disabled when 4STK is selected.

Is there any reasonable need to have them be independent? One could likely contrive a scenario that somehow answers this 'yes', but as it doesn't exist elsewhere, is there really any justification to do that here?

Note: arguably the 20b/30b are close to this, but it seems highly unlikely that any 20b/30b user would be upgrading to Free42...

[Thomas Okken]

(03-08-2021 01:33 PM)rprosperi Wrote:  OTOH, perhaps Enter/DUP behavior should automatically be enabled when NSTK is selected, and disabled when 4STK is selected.

That's the way it works now. In 4STK mode, the ENTER key executes the ENTER function, with the usual classic ENTER behavior of X duplication plus stack lift disabling, while in NSTK mode, the ENTER key terminates number entry mode if it is active, not executing any function, and executes the DUP function if number entry is not active. The idea being to emulate the ENTER key behavior as it exists on the RPL calculators.

[rprosperi]

(03-08-2021 11:56 PM)Thomas Okken Wrote:  

(03-08-2021 01:33 PM)rprosperi Wrote:  OTOH, perhaps Enter/DUP behavior should automatically be enabled when NSTK is selected, and disabled when 4STK is selected.

That's the way it works now. In 4STK mode, the ENTER key executes the ENTER function, with the usual classic ENTER behavior of X duplication plus stack lift disabling, while in NSTK mode, the ENTER key terminates number entry mode if it is active, not executing any function, and executes the DUP function if number entry is not active. The idea being to emulate the ENTER key behavior as it exists on the RPL calculators.

Sorry, I guess I missed one of the hops of the bouncing ball... I say leave it as it is!

Has anyone come up with a meaningful (not contrived to make a point) reason why it makes sense to have these behaviors separated? Doing so will certainly lead to confusion and false error reports, whereas the two traditional modes (RPL-ish and RPN) will likely be comfortably used by fans of both religions without confusion.

[Steve Simpkin]

I agree with Thomas. Someone using NSTK would probably be familiar with the way Enter works with the unlimited stack on the RPL models and would expect Enter to work the same way here. It is perfect the way it is.

[Massimo Gnerucci]

This looks to me as the perfect culprit as seen on many episodes of Air Crash Investigations. ;)

[Werner]

I seem to be in the minority, but I will try once more ;-)
RPL entry makes sense on an RPL machine; the 48 and successors did not have a 4STK mode or RPN mode.
Free42 is an RPN machine, a 42S with extensions. Why would it need to work differently in 4STK and NSTK mode? I for one never do
2 *
but always
ENTER +
In Program mode, there is no problem, I can chose between DUP and ENTER, but in interactive mode, it is (In My Humble Minority Opinion) confusing to change the basic behaviour.

Cheers, Werner

[Massimo Gnerucci]

(03-09-2021 07:53 AM)Werner Wrote:  In Program mode, there is no problem, I can chose between DUP and ENTER, but in interactive mode, it is (In My Humble Minority Opinion) confusing to change the basic behaviour.

Exactly.

[Thomas Okken]

I am a bit surprised that anyone would find the ENTER/DUP thing confusing, I implemented it because to me, the unlimited stack and the ENTER key terminating number entry or performing DUP just belong together. It's like saying voiture in French and calling the same thing auto in Dutch, it's different but it just fits.

But I can't deny that it is inconsistent within the context of an HP-42S simulator.

Oh well. There is plenty of room in the 5th row of the MODES menu to add another toggle!

[fqz]

(03-09-2021 01:14 AM)Steve Simpkin Wrote:  I agree with Thomas. Someone using NSTK would probably be familiar with the way Enter works with the unlimited stack on the RPL models and would expect Enter to work the same way here. It is perfect the way it is.

Since the topic of emulating RPL behavior was mentioned, I'm curious, does anyone have an example off-hand of an RPL calculator that enters input directly onto the "1:" level of the stack instead of an intermediate, anonymous input buffer?

That's what NSTK does, which is already a sort of odd hybrid I think, but admittedly it is unlikely to cause any change in practical behavior as opposed to the [ENTER] mapping, especially on a calculator like Free42 that doesn't support program entry in the main mode. FWIW I happen to like this divergence from RPL in the NSTK implementation and it definitely seems like the right choice here, all things considered.