WP43 Bug Reports and Maintenance

This area is for discussion about these families of custom high-end Scientific Calculator applications for SwissMicros devices.
User avatar
Jaymos
Posts: 1635
Joined: Sun Nov 04, 2018 7:03 pm
Location: Cape Town

Re: 43S Bug Reports and Maintenance

Post by Jaymos »

Walter wrote:
Thu Aug 25, 2022 8:00 pm
Jaymos wrote:
Thu Aug 25, 2022 2:06 pm
I do appreciate your comparison [of CC] with E when it comes to entry of a complex number. As such, it needs not be programmable.
It is for long. Try [P/R] [GTO..] 17 [CC] 4 [ENTER] and see. What more do you want here?
Nothing more. I said for the reason of entering a constant it is not an issue.
Jaco Mostert
Elec Eng, South Africa
https://47calc.com C47 (s/n 03818 & 06199), WP43 (0015). In box: HP42S, HP32Sii, WP34S&C, HP28C, HP35s, EL-506P, EL-W506, PB700; ex: FX702P, 11C, HP67 & HP85; iOS: 42s Byron, Free42+, WP31S/34S, HCalc.
User avatar
BINUBALL
Posts: 46
Joined: Fri Jan 28, 2022 3:48 am
Location: South Korea

Re: 43S Bug Reports and Maintenance

Post by BINUBALL »

Weird behavior in equation editor:

Try to type SF → in new equation. And you can insert → and ← by pressing F1 and F6 .(!) Same thing goes with CF.

Image
S.Korean / HP-50G | fx-570EX | fx-570CW | HP-200LX
User avatar
Walter
Posts: 3070
Joined: Tue May 02, 2017 11:13 am
Location: On a mission close to DRS, Germany

Re: 43S Bug Reports and Maintenance

Post by Walter »

Thanks for reporting. Reproducible. We'll investigate.

EDIT (22-08-31): Repaired (thanks Mihail). Will be included in next release.
WP43 SN00000, 34S, and 31S for obvious reasons; HP-35, 45, ..., 35S, 15CE, DM16L S/N# 00093, DM42β SN:00041
redglyph
Posts: 177
Joined: Sat Dec 22, 2018 11:45 am

Re: 43S Bug Reports and Maintenance

Post by redglyph »

Something else also related to pending input, I was checking the input of integers in other bases.
Tested on Windows wp43.s version 0.22.8.

Stack depth is 4. Here's what I typed and the results:

. ENTER (just to clean the integer state)
INTS
1 2 3 ENTER
=> stack is T:1, Z:2, Y:3, X:3
f # H (by the way, key is blank on emulator, expecting H)
=> stack is T:1, Z:2, Y:3, X:3 base 16
A
=> shown stack is: 2, 2, 3 base 16, A_ (no base)
+
=> shown stack is: 2, 2, 3, A ('3 base 16' has disappeared)
EXIT
=> no effect...
BACKSPACE
=> stack is T:1, Z:2, Y:3, X:3 base 16

So no loss of data, but a very confusing display and input behaviour. I've seen funniest things the first time I did it, with other values appearing in the shown stack but I didn't reproduce it.

Another attempt, which works this time:

. ENTER (just to clean the integer state)
INTS
1 2 3 4 #16
=> stack is T:1, Z:2, Y:3, X:4 base 16
A
=> shown stack is: 2, 3, 4 base 16, A_ #16 (here the base is automatically added)
+
=> stack as expected: 2, 2, 3, E base 16
User avatar
Walter
Posts: 3070
Joined: Tue May 02, 2017 11:13 am
Location: On a mission close to DRS, Germany

Re: 43S Bug Reports and Maintenance

Post by Walter »

redglyph wrote:
Tue Sep 27, 2022 4:01 pm
Stack depth is 4. Here's what I typed and the results:

