Free42 with big stack, test version

[Thomas Okken]

I'm leaning toward a declaration on line 01 that applies to the entire program. I think that will fit well with how people will use it in programs, that is, it doesn't seem likely people will want to mix four-level and big-stack within a program.

I'll have to rewrite FUNC and the L4STK/LNSTK logic, since they are currently meant to be called with FUNC coming first, and that will have to be reversed. It's not a big deal since most of the complexity happens at the end, when the effects of those functions are wrapped up during the RTN, and that logic would stay pretty much the same.

Making the big stack mode apply to entire programs will also work better when program execution starts with R/S or SST, because in those cases it would not be obvious which label would apply.

[Thomas Okken]

But maybe this is something that doesn't belong in the basic Free42 and should be reserved for Free42+. Regardless of what I do to prevent programs from running in the wrong mode by mistake, there will be a certain risk of confusion, and that might not go over well with the existing user base...

[rprosperi]

(02-05-2021 01:58 PM)Sylvain Cote Wrote:  

(02-05-2021 12:34 PM)Thomas Okken Wrote:  Or keep NSTK and 4STK, but make them non-programmable; eliminate LNSTK and L4STK; and add a new type of label, say, NLBL, so that LBL has the effect of L4STK and NLBL has the effect of LNSTK.
That way, legacy code is guaranteed to always run in four-level mode, regardless of the user's preferred interactive mode. And it is always obvious at a glance which mode any given program will run in.

Thomas,
IMHO this is the best route to take, I was going to suggest the same idea until I saw this post.
It's simple, the intention is clear and the compatibility with older program is guaranteed.
There are cases that will need to be addressed like: { LBL "L1" ... XEQ "L2" ... RTN } { NLBL "L2" ... RTN } or { NLBL "L3" ... XEQ "L4" ... RTN } { LBL "L4" ... RTN }
Sylvain

I agree this is a clever and self-documenting solution to prevent a program intended for one mode to run in the other, likely returning errors or worse, silently invalid results.

I was going to suggest using some bit(s) in the .raw file, but your suggestion is much better.

[rprosperi]

(02-05-2021 04:13 PM)Thomas Okken Wrote:  But maybe this is something that doesn't belong in the basic Free42 and should be reserved for Free42+. Regardless of what I do to prevent programs from running in the wrong mode by mistake, there will be a certain risk of confusion, and that might not go over well with the existing user base...

I think it's OK to include features like this as long as they are benign if ignored (i.e. never change expected result from a real 42S). If an experienced user (or intrepid noob) chooses to dabble with things like Big Stack, etc. they would have waded into deeper water and should be aware of the consequences. Using ideas like discussed above (differing LBL types) it's nearly inconceivable someone could accidentally run into trouble here.

[Marco Polo]

(02-05-2021 04:13 PM)Thomas Okken Wrote:  But maybe this is something that doesn't belong in the basic Free42 and should be reserved for Free42+. Regardless of what I do to prevent programs from running in the wrong mode by mistake, there will be a certain risk of confusion, and that might not go over well with the existing user base...

I appreciate a lot you efforts and i'm starting using Free42 more often than Emu48, thanks also to Werner's unit conversion programs (https://www.hpmuseum.org/forum/thread-10141.html) which partially satisfies my need (i miss the time to try some improvement, but thinking about it) and is fully configurable.
While i would greatly appreciate a bigger screen (i.e. showing all stack registers), i am starting having some concerns about "big" stack's implication and consequences.

In my experience with HP RPL, it is very unlikey to use more than 4 levels, unless stack is used to store object that would be more convenient to store in variables.
It seems to me that, with big stack and related implementation problems, Free42 is going to depart from the original HP42 concept and is starting to become a strange chimera between RPN and RPL.
Furthermore, the need to preserve backward compatibilty is making, imho, the usage a bit convoluted.

I am not sure if it will be attractive, being "sandwiched" between "classic" Free42 and Emu28/Emu48 (Emu28, provided that i have a legit rom image): if i need units, equations and bigger stack i can go with Emu28/Emu48 and enjoy a full coherent RPL environment, and wide choice of software to load.
If i prefer RPN i would go with Free42 as it is now, eventually with some more features like bigger screen, built in uom and eventually equations which could not impact the original and efficient HP42 concept.

The above considerations coming from a die-hard RPL user, who still cannot get used to the different behaviour of ENTER in RPN but appreciates a lot your work and would likely pay for a Free42+ or whatever :-)

[Thomas Okken]

After giving this some more thought, I think there are two major use cases here: one the one hand, people who are perfectly happy with the four-level stack and have no interest in the big stack feature, and on the other hand, people who like the big stack feature and could imagine using it occasionally.

The former would be best served by the big stack feature not existing at all. If it's not there, there's no chance of accidentally activating it and having programs fail etc.

