A case against the x<>y key - Printable Version

A case against the x<>y key - Printable Version

+- HP Forums (https://www.hpmuseum.org/forum)
+-- Forum: HP Calculators (and very old HP Computers) (/forum-3.html)
+--- Forum: General Forum (/forum-4.html)
+--- Thread: A case against the x<>y key (/thread-3810.html)

Pages: 1 2 3

A case against the x<>y key - hansklav - 05-09-2015 10:49 PM

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):

[Image: WP31S132.gif]

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

RE: A case against the x<>y key - Les Bell - 05-10-2015 12:56 AM

(05-09-2015 10:49 PM)hansklav Wrote: 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.
[...]
P.S. the correct answer to eight decimals is 1657.00894809

I just banged through that calculation near-subconsciously, without giving any thought to the alleged evils of x<>y, and got the same answer.

Which manual did you take this from? I'd like to see the original. But I suspect you're massively over-complicating something that is really quite simple, and possibly misinterpreting the original example.

RE: A case against the x<>y key - Paul Dale - 05-10-2015 01:13 AM

There is only one point in the formula where you overflow a four level stack working left to right (45 to the six sevenths term).

In SSIZE8 on my trusty 34S, there is no issue at all.

- Pauli

RE: A case against the x<>y key - Mark Hardman - 05-10-2015 02:20 AM

(05-09-2015 10:49 PM)hansklav Wrote: 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 – +.

Your point is valid. But, why do you feel that a negative b term (-b) is even necessary?

Simply let the stack do its job:

Code:

1 [Enter]

3 [Enter]

4

Y^X

2

x

5

/

-

etc.

"Inside out, left to right"

RE: A case against the x<>y key - Tugdual - 05-10-2015 04:06 AM

I would spontaneously not use a stack swap, just push things on stack as they come and read from left to right (as Mark said).

RE: A case against the x<>y key - d b - 05-10-2015 05:16 AM

I seldom use the X<>Y in hand calculations but have used it in programs more. For instance entering N & E for a point together then the same for another point so as to use the distance formula (or R-P) on them. Surveyors call this inversing and we do it often. I let the program do the ordering and re-ordering and that uses X<>Y each go-around. BTW: the reason surveyors use programs to do something this simple is that we do do it a lot and sooner or later we all fat-finger a key. Data entry itself is enough of a chance for error to creep in.

RE: A case against the x<>y key - hansklav - 05-10-2015 10:25 AM

(05-10-2015 12:56 AM)Les Bell Wrote:
(05-09-2015 10:49 PM)hansklav Wrote: 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.
[...]
P.S. the correct answer to eight decimals is 1657.00894809

I just banged through that calculation near-subconsciously, without giving any thought to the alleged evils of x<>y, and got the same answer.

Which manual did you take this from? I'd like to see the original. But I suspect you're massively over-complicating something that is really quite simple, and possibly misinterpreting the original example.

I sent you a copy of the relevant page.

Hans

RE: A case against the x<>y key - hansklav - 05-10-2015 10:37 AM

(05-10-2015 01:13 AM)Paul Dale Wrote: There is only one point in the formula where you overflow a four level stack working left to right (45 to the six sevenths term).

That's why it’s wise to start such a calculation from within the innermost parentheses using an RPN calculator with only four stack levels.

Quote:In SSIZE8 on my trusty 34S, there is no issue at all.

True, but you still have to count the number of stack levels you use to be sure that your answer is correct (because there is no stack overflow sensing built into the WP 34S). So to avoid that even on the WP 34S or WP 31S in SSIZE8-mode I personally would start from within the innermost parentheses.

Hans

RE: A case against the x<>y key - hansklav - 05-10-2015 10:43 AM

(05-10-2015 02:20 AM)Mark Hardman Wrote:
(05-09-2015 10:49 PM)hansklav Wrote: 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 – +.

Your point is valid. But, why do you feel that a negative b term (-b) is even necessary?

Simply let the stack do its job:

Code:

1 [Enter] 3 [Enter] 4 Y^X 2 x 5 / - etc.

"Inside out, left to right"

Well, as Paul Dale pointed out, on a four level stack RPN calculator then you will run into trouble (stack overflow, leading to a wrong answer, without warning), unless, of course, you make use of STO and RCL.

Hans

RE: A case against the x<>y key - hansklav - 05-10-2015 10:59 AM

