Free42 with big stack, test version

[Thomas Okken]

(02-03-2021 02:43 PM)rprosperi Wrote:  I think "no" is better too. Although one can think of scenarios where this could be useful (Werner already has!) I think keeping FREE42 RPN-like in all other ways makes the most sense. RPL-like behavior (e.g. full UNDO) can't realistically be implemented anyhow, without inventing a whole bunch of new cases and rules.

UNDO would be difficult, but ARG would actually be pretty easy. (How does that work on the 50g, actually? I'm referring to the command that retrieves all the parameters consumed by the last function, [RightShift] [EEX] on the 48G, but I can never find anything on the 50g...)

[John Keith]

(02-03-2021 03:45 PM)Thomas Okken Wrote:  UNDO would be difficult, but ARG would actually be pretty easy. (How does that work on the 50g, actually? I'm referring to the command that retrieves all the parameters consumed by the last function, [RightShift] [EEX] on the 48G, but I can never find anything on the 50g...)

On the 50g it's called ANS (left-shift ENTER). Confusingly there is an ARG (right-shift /) but that's the Arg of a complex number.

[grsbanks]

(02-03-2021 02:17 PM)Werner Wrote:  Maybe not, but I just encountered a situation that needed to 'DROP' X and save it in L ;-)

As a workaround you can always do STO ST L followed by RDN.

[Thomas Okken]

By the way, before anyone gets too deep into this, I should mention that I'm still working on the code to clean up after FUNC+LNSTK and FUNC+L4STK. The former is sort of OK as is, but doesn't deal with memory allocation failures well; the latter, which is rather important because you'll need it if you want to use 4-level-based functions from a big stack context, is still a bit of a mess, and that is turning out to be rather complicated to get right. The current code will not handle this case correctly; hopefully I'll have this fixed by tomorrow.

(02-03-2021 06:41 PM)John Keith Wrote:  

(02-03-2021 03:45 PM)Thomas Okken Wrote:  UNDO would be difficult, but ARG would actually be pretty easy. (How does that work on the 50g, actually? I'm referring to the command that retrieves all the parameters consumed by the last function, [RightShift] [EEX] on the 48G, but I can never find anything on the 50g...)

On the 50g it's called ANS (left-shift ENTER). Confusingly there is an ARG (right-shift /) but that's the Arg of a complex number.

Thanks! (BTW, I think ANS is a pretty confusing name, too...)

[Peet]

I think with RPL, a large stack is absolutely necessary, but with RPN you only lose the advantage of the good overview without real gaining another.

After this thread (https://www.hpmuseum.org/forum/thread-16086.html) had an open ending and the need (not even an advantage) for a larger RPN stack was never really clarified I am alike curious and interested - is there a reason/usage for a larger stack or is it more a proof of concept?

[Thomas Okken]

(02-03-2021 10:25 PM)Peet Wrote:  I think with RPL, a large stack is absolutely necessary, but with RPN you only lose the advantage of the good overview without real gaining another.

After this thread (https://www.hpmuseum.org/forum/thread-16086.html) had an open ending and the need (not even an advantage) for a larger RPN stack was never really clarified I am alike curious and interested - is there a reason/usage for a larger stack or is it more a proof of concept?

It's not merely a larger stack, it's a dynamic stack, i.e. it grows as large as it needs to be, nothing is ever lost from the top. For manual calculations this may not be a very big deal, but for programming it can be, it makes parameter passing and recursive functions easier. It's not strictly necessary in Free42 because it already had local variables with LSTO and support for cleaner functions with FUNC, but the big stack offers an alternative for people who prefer that kind of coding style.

[Sukiari]

This is great, thanks a lot. I hope to see this in the DM-42 as well.

[Peet]

(02-03-2021 11:21 PM)Thomas Okken Wrote:  For manual calculations this may not be a very big deal, ...

It is, but not in a good way. x=0 is not the same as an empty stack and you can't clear the stack with "0 enter enter enter" etc.
It has been pretty reckless on the part of HP to ignore the habits of many RPN users in such a mean way.

You have no idea how often my HP48 almost flew out of the window because of "Error: To Few Arguments" which even appeared on the HP48 if you wanted to push it away with <-, the HP28S and the Prime (also the Free42 test version) does it better in this case. But in contrast to the HP calculators, the Free42 does not show the function that triggered the error.

(02-03-2021 11:21 PM)Thomas Okken Wrote:  ... the big stack offers an alternative for people who prefer that kind of coding style.

I think it was precisely this consideration that led to the development of RPL. Wouldn't a dynamic array be more consistent for this on a RPN Calculator?

As I mentioned in an other thread, I don't see RPL as a successor to RPN but more as a fork. In RPL it became consistent with a dynamic stack. In RPN calculation was the startpoint and the stack optimized for this kind of operation. The programming "language" (Keystoke) resulted from it. In RPL a new structured language was developed and the stack was replaced by a list with stack-functionality for calculations.

I like to juggle the stack myself in programs instead of using register but the limited stack in particular forces you to make it understandable e.g. if you look at such a program again after years.

[Thomas Okken]

(02-04-2021 08:02 AM)Peet Wrote:  It is, but not in a good way. x=0 is not the same as an empty stack and you can't clear the stack with "0 enter enter enter" etc.
It has been pretty reckless on the part of HP to ignore the habits of many RPN users in such a mean way.

If you don't like "zero" being distinct from "no data" or having to use CLST (three keystrokes) to clear the stack, then don't use it, I'm not forcing this on anyone. The four-level stack is still there and works as always.

Just like HP, I'm adding capabilities to make the app more useful. In the case of the HP calculators, the dynamic stack wasn't merely an option, it was a central part of the new design. The new design was carefully thought out and very capable, but not compatible with certain habits. You can call that unfortunate; I find it odd to call it reckless or mean.

(02-04-2021 08:02 AM)Peet Wrote:  You have no idea how often my HP48 almost flew out of the window because of "Error: To Few Arguments" which even appeared on the HP48 if you wanted to push it away with <-, the HP28S and the Prime (also the Free42 test version) does it better in this case. But in contrast to the HP calculators, the Free42 does not show the function that triggered the error.

Just like the HP-42S, Free42 never tells you which function triggers an error, any error. You can tell because it's the one you just pressed on the keyboard, or, if it happened while running a program, it's the one that the program halted on, which you can see by going into program mode. This is how RPN keystroke programmable calculators have always worked.

(02-04-2021 08:02 AM)Peet Wrote:  I like to juggle the stack myself in programs instead of using register but the limited stack in particular forces you to make it understandable e.g. if you look at such a program again after years.

Style is a personal choice. You can use stackrobatics in a way that makes programs hard to understand, but you don't have to. Just like the Obfuscated C Contest doesn't mean C programs are necessarily hard to read.

[Peet]

(02-04-2021 01:51 PM)Thomas Okken Wrote:  If you don't like "zero" being distinct from "no data" or having to use CLST (three keystrokes) to clear the stack, then don't use it

I wasn't talk about a special calculator, on the HP41 e.g. it was XEQ alpha C L S T alpha ... 0 ENTER ENTER ENTER was much easier and tempting, also if you use an unknown HP.

(02-04-2021 01:51 PM)Thomas Okken Wrote:  The four-level stack is still there and works as always.

Thanks for that decision, so free42 will be a classic RPN calculator(-app) and not only am mixed hybrid around genarations.

(02-04-2021 01:51 PM)Thomas Okken Wrote:  In the case of the HP calculators, the dynamic stack wasn't merely an option, it was a central part of the new design. The new design was carefully thought out and very capable, but not compatible with certain habits.

Not a complete contradiction to what I wrote before ...

(02-03-2021 10:25 PM)Peet Wrote:  I think with RPL, a large stack is absolutely necessary, but with RPN you only lose the advantage of the good overview without real gaining another.

... but I disagree to your argument for RPN, the RPN-Mode on the Prime is not a real progress e.g. compared to the 42S.

(02-04-2021 01:51 PM)Thomas Okken Wrote:  You can call that unfortunate; I find it odd to call it reckless or mean.

I was referring among other things to the backspace key of the 48. In contrast to all other HPs you can't remove an error message with this key. Particularly annoying with "to few arguments" the backspace key triggers this messege on the 48 if the stack was empty instead to remove the message. So with my moderate english skills I call this reckless and mean!

(02-04-2021 01:51 PM)Thomas Okken Wrote:  Just like HP, I'm adding capabilities to make the app more useful.

But unlike HPs your improvements so far are very popular. Don't follow HP too much.

[Peet]

(02-04-2021 01:51 PM)Thomas Okken Wrote:  Just like the HP-42S, Free42 never tells you which function triggers an error, any error. You can tell because it's the one you just pressed on the keyboard, or, if it happened while running a program, it's the one that the program halted on, which you can see by going into program mode. This is how RPN keystroke programmable calculators have always worked.

I try to explain what I tried to say, it is difficult to do this with my moderate school-english skills, but I try.

On the HP28C (with an empty Stack):
If you type "SIN" then you get "to few arguments", if you type "5 X^2" you get a result.
If you type "100 +" instead then you get also "to few arguments" but a single argument would have been enough e.g. for SIN.

On a HP28S, HP48G Hewlett Packard enhanced this Message:
If you say "2 +" then you get: "+ ERROR: to few arguments", because e.g. for SIN a single number is not to few. The new Message is more precise.

At the moment free42 makes it like the HP28C and not like the 28S or 48G.

On the Prime HP returned to a message without telling the function but with a better wording. The Prime doesn't tell you, you used to few arguments, the prime says you used not the right number of arguments. On this phrase the question "why?" arise less than with the message "too few".

[Thomas Okken]

I just uploaded new test builds, with fixes to FUNC+LNSTK and FUNC+L4STK.
I also added the MDY/DMY/YMD, CLK12/CLK24, and 4STK/NSTK settings to the MODES menu.

As before, executables for Android, Windows, MacOS, and Linux are here:
https://thomasokken.com/free42/download/test/

[Vincent Weber]

I couldn't care less about the unlimited stack feature, but i really love the way things are organized now, both MODE and CATALOG. Much more modular, yet non-intrusive with regards to the original 42S.

Thanks Thomas !

Cheers

[Didier Lachieze]

Great set of new features, I really like the way CATALOG is now organized.
But...

(01-30-2021 02:11 PM)Thomas Okken Wrote:  I'm even considering adding an annunciator for big stack mode, because it is such an important setting and because knowing which mode is in effect is so important because it breaks backward compatibility with a lot of programs.

Breaking backward compatibility ! Really ?? This is something I never expected from Free42. And its a showstopper for me to use the big stack because with it I cannot trust anymore the programs in Free42.
Once you enable the big stack mode you can still run any of the programs you have in Free42 (or in your DM42 once this update will be implemented) including any of the huge HP42/41 library, but nothing will tell you which ones are compatible with the big stack mode, and for the ones that are not you may get an unexpected error message or, worse, a wrong result without any warning.

[Thomas Okken]

Yes, running programs in big stack mode, when they were written for the four-level stack, is not going to work well. And of course "don't use big stack mode at all" is a straightforward and effective way of avoiding that scenario.

For people who want to use both modes, I'm still thinking about how to support that best without running programs in the wrong mode by mistake. One improvement I'm thinking of would be this: make the 4STK and NSTK functions non-programmable, and make it so that when the return stack is cleared, any outstanding L4STK and LNSTK operations are undone. That way, programs can use whichever mode they want internally, but the calculator will always revert to the user's preferred mode afterward.

Other solutions are also possible, of course, but that one seems reasonably simple and less likely to cause confusion than some others I could think of...

[Werner]

(02-05-2021 08:40 AM)Thomas Okken Wrote:  make the 4STK and NSTK functions non-programmable, and make it so that when the return stack is cleared, any outstanding L4STK and LNSTK operations are undone.

Or just keep the L-versions, for use in programs? so no user-unlimited mode.
That may still fail when a NSTK program calls a 4STK legacy routine - but you, as writer of that NSTK routine, should then know to switch back to 4STK mode before the call.

Werner

[Thomas Okken]

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.

Other possibility: instead of NLBL, add a function BIGSTK, which must be placed at line 01, and which applies to the entire program.

[Werner]

I was trying out a few pieces of code, to see how they would look, implemented with (L)NSTK.
In one instance, I only switched to NSTK mode when necessary, so switching between NSTK and 4STK modes would be useful, for me ;-)
(it's actually not so easy, finding examples that benefit from NSTK. Here I am, making do with 4 levels all my life. All my programs make maximum use of the stack, and it's surprising what you can do with just 4 levels ;-)
Werner

[Paul Dale]

What about a forcing LNSTK and L4STK is only appear after a LBL? Or even an alpha LBL? This might muck up the automatic stack/last X support.


Pauli

[Sylvain Cote]

(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