The latter should understand how the differences between four-level and big stack mode affect programs, and thus understand the importance of making sure the appropriate mode is used for any given task.

I don't think there is much value in safety features, like LBL automatically forcing four-level mode. Big stack users won't really need them, they can figure out where to insert 4STK or L4STK into legacy programs as needed. And for people who prefer to use the four-level stack exclusively, such safety features probably won't go far enough.

So here's another proposal: I leave the big stack functionality exactly like it is now, with no changes to the semantics of FUNC, 4STK, NSTK, L4STK, or LNSTK... and I add a setting to the Preferences to completely disable the big stack. Completely disable, as in: removing the STK section under CATALOG, removing 4STK and NSTK from MODES, turning off big stack mode if it happened to be active, and making all big-stack-related functions raise a Big Stack Disabled error when they are executed in a program. This master setting will be set to "big stack disabled" by default.

(And this whole story will apply to the basic Free42 as well as Free42+.)

[Peet]

The compromise eliminates at least one big inconsistency, the modification of the stack content when switching modes.

But there are still some points that do not match the so far very consistent free42.

Stack error messages as the 28C instead of improved ones as later RPL modells.
But a backspace behavior as this RPL modells (DROP-ERROR) instead RPN-like (even Prime) with no effect if empty.
X<>Y (without X and Y Registers) instead of SWAP to swap stack positions 1 and 2.
Unanswered compatibility question for programs that are written in the other mode.
Unanswered question about register-function e.g. RCL IND L.
etc.

Today I saw a test of a luxury watch on Youtube. The watch was said to be outstanding, but at the watchmaker the tester took a look at the movement and it was encased in a plastic spacer. Even if you never see it, the tester said, the fact that is there is a turn of.

Someone in this forum wrote that he'd rather do something right instead of making it work somehow.
On Windows there is at least the V41 but as far as I know on other platforms the Free42 is without competition the only great RPN-Calculator. Please don't kill it.

[Thomas Okken]

(02-05-2021 09:14 PM)Peet Wrote:  But there are still some points that do not match the so far very consistent free42.

Well, yes. When you turn on the big stack, you get big stack behavior. That is different from four-level stack behavior. That's the whole point. The only way to be perfectly consistent with the four-level stack is to have a four-level stack, which is why that mode is still there.

(02-05-2021 09:14 PM)Peet Wrote:  Stack error messages as the 28C instead of improved ones as later RPL modells.

The error messages not including the function name is consistent with every single other error message the HP-42S has ever produced. What do you expect Free42 to be consistent with?

(02-05-2021 09:14 PM)Peet Wrote:  But a backspace behavior as this RPL modells (DROP-ERROR) instead RPN-like (even Prime) with no effect if empty.

Since the X register cannot be empty with the four-level stack, obviously you can never get an error message with CLX, there is always a number there to replace with zero.

(02-05-2021 09:14 PM)Peet Wrote:  X<>Y (without X and Y Registers) instead of SWAP to swap stack positions 1 and 2.

Are you having difficulty grasping the equivalence between "level 1" and "X register", and "level 2" and "Y register"?

(02-05-2021 09:14 PM)Peet Wrote:  Unanswered compatibility question for programs that are written in the other mode.

What are you even talking about? We've been discussing the behavior of the big stack in great detail here!

(02-05-2021 09:14 PM)Peet Wrote:  Unanswered question about register-function e.g. RCL IND L.
etc.

Which question would that be? I must not be paying attention?

(02-05-2021 09:14 PM)Peet Wrote:  Today I saw a test of a luxury watch on Youtube. The watch was said to be outstanding, but at the watchmaker the tester took a look at the movement and it was encased in a plastic spacer. Even if you never see it, the tester said, the fact that is there is a turn of.

I'm sorry but now you're really losing me. I guess I'd better not tell you about all the changes I've had to make to the Free42 internals in order to be able to implement SST→, LSTO, FUNC, and RTNYES/RTNNO/RTNERR. Even if you never see it or use those functions, the fact that those data stuctures exist must surely be a turn-off as well.

(02-05-2021 09:14 PM)Peet Wrote:  On Windows there is at least the V41 but as far as I know on other platforms the Free42 is without competition the only great RPN-Calculator. Please don't kill it.

Kill it? Are you paying even the slightest attention to what I'm doing?

[Vincent Weber]

I agree with Thomas that this debate is pointless.

I don't care about this unlimited stack feature, selfishly I would rather have Thomas instead spend time on features I care for, e.g. equations à la 27S, but reading about how he has done it, there is no compatibily break issue whatsoever.

You don't want the big stack ? Well just leave free42 permanently in 4-level stack mode, as I will do, period. You'll never have any compatibility issue.

[Peet]