(05-10-2015 05:16 AM)Den Belillo (Martinez Ca.) Wrote: I seldom use the X<>Y in hand calculations but have used it in programs more. For instance entering N & E for a point together then the same for another point so as to use the distance formula (or R-P) on them. Surveyors call this inversing and we do it often. I let the program do the ordering and re-ordering and that uses X<>Y each go-around. BTW: the reason surveyors use programs to do something this simple is that we do do it a lot and sooner or later we all fat-finger a key. Data entry itself is enough of a chance for error to creep in.

OK, that is a valid and safe use of the x<>y key.

Also I think when doing several ’stacked‘ power calculations backwards, like in \(9^{2^{3}} \), the use of this key is safe. My point is that when doing the most frequently occurring non-commutative calculations (subtractions and divisions) backwards its use is unsafe in some situations. And you don't have to be a newbie to make a mistake in such situations, as this case proves.

Hans

P.S. The title exaggerates the problem a bit, on purpose ;-)

RE: A case against the x<>y key - Thomas Radtke - 05-10-2015 12:35 PM

(05-10-2015 10:25 AM)hansklav Wrote: I sent you a copy of the relevant page.

Would you mind stating which calculator manual this is from?

And thanks for the interesting read this thread has become :-).

RE: A case against the x<>y key - Thomas Radtke - 05-10-2015 12:49 PM

(05-10-2015 10:43 AM)hansklav Wrote: Well, as Paul Dale pointed out, on a four level stack RPN calculator then you will run into trouble (stack overflow, leading to a wrong answer, without warning), unless, of course, you make use of STO and RCL.

No need to. You can evaluate from right to left until the first two terms 1-2*3^4/5, which have to be .calculated befor adding the sum of the two rightmost terms.

1688... in x, then [3][ENTER][4][y^x][5][/][2][*][1][x<>y][-][+]

Fits a 4-level stack perfectly.

.

RE: A case against the x<>y key - Mark Hardman - 05-10-2015 02:32 PM

(05-10-2015 10:43 AM)hansklav Wrote:
(05-10-2015 02:20 AM)Mark Hardman Wrote: Your point is valid. But, why do you feel that a negative b term (-b) is even necessary?

Simply let the stack do its job:

Code:

1 [Enter] 3 [Enter] 4 Y^X 2 x 5 / - etc.

"Inside out, left to right"

Well, as Paul Dale pointed out, on a four level stack RPN calculator then you will run into trouble (stack overflow, leading to a wrong answer, without warning), unless, of course, you make use of STO and RCL.

Hans

No you don't.

You say you've written a tutorial on RPN?

RE: A case against the x<>y key - hansklav - 05-10-2015 02:32 PM

(05-10-2015 12:49 PM)Thomas Radtke Wrote:
(05-10-2015 10:43 AM)hansklav Wrote: Well, as Paul Dale pointed out, on a four level stack RPN calculator then you will run into trouble (stack overflow, leading to a wrong answer, without warning), unless, of course, you make use of STO and RCL.
No need to. You can evaluate from right to left until the first two terms 1-2*3^4/5, which have to be .calculated befor adding the sum of the two rightmost terms.

1688.40894809 in x, then [3][ENTER][4][y^x][5][/][2][*][1][x<>y][-][+]

Fits a 4-level stack perfectly.

True, but my reply was to Mark Hardman’s post, who started the whole calculation from the left side, and then a 4-level stack will not suffice.

But Mark also wrote "Inside out, left to right", and possibly he meant for this calculation "first do the rightmost part from inside out, and then the rest (his listing) from left to right". Your solution partially uses that adagium.

(05-10-2015 12:35 PM)Thomas Radtke Wrote: Would you mind stating which calculator manual this is from?

The author himself of said manual (the spiral bound version of the WP 31S User’s Manual) sent me the simplest fix, which is even one keystroke shorter than yours:

1688.40894809 in x, then [3][ENTER][4][y^x][5][/][2][*][-][1][+]

So no need to use either CHS or x<>y !

The relevant part of the corrected page will now look as follows:

[Image: Precedence_corrected.png]

I must admit that I didn’t think of the latter possibility myself, probably because mentally it also uses the addition of a negative and then the use of CHS is more intuitive.

So now we’re left with several solutions to the same problem.

The question is: which one should we teach to newbies?
I’ll come back to that later.

