A case against the x<>y key

[hansklav]

Lately I had ample time to delve into some of the example calculations described in an attractive User’s Manual of one of my classical RPN calculators. I was especially interested in a challenging calculation given as illustration of the rules of operator precedence, because in my RPN Tutorial I’ve also written on this subject.

I was a bit irritated when I didn’t obtain the given solution in one try, so I tried again. When I got the same answer the second time I took my Prime and entered the calculation in Textbook Mode. This confirmed my previous answers, different from the manual’s.

Then I scutinized the keystroke sequence that led to the flawed solution in the manual, and it was not difficult to see the mistake.

Before reading further try the calculation for yourself, preferably using a classical RPN calculator with four stack levels (angles in sexagesimal degrees):



If your answer starts with negative one seven one nine then you made the same mistake, if it starts with one six five seven then congratulations!

Most people will start from within the innermost parentheses and then work backwards to the start of the calculation. The tricky part is how to proceed after calculating \(2\times3^4\div5\) (and before adding this term to the sum), so the part \(1-…+…\)
If you use the x<>y (exchange x and y) key indiscriminately every time you encounter a minus ’backwards‘ (ending the key sequence as the manual does with … + 1 x<>y – ) things go wrong, because:
\(1-b+c+d ≠ 1-(b+c+d)\)

The implied parentheses should be placed as follows:
\(1 - b + c + d = (1 - b) + c + d\)
So you have to do this part of the calculation backwards using …CHS + 1 +:
\(1 - b + c + d = 1 + -b + c + d\)
or you should do the \(1 - b\) before adding it to the rest of the calculation: … 1 x<>y – +.

For me encountering this mistake is an eye-opener because the above mentioned manual is written by an academically educated professional and (I’m sure) seasoned RPN-user. So even experienced and intelligent RPN-users are not immune to making this type of mistake while using the x<>y key.

This is evidence that the use of the x<>y key to do non-commutative operations backwards should be considered potentially harmful. It is safe to use this key to do an isolated non-commutative operation backwards, but you cannot use it when this operation is part of a series of operations of equal operator precedence on the same level of parentheses (e.g. a series of additions and subtractions or a series of multiplications and divisions), unless it’s the rightmost one.

The HP Manuals that mention the use of the x<>y key in case of non-commutative operations (e.g. HP-41CX, HP 33s, HP 35s) do not warn against its misuse. The HP-41CX Owner’s Manual (Vol. 1) is the only one I know that mentions the use of CHS or 1/x in such situations.

My RPN Tutorial contains a warning against this type of error and gives the methods of changing a subtraction into addition of a negative using CHS and + or changing division into multiplication of a reciprocal using 1/x and \(\times\) as safe alternatives. But having seen the ease with which mistakes can be made using the x<>y key I will change 6. of the ’Cheat Sheet‘ of my RPN Tutorial. In the new version (not finished yet) I will advise to use CHS and 1/x preferentially when doing subtractions and divisions backwards and x<>y only when the user knows exactly what the consequences are.

Hans

P.S. the correct answer to eight decimals is 1657.00894809