LastXY Register for WP34S

[PANAMATIK]

This is a proposal for a new feature for the WP34S.

I wonder, why I never heard about the idea of a LastXY register in RPN Calculators.

Obviously the more than fourty year old LastX register works perfectly for correcting a misexecuted monadic function like X^2. But for dyadic functions the user has to think about the correct inverse function of that he just has executed, and he has to enter it explicitely by an extra keystroke and some extra keystrokes for recalling the LastX register twice. Nobody would have difficulties to find the inverse function of x + - / etc., but still there is more comfort without having to think about it. Even more important is, this procedure does not always produce the exact Y value as it was before the operation. Think of multiplying after having done a division or worse.

If you would give the user a dedicated LastXY register, accessible by typing RCL U, if you like to call it Undo Register, which restores both, X and Y register, like they were just before the last operation, the user can forget about which operation he just executed, has the full precision, and can easily type the new dyadic function.

Even better in my opinion could be the implementation, that RCL L restores automatically either X or XY register depending on the last executed function, which the WP34S knows, was either a monadic or a dyadic function.

Of course, this could make old programs, that use the LastX functionality, become incompatible, but the advantage of having improved a fundamental old feature, which it not longer limited by available memory, could be worth of thinking about an implementation, couldn't it?

[Marcus von Cube]

I don't think that's easy.

The problem is that there is no U register, it would need to be emulated by L and probably I which is the imaginary part of complex LastX. We do not save Y to I in normal dyadic operations. We could do, of course, but that would break programs which are relying on the contents of I not being changed except by complex operations. And where to store Z and T when a complex dyadic operation is performed?

The next problem is that such an operation would cause an unusual behavior of RCL: It would not push the stack in a fashion we are used to but would push it up one level and then replace Y by some other saved value. That might be useful but it's not consistent behavior.

The next question arises in the interpretation of the keyboard input. How shall we distinguish between RCL U and RLC 2? An additional keystroke like ENTER would be required before the U.

The 31S has an undo feature which restores the complete working memory to the state it had before the last operation. This is only possible because the working memory of the 31S is way below the 2K RAM we have available. Implementing such a feature is just impossible on the 34S.

[PANAMATIK]

From my point of view, I cannot easily agree to the statement "Implementing such a feature is just impossible on the 34S"

I do know the value of consistency in programming. But an Undo feature imo would not break rules, but just add a new one. Lets get into it. The solution would be to generate 2 new registers like L and K, perhaps named LX,LY, not attached to any letters on the keyboard. The LastXY Undo register would consume just a few RAM bytes in the physical processor memory, about 16 bytes or double with complex numbers. If you dont have left this amount, then you could double purpose or sacrifice 2 to 4 general purpose registers. Before every dyadic instruction the operands could be stored into it, thats easy. By recalling it, there would indeed happen a new kind of stack lift. But this is just a reverse copy back into the X and Y registers. It should not considered as a stack operation at all. The problem with the ambiguity of RCL U and RCL 2 could be solved by a new Sequence, RCL CLx for example, which is afaik not yet occupied.

But again, I know that from the programming side there must be considered some more things. However: not impossible!

Addendum: I just recognized, that your 'impossibility' statement refers to storing the whole memory. Sorry! So still there is your statement "I dont think thats easy!"

[Paul Dale]

Feel free to implement and debug this and submit patches.

I'm leaning Marcus's way at the moment.

- Pauli

[BarryMead]

(11-30-2014 08:51 PM)PANAMATIK Wrote:  I wonder, why I never heard about the idea of a LastXY register in RPN Calculators.

Perhaps a compromise between these two approaches would be more acceptable and compatible with existing programs. What if (ALL NON-COMPLEX DIATIC OPERATORS) saved both X and Y, by calling the setlastXY() function instead of the setlastX() function then one could recall either X or XY, by choosing RCL L or CPX RCL L. The CPX RCL already handles the dual stack lift and recall of both X and Y.

I know this wouldn't take care of Z and T for Complex diatic operators, but it wouldn't be difficult to implement, wouldn't take any additional storage, and would break very few existing programs.

Any thoughts?

[Dieter]

(12-01-2014 05:44 AM)BarryMead Wrote:  What if (ALL NON-COMPLEX DIATIC OPERATORS) saved both X and Y, by calling the setlastXY() function instead of the setlastX() function then one could recall either X or XY, by choosing RCL L or CPX RCL L.

Great idea, Barry — I was about to suggest exactly the same. ;-)

Indeed, there already is a pair of LastX/Y registers: L (Last X) and I (LastY). Currently register I is only used in complex mode to save the imaginary part of the last argument, i.e. the last value of Y. So using register I generally for LastY (i.e. also for real functions with two or more arguments) should be easy.