(02-05-2021 09:45 PM)Thomas Okken Wrote:  When you turn on the big stack, you get big stack behavior. That is different from four-level stack behavior. That's the whole point. The only way to be perfectly consistent with the four-level stack is to have a four-level stack, which is why that mode is still there.

I ment something else. If you have 4 or more Levels on the big stack, change mode to the 4 level stack, do an aritmetic and change back to the big stack, than the 4: and 3: level now have the value from the former 3: level because of the behavior of the T-Register in 4 level mode. That may be technically correct but still strange because you don't see the changing of the content. That's why I liked your decision to remove 4STK and NSTK from MODES and put it to the preferece setting.

(02-05-2021 09:45 PM)Thomas Okken Wrote:  Since the X register cannot be empty with the four-level stack, obviously you can never get an error message with CLX, there is always a number there to replace with zero.

The Prime didn't have a four-level stack and produces no CLX-Error. Even well known Programs like Notepad or Word did not produces errors with backspace in an empty document. That was an annoying error-message on some (not every) RPL calculators and I don't understand why you choose this for the Free42.

(02-05-2021 09:45 PM)Thomas Okken Wrote:  Are you having difficulty grasping the equivalence between "level 1" and "X register", and "level 2" and "Y register"?

No, no difficulties but it looks a bit sloppy, even HP never uses X<>Y on Calculators with an dynamic stack. It was SWAP on RPL or arrows on the Prime but X and Y are used for math equations and not for the stack on this calculators.

(02-05-2021 09:45 PM)Thomas Okken Wrote:  Which question would that be? I must not be paying attention?

There is no example from HP Calculators in for a T -od L-Register on a dynamic stack. If you do so, your setting new standards and I asked if there is a strict logic behind or whether they result from the programming.
Is there an equivalent to the T-Register? Is there a LastX in a numbered stack? If yes, does it behave like LastX on the 4 Level Stack?

(02-05-2021 09:45 PM)Thomas Okken Wrote:  What are you even talking about?

In RPL the dynamic Stack was implemetet as part of the system and consistent. On the Prime a bit adapted for RPN but not particularly elegant. On the Free42 I thougt it was on development and I wantet to point out possible discrepancies so you can take this into account if necessary or ignore them if you want.

[Thomas Okken]

Code:

T                ↔ Level 4
Z                ↔ Level 3
Y                ↔ Level 2
X                ↔ Level 1
LAST x, a.k.a. L ↔ LAST x, a.k.a. L

[Thomas Okken]

(02-05-2021 11:05 PM)Peet Wrote:  

(02-05-2021 09:45 PM)Thomas Okken Wrote:  Are you having difficulty grasping the equivalence between "level 1" and "X register", and "level 2" and "Y register"?

No, no difficulties but it looks a bit sloppy, even HP never uses X<>Y on Calculators with an dynamic stack. It was SWAP on RPL or arrows on the Prime but X and Y are used for math equations and not for the stack on this calculators.

I'm adding a big stack option to Free42, not creating an RPL clone. As I've said before right here on this forum. Besides, I assume even RPL users can figure out what keys like Y^X and 1/X etc. do, since they are labeled just like that on the RPL calculators. X↔Y shouldn't be that much harder.

But I think I'm wasting my time answering these so-called questions. You just don't like the addition of a big stack, and that is fine, you don't have to use it. But rationalizing that dislike with the kind of nitpicking you're doing here is just annoying.

[Peet]

(02-06-2021 12:12 AM)Thomas Okken Wrote:  But I think I'm wasting my time answering these so-called questions. You just don't like the addition of a big stack, and that is fine, you don't have to use it.

I was interested in a Prime and looked into why it was so hated. The Prime was so far the only calculator with RPN and a big stack, so I wanted to share some things I noticed with the acceptance of the RPN-Mode on the prime because you want to go a similar way with the free42.

(02-06-2021 12:12 AM)Thomas Okken Wrote:  Besides, I assume even RPL users can figure out what keys like Y^X and 1/X etc. do, since they are labeled just like that on the RPL calculators. X?Y shouldn't be that much harder.

I agree, but what I have tried to point out is that this is not the most elegant solution. If you already know that, then it's fine with me, I have no problem with that. I just think it would be a shame if I don't tell it and read in the future that it's only because nobody mentioned it.

We talk terribly past each other all the time, I didn't want you to give me answers but maybe you can consider possible discrepancies as long as you are still developing. I don't care if you take it into account, but if I never reveal my concerns there's no chance that you will.

(02-06-2021 12:12 AM)Thomas Okken Wrote:  But rationalizing that dislike with the kind of nitpicking you're doing here is just annoying.

I think you're very unfair. In my opinion that's exact the way you argue e.g. the "to few arguments" on backspace with an empty stack:

