A case against the x<>y key

05092015, 10:49 PM
(This post was last modified: 05102015 11:53 AM by hansklav.)
Post: #1




A case against the x<>y key
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: \(1b+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 eyeopener because the above mentioned manual is written by an academically educated professional and (I’m sure) seasoned RPNuser. So even experienced and intelligent RPNusers 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 noncommutative operations backwards should be considered potentially harmful. It is safe to use this key to do an isolated noncommutative 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 noncommutative operations (e.g. HP41CX, HP 33s, HP 35s) do not warn against its misuse. The HP41CX 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 

05102015, 12:56 AM
Post: #2




RE: A case against the x<>y key
(05092015 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. I just banged through that calculation nearsubconsciously, 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 overcomplicating something that is really quite simple, and possibly misinterpreting the original example.  Les [http://www.lesbell.com.au] 

05102015, 01:13 AM
Post: #3




RE: A case against the x<>y key
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 

05102015, 02:20 AM
Post: #4




RE: A case against the x<>y key
(05092015 10:49 PM)hansklav Wrote: The implied parentheses should be placed as follows: 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] "Inside out, left to right" Ceci n'est pas une signature. 

05102015, 04:06 AM
(This post was last modified: 05102015 04:18 AM by Tugdual.)
Post: #5




RE: A case against the x<>y key
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).


05102015, 05:16 AM
Post: #6




RE: A case against the x<>y key
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 RP) on them. Surveyors call this inversing and we do it often. I let the program do the ordering and reordering and that uses X<>Y each goaround. 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 fatfinger a key. Data entry itself is enough of a chance for error to creep in.


05102015, 10:25 AM
Post: #7




RE: A case against the x<>y key
(05102015 12:56 AM)Les Bell Wrote:(05092015 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. I sent you a copy of the relevant page. Hans 

05102015, 10:37 AM
(This post was last modified: 05102015 10:38 AM by hansklav.)
Post: #8




RE: A case against the x<>y key
(05102015 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 SSIZE8mode I personally would start from within the innermost parentheses. Hans 

05102015, 10:43 AM
(This post was last modified: 05102015 11:12 AM by hansklav.)
Post: #9




RE: A case against the x<>y key
(05102015 02:20 AM)Mark Hardman Wrote:(05092015 10:49 PM)hansklav Wrote: The implied parentheses should be placed as follows: 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 

05102015, 10:59 AM
(This post was last modified: 10122015 11:42 PM by hansklav.)
Post: #10




RE: A case against the x<>y key
(05102015 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 RP) on them. Surveyors call this inversing and we do it often. I let the program do the ordering and reordering and that uses X<>Y each goaround. 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 fatfinger 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 noncommutative 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 ;) 

05102015, 12:35 PM
Post: #11




RE: A case against the x<>y key  
05102015, 12:49 PM
Post: #12




RE: A case against the x<>y key
(05102015 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 12*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 4level stack perfectly. . 

05102015, 02:32 PM
Post: #13




RE: A case against the x<>y key
(05102015 10:43 AM)hansklav Wrote:(05102015 02:20 AM)Mark Hardman Wrote: Your point is valid. But, why do you feel that a negative b term (b) is even necessary? No you don't. You say you've written a tutorial on RPN? Ceci n'est pas une signature. 

05102015, 02:32 PM
Post: #14




RE: A case against the x<>y key
(05102015 12:49 PM)Thomas Radtke Wrote:(05102015 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 12*3^4/5, which have to be .calculated befor adding the sum of the two rightmost terms. True, but my reply was to Mark Hardman’s post, who started the whole calculation from the left side, and then a 4level 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. (05102015 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: 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 

05102015, 03:02 PM
(This post was last modified: 05102015 03:06 PM by Thomas Radtke.)
Post: #15




RE: A case against the x<>y key
(05102015 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 4level stack will not suffice.I see (not everythingshould work from left to right, too), sorry! (05102015 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 . 

05102015, 03:12 PM
(This post was last modified: 05102015 08:16 PM by Mark Hardman.)
Post: #16




RE: A case against the x<>y key
(05102015 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 4level stack will not suffice. Again, you've written an RPN tutorial!?! Code: x y z t Ceci n'est pas une signature. 

05102015, 03:48 PM
Post: #17




RE: A case against the x<>y key
(05102015 02:32 PM)hansklav Wrote:(emphasis is mine)(05102015 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 ... 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 :) JF 

05102015, 03:51 PM
(This post was last modified: 05102015 03:56 PM by hansklav.)
Post: #18




RE: A case against the x<>y key
(05102015 03:12 PM)Mark Hardman Wrote:(05102015 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 4level stack will not suffice. You don’t believe it? Please, feel free to let me know where it can be made better ;) Quote: 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 RPNuser to do it like this on a 4level calculator without SOS. Hans 

05102015, 04:10 PM
Post: #19




RE: A case against the x<>y key
(05102015 03:12 PM)Mark Hardman Wrote: Again, you've written an RPN tutorial!?! Well done Mark! Greetings, Massimo +×÷ ↔ left is right and right is wrong 

05102015, 06:49 PM
Post: #20




RE: A case against the x<>y key
(05092015 10:49 PM)hansklav Wrote: (05102015 03:12 PM)Mark Hardman Wrote: 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. 

« Next Oldest  Next Newest »

User(s) browsing this thread: 1 Guest(s)