This would only affect programs that use register I for other purposes. Which is not a good idea anyway (using A–D, L, I, J and K generally is discouraged as these registers may be used by the 34s for other purposes). The impact on existing programs would not be greater than with previous updates, e.g. the change in the way the incomplete Beta function expects its arguments on the stack.

And no, I do not expect a complex LastXY with two more registers saving LastZ and LastT, nor a LastXYZ for functions using three arguments. Although a "Last stack" command would be a nice idea. However, if this is really required it can be done using the current STOS and RCLS commands.

Dieter

[PANAMATIK]

(12-01-2014 05:44 AM)BarryMead Wrote:  What if (ALL NON-COMPLEX DIATIC OPERATORS) saved both X and Y, by calling the setlastXY() function instead of the setlastX() function then one could recall either X or XY, by choosing RCL L or CPX RCL L. The CPX RCL already handles the dual stack lift and recall of both X and Y.

That is a very elegant solution!

It also leaves the choice of recalling LastX instead of LastXY for using a typed number with many digits twice in a calculation.

Bernhard

[Paul Dale]

(12-01-2014 06:56 AM)Dieter Wrote:  This would only affect programs that use register I for other purposes. Which is not a good idea anyway (using A–D, L, I, J and K generally is discouraged as these registers may be used by the 34s for other purposes).

There is some amount of code for a number of the older HP calculators that use an I register and (i) for indirection. Leaving the 34S's I register clear makes porting these a little bit easier. This is part of the reason there is an I register in the device.


- Pauli

[PANAMATIK]

(12-01-2014 09:08 AM)Paul Dale Wrote:  There is some amount of code for a number of the older HP calculators that use an I register and (i) for indirection. Leaving the 34S's I register clear makes porting these a little bit easier. This is part of the reason there is an I register in the device.

- Pauli

I understand, that these older programs don't use complex arithmetik, therefore the I(ndirecton) register remains backward compatible.
Full Backward compatibility with LastXY feature can only be achieved, if there will be a new register for LastY.

But all RAM is already used, like 40 years ago. :-(

Bernhard

[Bit]

(12-01-2014 11:07 AM)PANAMATIK Wrote:  

(12-01-2014 09:08 AM)Paul Dale Wrote:  There is some amount of code for a number of the older HP calculators that use an I register and (i) for indirection. Leaving the 34S's I register clear makes porting these a little bit easier. This is part of the reason there is an I register in the device.

- Pauli

I understand, that these older programs don't use complex arithmetik, therefore the I(ndirecton) register remains backward compatible.
Full Backward compatibility with LastXY feature can only be achieved, if there will be a new register for LastY.

But all RAM is already used, like 40 years ago. :-(

Bernhard

A quick look into the sources revealed that even an XROM routine (in orthopolys.wp34s) depends on the I register not being modified by dyadic operations, although it probably wouldn't be difficult to change that. Several library routines also make use of the I register. Such a change would need to be well tested against all XROM and library programs.

Since this would primarily benefit interactive operation rather than programs, another option is that the Y register could be saved only when not running any program, thus avoiding the compatibility issue.

[brouhaha]

(11-30-2014 09:31 PM)Marcus von Cube Wrote:  The 31S has an undo feature which restores the complete working memory to the state it had before the last operation. This is only possible because the working memory of the 31S is way below the 2K RAM we have available. Implementing such a feature is just impossible on the 34S.

The undo save could be in the non-battery-backed 4K of RAM. If you turn the 34S off, or leave it idle so it turns itself off, then undo would not be available when you turn it back on.

Of course, there might not be enough Flash space left to implment that. I don't think there are many features that I'd be happy to dump in favor of adding undo.

[walter b]

What do we need LASTx for?

1. For error correction after executing a wrong dyadic function. (For a wrong monadic function, just invert it.)
2. For convenient reentry of a multi-digit number.
   

Please compare the manual. RCL L puts the old x right where it belongs for reverting the erroneous operation or reusing it.

Now, if I understood your suggestion correctly, with a LASTxy (or CPX RCL L) for error correction you'd push the previous (erroneous) x into Z, which means you have to get rid of it in an extra step. So I don't see a benefit in recalling last x and y here. Yes, there may be a slight difference to the original calculation in the 16th decimal. But it's an error correction after all, so I won't care for that.

Instead of LASTxy, I'd prefer an UNDO recalling the entire stack as it was before that erroneous last operation. KISS (but it has to be determined whether that's viable with the WP 34S).

Just my 20m€.
d:-)

[Bit]

(12-01-2014 05:10 PM)brouhaha Wrote:  

(11-30-2014 09:31 PM)Marcus von Cube Wrote:  The 31S has an undo feature which restores the complete working memory to the state it had before the last operation. This is only possible because the working memory of the 31S is way below the 2K RAM we have available. Implementing such a feature is just impossible on the 34S.