Hans

RE: A case against the x<>y key - Thomas Radtke - 05-10-2015 03:02 PM

(05-10-2015 02:32 PM)hansklav Wrote: True, but my reply was to Mark Hardman’s post, who started the whole calculation from the left side, and then a 4-level stack will not suffice.

I see (not everything-should work from left to right, too), sorry!

(05-10-2015 02:32 PM)hansklav Wrote: The question is: which one should we teach to newbies?

The simplest not requiring doing any calculations in mind, but pointing out that algebraic considerations are unfortunately necessary: Mine Tongue

RE: A case against the x<>y key - Mark Hardman - 05-10-2015 03:12 PM

(05-10-2015 02:32 PM)hansklav Wrote: True, but my reply was to Mark Hardman’s post, who started the whole calculation from the left side, and then a 4-level stack will not suffice.

Again, you've written an RPN tutorial!?!

Code:

              x          y          z          t

1 [Enter]     1          -          -          -

3 [Enter]     3          1          -          -

4             4          3          1          -

y^x          81          1          -          -

2             2         81          1          -

x           162          1          -          -

5             5        162          1          -

/            32.4        1          -          -

-           -31.4        -          -          -

6 [Enter]     6        -31.4        -          -

7             7          6        -31.4        -

x^2          49          6        -31.4        -

3             3         49          6        -31.4

1/x           0.3333    49          6        -31.4

y^x           3.6593     6        -31.4      -31.4

-             2.3407   -31.4      -31.4      -31.4

sin           0.0408   -31.4      -31.4      -31.4

8             8          0.0408   -31.4      -31.4

x!        40320          0.0408   -31.4      -31.4

x          1646.7276   -31.4      -31.4      -31.4

+          1615.3276   -31.4      -31.4      -31.4

45 [Enter]   45       1615.3276   -31.4      -31.4

6  [Enter]    6         45       1615.3276   -31.4

7             7          6         45       1615.3276

/             0.8571    45       1615.3276  1615.3276

y^x          26.1240  1615.3276  1615.3276  1615.3276

2 [Enter]     2         26.1240  1615.3276  1615.3276

3             3          2         26.1240  1615.3276

y^x           8         26.1240  1615.3276  1615.3276

9 [Chs]      -9          8         26.1240  1615.3276

x<>y          8         -9         26.1240  1615.3276

y^x        4.3047e07    26.1240  1615.3276  1615.3276

x          1.1246e09  1615.3276  1615.3276  1615.3276

x^2        1.2646e18  1615.3276  1615.3276  1615.3276

ln        41.6813     1615.3276  1615.3276  1615.3276

+       1657.0089     1615.3276  1615.3276  1615.3276

RE: A case against the x<>y key - J-F Garnier - 05-10-2015 03:48 PM

(05-10-2015 02:32 PM)hansklav Wrote:
(05-10-2015 12:35 PM)Thomas Radtke Wrote: Would you mind stating which calculator manual this is from?
The author himself of said manual (the spiral bound version of the WP 31S User’s Manual) sent me the simplest fix ...

(emphasis is mine)

Oh, I thought you were speaking about "one of [your] classical RPN calculators".

So I don't need to worry any more, no mistake in a HP classical RPN calculator manual :-)

J-F

RE: A case against the x<>y key - hansklav - 05-10-2015 03:51 PM

(05-10-2015 03:12 PM)Mark Hardman Wrote:
(05-10-2015 02:32 PM)hansklav Wrote: True, but my reply was to Mark Hardman’s post, who started the whole calculation from the left side, and then a 4-level stack will not suffice.

Again, you've written an RPN tutorial!?!

You don’t believe it? Please, feel free to let me know where it can be made better ;-)

Quote:

Code:

