Nothing more. I said for the reason of entering a constant it is not an issue.
WP43 Bug Reports and Maintenance
Re: 43S Bug Reports and Maintenance
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.
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.
Re: 43S Bug Reports and Maintenance
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.
Try to type SF → in new equation. And you can insert → and ← by pressing F1 and F6 .(!) Same thing goes with CF.
S.Korean / HP-50G | fx-570EX | fx-570CW | HP-200LX
Re: 43S Bug Reports and Maintenance
Thanks for reporting. Reproducible. We'll investigate.
EDIT (22-08-31): Repaired (thanks Mihail). Will be included in next release.
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
Re: 43S Bug Reports and Maintenance
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
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
Re: 43S Bug Reports and Maintenance
You meant 1 ENTER 2 ENTER 3 ENTER
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
f # H (by the way, key is blank on emulator, expecting H)
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)?=> stack is T:1, Z:2, Y:3, X:3 base 16
A
=> shown stack is: 2, 2, 3 base 16, A_ (no base)
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.+
Consequential errors. The 43S still waits for you entering the base for this incomplete integer input.=> shown stack is: 2, 2, 3, A ('3 base 16' has disappeared)
EXIT
=> no effect...
Now, this it understands and deletes your input digit. Since there's no more digit left, it acts like CLX.BACKSPACE
=> stack is T:1, Z:2, Y:3, X:3 base 16
As mentioned above, user creativity is infinite. We simply didn't foresee (imagine) such an input. Our fault.So no loss of data, but a very confusing display and input behaviour.
Correct. See the difference? Anyway, thanks for this real-life experiment. We'll try our best.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
WP43 SN00000, 34S, and 31S for obvious reasons; HP-35, 45, ..., 35S, 15CE, DM16L S/N# 00093, DM42β SN:00041
Re: 43S Bug Reports and Maintenance
Oops, yes.
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.Thanks for reporting this glitch. Actually, the target system is a calculator which can't switch key labels at all, but anyway.
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.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)?
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.
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.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.
But you can call it BS, see if I care. I'll just assume it's a difference in education and manners.
Again, just a suggestion regarding EXIT:Consequential errors. The 43S still waits for you entering the base for this incomplete integer input.
- 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.
Always a pleasure to help.Anyway, thanks for this real-life experiment. We'll try our best.
Re: 43S Bug Reports and Maintenance
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).redglyph wrote: ↑Thu Sep 29, 2022 11:22 amAh 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.
Good idea.So it becomes a suggestion:
- A more robust system would either give an indication, like "Invalid syntax" on the HP48...
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.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.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.
But you can call it BS, see if I care. I'll just assume it's a difference in education and manners.
May look like but what [EXIT] really does is documented in the OM, App. 1.Again, just a suggestion regarding EXIT:Consequential errors. The 43S still waits for you entering the base for this incomplete integer input.
- It looks like it's possible to EXIT a pending input in most other situations, it's strange that it's not possible here.
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.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.
WP43 SN00000, 34S, and 31S for obvious reasons; HP-35, 45, ..., 35S, 15CE, DM16L S/N# 00093, DM42β SN:00041
Re: 43S Bug Reports and Maintenance
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.Walter wrote: ↑Thu Sep 29, 2022 2:59 pmThe 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.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.
In the mean time, I've understood the problem (I attached screenshots for 1-4):
- Initial stack: X0 Y0 Z0 T0
- after typing 'A' from the menu: A_ X0 Y0 Z0
- after '+': A_ Y0 Z0 Z0
- after '+': A_ Z0 Z0 Z0
- after BACKSPACE: X0 Y0 Z0 T0
For what it's worth, nothing serious. I agree the user does something invalid anyway, but this will probably add this their confusion.
PS:
Good to know, I've learned something too then. 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.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.
- Attachments
-
- stack_screenshots.zip
- (50.99 KiB) Downloaded 63 times
Re: 43S Bug Reports and Maintenance
Confirmed.redglyph wrote: ↑Thu Sep 29, 2022 4:15 pmJust 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.Walter wrote: ↑Thu Sep 29, 2022 2:59 pmThe 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.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.
In the mean time, I've understood the problem (I attached screenshots for 1-4):=> so the display behaves as if the stack was popping items when pressing '+', but the actual stack is unchanged because the input is invalid.
- Initial stack: X0 Y0 Z0 T0
- after typing 'A' from the menu: A_ X0 Y0 Z0
- after '+': A_ Y0 Z0 Z0
- after '+': A_ Z0 Z0 Z0
- after BACKSPACE: X0 Y0 Z0 T0
For what it's worth, nothing serious. I agree the user does something invalid anyway, but this will probably add this their confusion.
PS:Good to know, I've learned something too then. 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.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.
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.
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.
-
- Posts: 49
- Joined: Wed Feb 24, 2021 7:50 pm
- Location: Cambridge, UK
Re: 43S Bug Reports and Maintenance
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.Jaymos wrote: ↑Thu Sep 29, 2022 5:27 pmConfirmed.redglyph wrote: ↑Thu Sep 29, 2022 4:15 pmJust 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):=> so the display behaves as if the stack was popping items when pressing '+', but the actual stack is unchanged because the input is invalid.
- Initial stack: X0 Y0 Z0 T0
- after typing 'A' from the menu: A_ X0 Y0 Z0
- after '+': A_ Y0 Z0 Z0
- after '+': A_ Z0 Z0 Z0
- after BACKSPACE: X0 Y0 Z0 T0
For what it's worth, nothing serious. I agree the user does something invalid anyway, but this will probably add this their confusion.
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).