. ENTER (just to clean the integer state)
INTS
1 2 3 ENTER
You meant 1 ENTER 2 ENTER 3 ENTER ;)
=> stack is T:1, Z:2, Y:3, X:3
f # H (by the way, key is blank on emulator, expecting H)
Thanks for reporting this glitch. Actually, the target system is a calculator which can't switch key labels at all, but anyway.
=> stack is T:1, Z:2, Y:3, X:3 base 16
A
=> shown stack is: 2, 2, 3 base 16, A_ (no base)
Correct so far. You converted the last decimal integer entered to a hexadecimal. How shall the poor calculator know you want to enter a hex number now (you could enter e.g. a number of base 12 as well)?
+
User creativity is amazing. But this is plain BS: you didn't complete numeric input and press an operator. Our fault, of course: we shouldn't have allowed you choosing [+] here.
=> shown stack is: 2, 2, 3, A ('3 base 16' has disappeared)
EXIT
=> no effect...
Consequential errors. The 43S still waits for you entering the base for this incomplete integer input.
BACKSPACE
=> stack is T:1, Z:2, Y:3, X:3 base 16
Now, this it understands and deletes your input digit. Since there's no more digit left, it acts like CLX.
So no loss of data, but a very confusing display and input behaviour.
As mentioned above, user creativity is infinite. We simply didn't foresee (imagine) such an input. Our fault.
Another attempt, which works this time:

. ENTER (just to clean the integer state)
INTS
1 2 3 4 #16
=> stack is T:1, Z:2, Y:3, X:4 base 16
A
=> shown stack is: 2, 3, 4 base 16, A_ #16 (here the base is automatically added)
+
=> stack as expected: 2, 2, 3, E base 16
Correct. See the difference? Anyway, thanks for this real-life experiment. We'll try our best.
WP43 SN00000, 34S, and 31S for obvious reasons; HP-35, 45, ..., 35S, 15CE, DM16L S/N# 00093, DM42β SN:00041
redglyph
Posts: 177
Joined: Sat Dec 22, 2018 11:45 am

Re: 43S Bug Reports and Maintenance

Post by redglyph »

Walter wrote:
Wed Sep 28, 2022 11:29 pm
You meant 1 ENTER 2 ENTER 3 ENTER ;)
Oops, yes.
Thanks for reporting this glitch. Actually, the target system is a calculator which can't switch key labels at all, but anyway.
Yes, it's very minor and I wasn't sure there was a plan to make it more polished than what it already is. Forget I mentioned it.
Correct so far. You converted the last decimal integer entered to a hexadecimal. How shall the poor calculator know you want to enter a hex number now (you could enter e.g. a number of base 12 as well)?
Ah OK, the automatic 2nd entry mentioned in Owner's Manual pg 153 doesn't count if the base was changed after. So the "keyed-in base" in the manual actually means "the base when the last number was keyed in", and not the based I keyed in with the # operation.

I suspected that it happened because of this, but when it happened I didn't realize it immediately because the 'A' was accepted and there was no feedback when pressing '+' other than the displayed stack changing.

So it becomes a suggestion:
- A more robust system would either give an indication, like "Invalid syntax" on the HP48, or would prevent the use from keying in digits that don't belong to the expected base.
- OR, the behaviour could be changed, after all if the user just changed the base of the last integer, they may want to benefit from automatic base entry.
- The phrasing in the manual could be less ambiguous to avoid misinterpreting.
User creativity is amazing. But this is plain BS: you didn't complete numeric input and press an operator. Our fault, of course: we shouldn't have allowed you choosing [+] here.
No, I'm not doing that for the pleasure of creativity, the integer input mode is unconventional in comparison to other calculators and I'm only showing that it's an easy mistake. You know your own system because you've created it, it may not be the case of any user.

But you can call it BS, see if I care. I'll just assume it's a difference in education and manners.
Consequential errors. The 43S still waits for you entering the base for this incomplete integer input.
Again, just a suggestion regarding EXIT:
- It looks like it's possible to EXIT a pending input in most other situations, it's strange that it's not possible here.
- Or showing an error like "invalid syntax" would make it less confusing.