x y z t 1 [Enter] 1 - - - 3 [Enter] 3 1 - - 4 4 3 1 - y^x 81 1 - - 2 2 81 1 - x 162 1 - - 5 5 162 1 - / 32.4 1 - - - -31.4 - - - 6 [Enter] 6 -31.4 - - 7 7 6 -31.4 - x^2 49 6 -31.4 - 3 3 49 6 -31.4 1/x 0.3333 49 6 -31.4 y^x 3.6593 6 -31.4 -31.4 - 2.3407 -31.4 -31.4 -31.4 sin 0.0408 -31.4 -31.4 -31.4 8 8 0.0408 -31.4 -31.4 x! 40320 0.0408 -31.4 -31.4 x 1646.7276 -31.4 -31.4 -31.4 + 1615.3276 -31.4 -31.4 -31.4 45 [Enter] 45 1615.3276 -31.4 -31.4 6 [Enter] 6 45 1615.3276 -31.4 7 7 6 45 1615.3276 / 0.8571 45 1615.3276 1615.3276 y^x 26.1240 1615.3276 1615.3276 1615.3276 2 [Enter] 2 26.1240 1615.3276 1615.3276 3 [Enter] 3 2 26.1240 1615.3276 y^x 8 26.1240 1615.3276 1615.3276 9 [Chs] -9 8 26.1240 1615.3276 x<>y 8 -9 26.1240 1615.3276 y^x 4.3047e07 26.1240 1615.3276 1615.3276 x 1.1246e09 1615.3276 1615.3276 1615.3276 x^2 1.2646e18 1615.3276 1615.3276 1615.3276 ln 41.6813 1615.3276 1615.3276 1615.3276 + 1657.0089 1615.3276 1615.3276 1615.3276

Amazing! If you hadn’t written it out so neatly I wouldn’t have believed it possible.
I took Paul Dale's verdict for granted and didn’t even try to do it like this.

I certainly wouldn’t advise a starting RPN-user to do it like this on a 4-level calculator without SOS.

Hans

RE: A case against the x<>y key - Massimo Gnerucci - 05-10-2015 04:10 PM

(05-10-2015 03:12 PM)Mark Hardman Wrote: Again, you've written an RPN tutorial!?!

Code:

x y z t 1 [Enter] 1 - - - 3 [Enter] 3 1 - - 4 4 3 1 - y^x 81 1 - - 2 2 81 1 - x 162 1 - - 5 5 162 1 - / 32.4 1 - - - -31.4 - - - 6 [Enter] 6 -31.4 - - 7 7 6 -31.4 - x^2 49 6 -31.4 - 3 3 49 6 -31.4 1/x 0.3333 49 6 -31.4 y^x 3.6593 6 -31.4 -31.4 - 2.3407 -31.4 -31.4 -31.4 sin 0.0408 -31.4 -31.4 -31.4 8 8 0.0408 -31.4 -31.4 x! 40320 0.0408 -31.4 -31.4 x 1646.7276 -31.4 -31.4 -31.4 + 1615.3276 -31.4 -31.4 -31.4 45 [Enter] 45 1615.3276 -31.4 -31.4 6 [Enter] 6 45 1615.3276 -31.4 7 7 6 45 1615.3276 / 0.8571 45 1615.3276 1615.3276 y^x 26.1240 1615.3276 1615.3276 1615.3276 2 [Enter] 2 26.1240 1615.3276 1615.3276 3 [Enter] 3 2 26.1240 1615.3276 y^x 8 26.1240 1615.3276 1615.3276 9 [Chs] -9 8 26.1240 1615.3276 x<>y 8 -9 26.1240 1615.3276 y^x 4.3047e07 26.1240 1615.3276 1615.3276 x 1.1246e09 1615.3276 1615.3276 1615.3276 x^2 1.2646e18 1615.3276 1615.3276 1615.3276 ln 41.6813 1615.3276 1615.3276 1615.3276 + 1657.0089 1615.3276 1615.3276 1615.3276

Well done Mark!

[Image: tumblr_mftih9viwe1rvzu9do1_400.gif]

RE: A case against the x<>y key - Thomas Klemm - 05-10-2015 06:49 PM

(05-09-2015 10:49 PM)hansklav Wrote:

(05-10-2015 03:12 PM)Mark Hardman Wrote:

Code:

x y z t 2 [Enter] 2 26.1240 1615.3276 1615.3276 3 [Enter] 3 2 26.1240 1615.3276 y^x 8 26.1240 1615.3276 1615.3276 9 [Chs] -9 8 26.1240 1615.3276 x<>y 8 -9 26.1240 1615.3276 y^x 4.3047e07 26.1240 1615.3276 1615.3276

That's not how to calculate \(-9^{2^3}\).
The negative sign changes the whole expression:

2
ENTER
3
y^x
9
x<>y
y^x
CHS

Only since the whole product is squared this doesn't matter.

Cheers
Thomas

PS: The 2nd ENTER after 3 is probably a typo.