Page 1 of 1

minor inconsistency

Posted: Thu Jan 07, 2021 4:14 pm
by whuyse
Suppose you have two programs with the same global label, but the older one has MVAR statements (so will be recognized by the interactive solver and integrator).
The simplest way to accomplish that is:

Code: Select all

 LBL "T"
 MVAR "X"
 LBL "T"
 END
When you invoke the solver, and press "T", the real 42S responds with "No Menu Variables", whereas the DM42 (and Free42) does nothing.

Cheers, Werner

Re: minor inconsistency

Posted: Thu Jan 07, 2021 8:17 pm
by Thomas Okken

Code: Select all

int docmd_pgmslvi(arg_struct *arg) {
    /* This command can only be invoked from a menu; we assume that
     * the menu handler only gives us valid arguments. We do check
     * the argument type, but the existence of the named label, and
     * whether it actually has MVAR instructions, we just assume.
     */
That assumption is obviously a bit too optimistic!
I'll fix it in the next release.

Re: minor inconsistency

Posted: Thu Jan 07, 2021 11:48 pm
by Boub65
Hello Thomas,
Someone presents a totally improbable "bug" that has absolutely no effect on calculation, and...
1) you investigate it
2) you commit to correct it and push it in next release

I am really impressed by your professionalism!

Take care, stay safe
Boubker.

Re: minor inconsistency

Posted: Fri Jan 08, 2021 12:36 am
by rprosperi
I agree, professional, caring and all too rare.

Even more rare in my experience, are program code comments which actually state the assumptions used when designed, even if they prove to be too... um... optimistic. :)

Bravo Thomas, and also to Werner for finding this, though it makes me wonder how you found it... :?

Re: minor inconsistency

Posted: Fri Jan 08, 2021 9:15 am
by whuyse
Hi Bob,
I use programs "T" all the time, as small tests, and usually have a dozen or so before I start cleaning them up.
One of them (not the most recent) was a solver program that I needed to run again..

@Boub65: Thomas is dedicated to make Free42 behave as close to the real 42S as possible, even in cases where that does not make the most sense, such as:

- OLD and RCLEL being different commands but doing exactly the same
- RCL . showing the IND at the left instead of at the right of the menu, so that the ST entries shift if you do RCL ST Y vs. RCL IND ST Y (yes that bothers me to no end ;-)
- DIM? that should have been called DIMS (anything that ends in a ? is a test for me)
- STOring a matrix into a variable duplicates it, but RCLing it to the stack doesn't. (this is the underlying SysRPL at work) Actually, this is not the case on the DM42, and is an 'inconsistency' that I'd like to keep, please, Thomas!
- GETKEY not catching EXIT - that has been solved by the introduction of GETKEY1
- not all functions work with matrices. Eg. % and MOD don't.
- EDIT doesn't disable stack lift. 1 ENTER NEWMAT EDIT 5 EXITALL now shows a zero in Y.

Cheers, Werner

Re: minor inconsistency

Posted: Fri Jan 08, 2021 12:49 pm
by Walter
whuyse wrote:
Fri Jan 08, 2021 9:15 am
- EDIT doesn't disable stack lift. 1 ENTER NEWMAT EDIT 5 EXITALL now shows a zero in Y.
Hmmm, I'd expect the following:

Code: Select all

            X       Y       Z
1           1       y
ENTER       1       1       y
NEWMAT     [0]      y
EDIT       [0]      y
5          [5]      y
EXITALL    [5]      y
EDIT opens the matrix in X for editing. So why on earth should there be a zero in Y? Reason?

Re: minor inconsistency

Posted: Fri Jan 08, 2021 1:00 pm
by whuyse
EDIT enters the matrix at position 1:1, and the current content (a zero) gets lifted up to Y when you enter the 5, because stack lifting is enabled..
That is how the 42S behaves, and so it is faithfully reproduced in Free42 - in this case, there is no choice: programs would behave differently (wrongly) if it were changed.

Werner

Re: minor inconsistency

Posted: Fri Jan 08, 2021 1:24 pm
by Walter
Thanks, Werner, for the quick response. From a logical point of view, however, if EDIT lifts anything it should lift the content of X, i.e. [0]. Better lift nothing than something different from x, IMO. Will think about a proper procedure for the 43S.

EDIT: We can't be fully consistent with HP-42S & Co anyway, so we're not forced to reproduce what's weird.

Re: minor inconsistency

Posted: Fri Jan 08, 2021 2:23 pm
by whuyse
But EDIT puts the content of position 1:1 into X. The matrix is returned to the stack only after EXITALL.
If you re-edit the matrix after having put a 5 in, the 5 will be pushed up if you enter something new.
The 'store and next' commands (up, down, left and right arrows) do disable stack lift, however.
Werner

Re: minor inconsistency

Posted: Fri Jan 08, 2021 5:09 pm
by Thomas Okken
Once I had decided that my scientific programmable RPN calculator app was going to be modeled after the HP-42S, I felt it made sense to make it mimic the 42S as closely as possible. I find it annoying when simulators only approximate what they simulate, because it tends to trip me up when my muscle memory makes me do things that work in the original but not in the simulator.

Paying attention to detail was most important in the menu system, of course, but since I was at it anyway, I figured I might as well get the less important (strictly cosmetic) things right, too. I seem to remember one case where I ended up leaving a cosmetic discrepancy because getting it right would have introduced a lot of complexity, but in all other cases, doing it right wasn't hard because the way the HP-42S works generally tends to make sense.

The stack lift behavior in EDIT is one of the rare exceptions. The way that works on the real 42S makes no sense and has to be a bug, but unfortunately it's a bug that can't be fixed without breaking full backward compatibility.

But when a bug can be fixed without causing problems I'm happy to do so, like the COMB and PERM bugs, for example.
whuyse wrote:
Fri Jan 08, 2021 9:15 am
- OLD and RCLEL being different commands but doing exactly the same
I think that does make sense in that OLD is a reasonable name to put in the menu in the matrix editor. That it does exactly the same thing as RCLEL isn't immediately obvious, or at least it wasn't to me; IIRC I only realized it when I started implementing the matrix functions.
whuyse wrote:
Fri Jan 08, 2021 9:15 am
- DIM? that should have been called DIMS (anything that ends in a ? is a test for me)
Reasonable, but on the other hand there is also the precedent of ΣREG?
whuyse wrote:
Fri Jan 08, 2021 9:15 am
- STOring a matrix into a variable duplicates it, but RCLing it to the stack doesn't. (this is the underlying SysRPL at work) Actually, this is not the case on the DM42, and is an 'inconsistency' that I'd like to keep, please, Thomas!
Huh! I didn't know that. But there's no reason to simulate that anyway. The way shared matrices are handled, both on the HP-42S and in Free42, is designed to make it look like every matrix is separate anyway, and sharing them is just a performance optimization. The fact that the HP-42S misses one opportunity to apply that optimization doesn't cause any issues except wasting some RAM and CPU cycles.