Also, what the user sees after pressing '+' is the stack changing and Y disappearing (sometimes other changes that I couldn't reproduce), when in reality there was no change.
Anyway, thanks for this real-life experiment. We'll try our best.
Always a pleasure to help. ;)
User avatar
Walter
Posts: 3070
Joined: Tue May 02, 2017 11:13 am
Location: On a mission close to DRS, Germany

Re: 43S Bug Reports and Maintenance

Post by Walter »

redglyph wrote:
Thu Sep 29, 2022 11:22 am
Walter wrote:
Wed Sep 28, 2022 11:29 pm
Correct so far. You converted the last decimal integer entered to a hexadecimal. How shall the poor calculator know you want to enter a hex number now (you could enter e.g. a number of base 12 as well)?
Ah OK, the automatic 2nd entry mentioned in Owner's Manual pg 153 doesn't count if the base was changed after. So the "keyed-in base" in the manual actually means "the base when the last number was keyed in", and not the based I keyed in with the # operation.
That's the curse of shortcuts: if you press [#] after an open number, you enter the base for this number; if you enter [#] with numeric input closed, you call ->INT which is - as you know now - a totally different command. I'll modify the manual according to your suggestion (not literally though).
So it becomes a suggestion:
- A more robust system would either give an indication, like "Invalid syntax" on the HP48...
Good idea.
User creativity is amazing. But this is plain BS: you didn't complete numeric input and press an operator. Our fault, of course: we shouldn't have allowed you choosing [+] here.
No, I'm not doing that for the pleasure of creativity, the integer input mode is unconventional in comparison to other calculators and I'm only showing that it's an easy mistake. You know your own system because you've created it, it may not be the case of any user.