The 28S doesn't do it, the 48G does it, the Prime doesn't do it but the big stack test version of the Free42 does it.

I realy don't like this message in this case and mentioned it. I would accept if you answer you don't care or you want it so ... but instead your answer is:

(02-05-2021 09:45 PM)Thomas Okken Wrote:  Since the X register cannot be empty with the four-level stack, obviously you can never get an error message with CLX, there is always a number there to replace with zero.

I know that and it even seems like an explanation. But unfortunately not to my comment, it does not explain why you choose the way of the 48 and not the way of the 28 or prime.

Like I said, I think we talk terribly past each other all the time.

I try a car-example:

On the Mercedes automatic gearshift there are three modes: E (economic) S (sport) and M (manual), on the AMG models these are C (comfort) S (sport) and M (manual).
A work colleague had as replacement a AMG button in his non AMG Modell, so CMS on button but an "E" for economic instead of "C" appears on the display.
If I see something like that, then I would note the inconsistency and I am OK with an answer like "yes, I know, but it doesn't matter".
What I can't stand is if someone accuses me of being to stupid to understand that e and c are synonymous.

My English is not very good and maybe this is the reason for the misunderstandings. So I will stay out of your topics in the future.

[Marco Polo]

(02-05-2021 08:17 PM)Thomas Okken Wrote:  So here's another proposal: I leave the big stack functionality exactly like it is now, with no changes to the semantics of FUNC, 4STK, NSTK, L4STK, or LNSTK... and I add a setting to the Preferences to completely disable the big stack. Completely disable, as in: removing the STK section under CATALOG, removing 4STK and NSTK from MODES, turning off big stack mode if it happened to be active, and making all big-stack-related functions raise a Big Stack Disabled error when they are executed in a program. This master setting will be set to "big stack disabled" by default.

(And this whole story will apply to the basic Free42 as well as Free42+.)

I like your idea.
You could consider an annunciator to light up when big stack is enabled

[Thomas Okken]

I just uploaded new builds for Android, Windows, MacOS, and Linux:

https://thomasokken.com/free42/download/test/

These include the Allow Big Stack setting in Preferences, but are otherwise unchanged. Just a lot of little fiddly changes to make sure the stack and menus update correctly when the setting is changed: when Allow Big Stack is turned off, the calculator has to switch to 4STK mode if it happened to be in NSTK mode, and the CATALOG and MODES menus have to update correctly if they happen to be active at the time of the switch.

Note that Allow Big Stack is a global setting, that is, it is stored in the app state and not in the *.f42 state files, and so it affects all states. The currently active state is updated immediately, and other states are updated if necessary when they are loaded.

(02-06-2021 09:24 AM)Marco Polo Wrote:  You could consider an annunciator to light up when big stack is enabled

Yes, I do like that idea.
I'm not looking forward to updating 88 skins, though!

[Guenter Schink]

(02-06-2021 09:24 AM)Marco Polo Wrote:  I like your idea.
You could consider an annunciator to light up when big stack is enabled

I think that's already implemented by changing the labels of the stack from x,y.. to 1,2,..

Not so difficult to recognize I'd guess. I even think it would be superfluous clutter.

Günter

[Vincent Weber]

Yes, the 42S has always been minimalist, it doesn't have a PGM annunciator because it is quite obvious whether you are in program mode or not. It doesn't have flag annunciators either, because with the custom menus you don't need flags to use flags as indicators...

[Matt Kernal]

Hi Thomas,
I think I'm going to like your big stack feature - just installed it (I use Free42 every day, so thanks). One simple, albeit old school(?), example might be for reconciling your bank checking account balance by entering several debits and/or credits on the big stack - same as those you write in your check (cheque?) book register (do people still do this?). Then comparing them to your checking account app transaction entries by rolling through the big stack, checking for typos (!), then finally performing the "+" and "-" operators to see if "your" final balance matches the "bank's" final balance or not.

Note: to avoid any chance of this thread going off topic, please feel free to (only) PM me a good Android check register app. Thx

Quote:Marco Polo Wrote:
You could consider an annunciator to light up when big stack is enabled

My initial thought is that it's pretty easy to tell you're in NSTK mode by the numbered (i.e. 2 : and 1: ) stack labels, rather than the conventional/lettered (i.e. Y : and X: ) stack labels.

[Gene]

Looking good Thomas!
Gene

[Marco Polo]

(02-06-2021 06:23 PM)Guenter Schink Wrote:  

(02-06-2021 09:24 AM)Marco Polo Wrote:  I like your idea.
You could consider an annunciator to light up when big stack is enabled

I think that's already implemented by changing the labels of the stack from x,y.. to 1,2,..

Not so difficult to recognize I'd guess. I even think it would be superfluous clutter.

Günter

I did not consider this.
You are right.