The undo save could be in the non-battery-backed 4K of RAM. If you turn the 34S off, or leave it idle so it turns itself off, then undo would not be available when you turn it back on.

Of course, there might not be enough Flash space left to implment that. I don't think there are many features that I'd be happy to dump in favor of adding undo.

Unfortunately the content of that 4K RAM is usually lost between keystrokes as the device goes to sleep to save power. There's very little memory left to play with. Perhaps you could reduce the number of general purpose registers to make space for some undo feature.

[PANAMATIK]

(12-01-2014 06:45 PM)walter b Wrote:  Now, if I understood your suggestion correctly, with a LASTxy (or CPX RCL L) for error correction you'd push the previous (erroneous) x into Z, which means you have to get rid of it in an extra step.

Instead of LASTxy, I'd prefer an UNDO recalling the entire stack as it was before that erroneous last operation. KISS (but it has to be determined whether that's viable with the WP 34S).

Just my 20m€.
d:-)

My intuitive suggestion for CPX RCL L was Z->T, Y->Z, X->thin air, LastY->Y LastX->X. X can be discarded, because its result was never intended.
UNDO of the entire stack would be much more attractive, because it includes also complex dyadic functions (but it has to be determined ......).

Bernhard

[walter b]

(12-01-2014 07:28 PM)PANAMATIK Wrote:  My intuitive suggestion for CPX RCL L was Z->T, Y->Z, X->thin air, LastY->Y LastX->X. X can be discarded, because its result was never intended.

I understand your reasons, but that suggested functionality is not consistent with the standard of CPX RCL. Let's look for UNDO ...

d:-/

[BarryMead]

(12-01-2014 06:45 PM)walter b Wrote:  Instead of LASTxy, I'd prefer an UNDO recalling the entire stack as it was before that erroneous last operation. KISS (but it has to be determined whether that's viable with the WP 34S).

It would be a really nice feature, if it turns out to be practical. So to determine if this potential feature is
practical requires answering the following questions (at least):
1. Where to store the stack? (Fewer general registers?) (Is undo more valuable than these registers?)
2. Is there sufficient flash memory to implement the "Undo" feature, and the implicit automatic save
features that would probably need to be incorporated into the setLastX() and setLastXY() routines
to make them available to all existing operators.
3. Is there a spot on the keyboard to put the "Undo" button (RCL CLx) might work because a partially
complete RCL operation can always be cancelled by the "EXIT" button. Or perhaps "f CLx" like on the 31s
since the CLP function could always be accessed through the "h PFCN" menu.
4. Verification that no existing programs (or very few) would be broken by the feature's implementation.
5. Does the demand for this feature warrant the effort to bring it into existence? What about the effort
to redo the keyboard overlays and change the manual? All of these weigh against such a big change.

Have I left out any milestones that would have to be evaluated to confirm the practicality of this potential
feature?

[Paul Dale]

(12-01-2014 05:10 PM)brouhaha Wrote:  The undo save could be in the non-battery-backed 4K of RAM. If you turn the 34S off, or leave it idle so it turns itself off, then undo would not be available when you turn it back on.

Flash space could probably be found. The problem is that we use every last byte of the volatile RAM during some operations (statistics and matrix functions). There simply is nowhere to store UNDO memory.

The only way I can see to include such a feature would be to install a SPI memory device.


- Pauli

[Marcus von Cube]

(12-01-2014 05:10 PM)brouhaha Wrote:  The undo save could be in the non-battery-backed 4K of RAM. If you turn the 34S off, or leave it idle so it turns itself off, then undo would not be available when you turn it back on.

Sorry to disappoint you but the non volatile memory is lost between keystrokes, not when the device is "turned off". When you see the display contents and nothing else is going on, the core is powered down, just the display controller is active.

[PANAMATIK]

(12-01-2014 09:29 PM)Paul Dale Wrote:  Flash space could probably be found. The problem is that we use every last byte of the volatile RAM during some operations (statistics and matrix functions). There simply is nowhere to store UNDO memory.

I hope this is not too complicated:

UNDO (or the less RAM consuming RCL LastXY) should not become a programmable function and must be used directly after having performed the wrong dyadic function. Perhaps most (or all?) of them don't use all RAM. However if there is a dyadic function which uses all RAM, a flag will be set and UNDO is not available after this complicated function.

As I understood there must be battery backuped memory availabe for that purpose.

Bernhard

[Paul Dale]

(12-01-2014 10:11 PM)PANAMATIK Wrote:  I hope this is not too complicated:
...

Not complicated, but completely inconsistent.
Why should some functions be undoable but others not?
Not a positive user experience in my view.


-- Pauli