But you can call it BS, see if I care. I'll just assume it's a difference in education and manners.
Good grief. Seems I'll have to work with [irony] and [/irony]. And I chose BS as a translation of good ol' German Quatsch but found out just now that I'd better stayed with quatsch. Learned something new.
Consequential errors. The 43S still waits for you entering the base for this incomplete integer input.
Again, just a suggestion regarding EXIT:
- It looks like it's possible to EXIT a pending input in most other situations, it's strange that it's not possible here.
May look like but what [EXIT] really does is documented in the OM, App. 1.
Also, what the user sees after pressing '+' is the stack changing and Y disappearing (sometimes other changes that I couldn't reproduce), when in reality there was no change.
The world is full of irreproducible events (there's even a journal covering them) but, alas, only reproducible events count here. Anyway, throwing "Invalid input" would be a better reaction as you suggested. We'll try our best.
WP43 SN00000, 34S, and 31S for obvious reasons; HP-35, 45, ..., 35S, 15CE, DM16L S/N# 00093, DM42β SN:00041
redglyph
Posts: 177
Joined: Sat Dec 22, 2018 11:45 am

Re: 43S Bug Reports and Maintenance

Post by redglyph »

Walter wrote:
Thu Sep 29, 2022 2:59 pm
Also, what the user sees after pressing '+' is the stack changing and Y disappearing (sometimes other changes that I couldn't reproduce), when in reality there was no change.
The world is full of irreproducible events (there's even a journal covering them) but, alas, only reproducible events count here. Anyway, throwing "Invalid input" would be a better reaction as you suggested. We'll try our best.
Just to be clear: the stack changing and Y disappearing is reproducible though. It's actually what prompted me to report the issue in the first place.

In the mean time, I've understood the problem (I attached screenshots for 1-4):
  1. Initial stack: X0 Y0 Z0 T0
  2. after typing 'A' from the menu: A_ X0 Y0 Z0
  3. after '+': A_ Y0 Z0 Z0
  4. after '+': A_ Z0 Z0 Z0
  5. after BACKSPACE: X0 Y0 Z0 T0
=> so the display behaves as if the stack was popping items when pressing '+', but the actual stack is unchanged because the input is invalid.

For what it's worth, nothing serious. I agree the user does something invalid anyway, but this will probably add this their confusion.

PS:
And I chose BS as a translation of good ol' German Quatsch but found out just now that I'd better stayed with quatsch. Learned something new.
Good to know, I've learned something too then. :D Let's just say that if someone was using that where I live, they'd be in serious trouble. Unless it's a bully boss, in which case it would indicate the other person is about to be in a lot of trouble. ;)
Attachments
stack_screenshots.zip
(50.99 KiB) Downloaded 61 times
User avatar
Jaymos
Posts: 1635
Joined: Sun Nov 04, 2018 7:03 pm
Location: Cape Town

Re: 43S Bug Reports and Maintenance

Post by Jaymos »

redglyph wrote:
Thu Sep 29, 2022 4:15 pm
Walter wrote:
Thu Sep 29, 2022 2:59 pm
Also, what the user sees after pressing '+' is the stack changing and Y disappearing (sometimes other changes that I couldn't reproduce), when in reality there was no change.
The world is full of irreproducible events (there's even a journal covering them) but, alas, only reproducible events count here. Anyway, throwing "Invalid input" would be a better reaction as you suggested. We'll try our best.
Just to be clear: the stack changing and Y disappearing is reproducible though. It's actually what prompted me to report the issue in the first place.

In the mean time, I've understood the problem (I attached screenshots for 1-4):
  1. Initial stack: X0 Y0 Z0 T0
  2. after typing 'A' from the menu: A_ X0 Y0 Z0
  3. after '+': A_ Y0 Z0 Z0
  4. after '+': A_ Z0 Z0 Z0
  5. after BACKSPACE: X0 Y0 Z0 T0
=> so the display behaves as if the stack was popping items when pressing '+', but the actual stack is unchanged because the input is invalid.

For what it's worth, nothing serious. I agree the user does something invalid anyway, but this will probably add this their confusion.

PS:
And I chose BS as a translation of good ol' German Quatsch but found out just now that I'd better stayed with quatsch. Learned something new.
Good to know, I've learned something too then. :D Let's just say that if someone was using that where I live, they'd be in serious trouble. Unless it's a bully boss, in which case it would indicate the other person is about to be in a lot of trouble. ;)
Confirmed.

It progressively drops and destroys the stack each time you attempt addition.

It should not destruct the stack in the process of refusing to operate (for valid reason).
Jaco Mostert
Elec Eng, South Africa
https://47calc.com C47 (s/n 03818 & 06199), WP43 (0015). In box: HP42S, HP32Sii, WP34S&C, HP28C, HP35s, EL-506P, EL-W506, PB700; ex: FX702P, 11C, HP67 & HP85; iOS: 42s Byron, Free42+, WP31S/34S, HCalc.
ben.titmus
Posts: 49
Joined: Wed Feb 24, 2021 7:50 pm
Location: Cambridge, UK

Re: 43S Bug Reports and Maintenance

Post by ben.titmus »

Jaymos wrote:
Thu Sep 29, 2022 5:27 pm
redglyph wrote:
Thu Sep 29, 2022 4:15 pm
Just to be clear: the stack changing and Y disappearing is reproducible though. It's actually what prompted me to report the issue in the first place.

In the mean time, I've understood the problem (I attached screenshots for 1-4):
  1. Initial stack: X0 Y0 Z0 T0
  2. after typing 'A' from the menu: A_ X0 Y0 Z0
  3. after '+': A_ Y0 Z0 Z0
  4. after '+': A_ Z0 Z0 Z0
  5. after BACKSPACE: X0 Y0 Z0 T0
=> so the display behaves as if the stack was popping items when pressing '+', but the actual stack is unchanged because the input is invalid.

For what it's worth, nothing serious. I agree the user does something invalid anyway, but this will probably add this their confusion.
Confirmed.

It progressively drops and destroys the stack each time you attempt addition.

It should not destruct the stack in the process of refusing to operate (for valid reason).
Actually, I think it is worse than this because if you complete the input (by typing #16) then the + operations remain in force. If you backspace it will restore to the previous state. I've raised issue 1168 for this.
Post Reply