A case against the x<>y key

[hansklav]

(05-11-2015 10:27 PM)Les Bell Wrote:  

(05-11-2015 02:16 PM)Don Shepherd Wrote:  It is as necessary as the four arithmetic operation keys, and ENTER.

Amen! (…)

(05-12-2015 11:39 PM)Dwight Sturrock Wrote:  RPN has the luxury of x<>y, roll down and up, at least a 4 level stack with the clever T register. Wonderful tools for everyday and complicated calculations. As with any set of tools, practice makes perfect.

The title of this thread was meant hyperbolically. I concur that the x<>y key or equivalent is invaluable on any RPN calculator.

But there are two aspects of this key that need attention:
1. It can be misused easier than a lot of us RPN'ers might be aware of (albeit misused by engineers or scientists only late at night and after a good glas of wine…)
2. In HP RPN calculator manuals it is the only key mentioned when non-commutative operations like subtraction or division have to be done ‘backwards’ (e.g HP 35s Users Guide, http://www.hp.com/ctg/Manual/c01579350.pdf, p.2.12ff). Its alternatives (CHS and 1/x) are neglected in these manuals (afaik the only exception being the HP-41CX Owner's Manual, Vol. 1, p. 22-23). From a didactic point of view this is unfortunate.

To illustrate these points I’ll give a few simple examples. In the following assume that the rightmost term (6) is the result of a number of operations within parentheses; to simulate a state of "stack-lift enabled" each calculation is started with 6 ENTER. Imagine you would like to preserve as many results from previous operations on the 4-level stack as possible.

The adagium "Inside out, left to right" was used in all four examples as the first solution (A-D (i)). This leads to a correct answer in all cases, but done in this way only preserves one previous result on the stack. In a first attempt to preserve one more stack level we do the calculation ‘backwards’.

Using x<>y to do a non-commutative operation backwards only works when the operator is in the rightmost position (A (iv)), and needs the use of CHS when there are two subtractions next to each other (B (v)). When the subtraction is in any other position doing the calculation backwards using x<>y fails (C-D (v)).

When we use what is taught to every secondary school student, namely that subtraction can be regarded as addition of a negative number we come to a natural solution using CHS and +, which is correct independent of the location of the subtraction (A-D (ii)). Realizing that addition of the negative is equal to subtraction makes it easier to see that its simplified form (A-D (iii)) is correct also.
And only now is it clear (at least to me) that the "Inside out, left to right" strategy can be simplified as well (A-D (iv)).

These examples make clear that for learners of RPN it might be better to solve ‘backwards’ subtractions using CHS and + first and only then learn to use the x<>y key as a special case.

Although in theory the same applies to divisions by changing them into multiplication of the reciprocal (using 1/x and ×), in practice this is less important because divisions seldom appear next to multiplications without the use of parentheses or horizontal fraction bars as vinculum. So in these cases, and also in stacked power operations, use of x<>y will hardly ever be a problem.

Hans