minor inconsistency

Post here to share useful tips and tricks, to ask questions about using your DM42 or to report software-related problems
Post Reply
whuyse
Posts: 198
Joined: Thu Dec 21, 2017 1:23 pm

minor inconsistency

Post 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
41CV†,42S,48GX,49G,DM42,DM41X,17BII,15CE, DM15L
Thomas Okken
Posts: 1100
Joined: Tue May 02, 2017 5:48 pm
Location: Netherlands
Contact:

Re: minor inconsistency

Post 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.
Boub65
Posts: 231
Joined: Tue Sep 12, 2017 4:34 pm
Location: Rabat, Morocco

Re: minor inconsistency

Post 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.
Sincèrement, Sincerely, 73,
Boubker

DM15L, DM41L, DM42 #00855 (domes upgraded), DM41X #00707
HP48SX (with dark screen), HP42s, HP32SII (1990 with fraction bug), HP41C/CV
TI-89 titanium, CASIO fx-cg50 and Numworks (to play with micropython)
rprosperi
Posts: 1703
Joined: Mon Apr 24, 2017 7:48 pm
Location: New York

Re: minor inconsistency

Post 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... :?
--bob p

DM42: β00071 & 00282, DM41X: β00071 & 00656, DM10L: 071/100
whuyse
Posts: 198
Joined: Thu Dec 21, 2017 1:23 pm

Re: minor inconsistency

Post 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
41CV†,42S,48GX,49G,DM42,DM41X,17BII,15CE, DM15L
User avatar
Walter
Posts: 3070
Joined: Tue May 02, 2017 11:13 am
Location: On a mission close to DRS, Germany

Re: minor inconsistency

Post 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?
WP43 SN00000, 34S, and 31S for obvious reasons; HP-35, 45, ..., 35S, 15CE, DM16L S/N# 00093, DM42β SN:00041
whuyse
Posts: 198
Joined: Thu Dec 21, 2017 1:23 pm

Re: minor inconsistency

Post 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
41CV†,42S,48GX,49G,DM42,DM41X,17BII,15CE, DM15L
User avatar
Walter
Posts: 3070
Joined: Tue May 02, 2017 11:13 am
Location: On a mission close to DRS, Germany

Re: minor inconsistency

Post 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.
WP43 SN00000, 34S, and 31S for obvious reasons; HP-35, 45, ..., 35S, 15CE, DM16L S/N# 00093, DM42β SN:00041
whuyse
Posts: 198
Joined: Thu Dec 21, 2017 1:23 pm

Re: minor inconsistency

Post 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
41CV†,42S,48GX,49G,DM42,DM41X,17BII,15CE, DM15L
Thomas Okken
Posts: 1100
Joined: Tue May 02, 2017 5:48 pm
Location: Netherlands
Contact:

Re: minor inconsistency

Post 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.
Post Reply