I just discovered that the 31s behaves differently from other HPs or the WP34s after an error occured. Example: type 3 [ENTER] -4 [LN] and you'll get the expected "Domain Error". Usually pressing backspace clears the error message and returns to the previously entered –4. The 31s however has lost this value and shows the 3 that was previously in Y. In fact, now both X and Y (!) hold this value.

I thought that the UNDO feature may help here, but pressing UNDO after the error occured does not recover the –4 either. Neither on the emulator nor on real hardware.

Is this the intended behaviour? Sorry if this has been discussed earlier, in this case a pointer to the respective thread will do. ;-)

(03-01-2015 10:07 PM)Dieter Wrote: Is this the intended behaviour? Sorry if this has been discussed earlier, in this case a pointer to the respective thread will do. ;-)
Dieter

According to page 26 of the PDF manual this is NOT the intended behavior. The Back Arrow key should clear the error message and return the display to the state before the error occurred.

I don't recall ever seeing this subject reported in the forums, but I must admit that I typically don't read as many WP-31s threads as I do WP-34s threads. It looks to me like you found another genuine bug.

In the example you give above, the "Stack" does get restored by the UNDO command. The number 4 is not actually on the stack when the + key is pressed. It is in the "Input" register not the X register. If you do this sequence:

Code:

1 [ENTER] 2 [ENTER] 3 [ENTER] 4 [X<>Y] [X<>Y]

T 1 1 1
Z 2 1 2
Y 3 2 3
X 4 7 4
[+] [UNDO]

You can see that the UNDO really does restore the actual "STACK" but in your example the number 4 was
not yet in the stack (only in the input register) so the UNDO couldn't restore it. In your example the actual X register
still had the 3 in it from [ENTER] duplication, and the input register (displayed in the lower line of the calculator) does not show
what is in the X register It shows the partially completed input register (4). If you run the QT emulator for the WP-31s you can see this in real time.

Modifying your original error report if you type: 3 [ENTER] 4 [+/-] [X<>Y] [X<>Y] [LN] [BACKSPACE] The -4 will be restored to the X register. But there is a difference in the behavior of the WP-34s and the WP-31s as follows:

So the difference is that on the WP-34s LN copies the input register to the X register first then computes the natural log so the backspace can restore the -4 but on the WP-31s this copy is not happening, or the error recovery (backspace) is restoring back too far, so what gets restored is the duplicate 3 from the previous [ENTER].

I noticed a while ago that there were multiple things wrong IMO with the undo function in the 31S but I haven't yet gotten around to dealing with it properly, or even figuring out whether or not the behavior matches the official documentation. This is something I'll definitely fix unless someone else does it first.

You may want to try the following patch but be warned, it hasn't yet received much testing.

(03-02-2015 07:57 AM)BarryMead Wrote: You can see that the UNDO really does restore the actual "STACK" but in your example the number 4 was not yet in the stack (only in the input register) so the UNDO couldn't restore it. In your example the actual X register still had the 3 in it from [ENTER] duplication, and the input register (displayed in the lower line of the calculator) does not show what is in the X register It shows the partially completed input register (4). If you run the QT emulator for the WP-31s you can see this in real time.

Barry, that's a very interesting observation. However I do not think this is the way the 31s should behave. It is an ultimately "classic" RPN device, and the documentation does not know of an input register as opposed to the usual stack register X. In the first example, the [ln] key computes the natural logarithm of X, so there must have been a –4 in X before. Likewise the [+] key adds Y and X, so again there must have been a 4 in X. And finally there is a LastX command (OK, RCL L in this case) that restores the X-value before the last operation.

So I do not think that the examples show the behaviour intended by the 31s team. Pauli? Walter?

(03-02-2015 07:34 PM)Dieter Wrote: Barry, that's a very interesting observation. However I do not think this is the way the 31s should behave. It is an ultimately "classic" RPN device, and the documentation does not know of an input register as opposed to the usual stack register X. In the first example, the [ln] key computes the natural logarithm of X, so there must have been a –4 in X before. Likewise the [+] key adds Y and X, so again there must have been a 4 in X. And finally there is a LastX command (OK, RCL L in this case) that restores the X-value before the last operation.

So I do not think that the examples show the behaviour intended by the 31s team. Pauli? Walter?

Dieter

I agree. One would naturally tend to think that the input register and the X register are the same thing. The fact that they are different is a convenience to the developers, not the user. I applied Bit's patch and it does seem to fix the error recovery and UNDO behaviors for both of your examples. Thank You Bit! Dieter: If you would like to try out Bit's patch unzip and flash your WP-31s with this file, Barry (See a later posting in this thread for a more updated wp31s flash image with Bit's Better Undo feature).

(03-02-2015 07:44 PM)BarryMead Wrote: I applied Bit's patch and it does seem to fix the error recovery and UNDO behaviors for both of your examples. Thank You Bit! Dieter: If you would like to try out Bit's patch unzip and flash your WP-31s with this file, Barry

Thank you, Barry. I just tried that build and indeed the 31s now behaves as expected. This fix should be included in the "official" firmware release. For those who want to try the posted version: it also includes some other of Bit's modifications, for instance the SIG display mode.

BTW, in the meantime I received an "official confirmation" saying that the current implementation does not work the way it is supposed to. ;-)

(03-03-2015 01:54 PM)Bit Wrote: I can commit the fix to SVN but I'd rather wait a little until it's been more thoroughly tested, and someone should confirm that this particular new behavior is desired for the official 31S.

Good idea to wait a bit (get it? ). Walter is away for a couple days, and best if he verifies w/the docs, etc. It's odd that it took this long for such an issue to be discovered. Can you tell if the code with the issue is original 31S release level?

(03-03-2015 01:54 PM)Bit Wrote: I can commit the fix to SVN but I'd rather wait a little until it's been more thoroughly tested

Apropos... I noticed a tiny dot in the upper display line. With YDON it's on the left border, with YDOFF above the 6 if Pi is in X. So it looks this tiny dot has some meaning. Or is it just a glitch in the software ?-)

(03-03-2015 01:54 PM)Bit Wrote: I can commit the fix to SVN but I'd rather wait a little until it's been more thoroughly tested

Apropos... I noticed a tiny dot in the upper display line. With YDON it's on the left border, with YDOFF above the 6 if Pi is in X. So it looks this tiny dot has some meaning. Or is it just a glitch in the software ?-)

Dieter

Dieter: That dot is the "Stack Size Indicator" with stack size of 4 you get one dot, with stack size 8 you get two dots (looks like a colon). I compiled the source with ALL of Bit's patches and this is one of his added features.

(03-03-2015 08:10 PM)BarryMead Wrote: Dieter: That dot is the "Stack Size Indicator" with stack size of 4 you get one dot, with stack size 8 you get two dots (looks like a colon).

I see. Not a bad idea, but I would prefer having this indicator always on the same spot, preferably on the far left as it is now in YDON mode.

(03-03-2015 08:10 PM)BarryMead Wrote: I compiled the source with ALL of Bit's patches and this is one of his added features.

Yes, compared to the "official" releases there is a substantial number of differences. Even the function set seems to be different. Do you know if all this is documented somewhere? At first sight I thought this dot was a dust particle. But then it disappeared as I turned the calculator off. ;-)