A case against the x<>y key

05102015, 08:14 PM
Post: #21




RE: A case against the x<>y key
(05102015 06:49 PM)Thomas Klemm Wrote: That's not how to calculate \(9^{2^3}\). Honestly, when I ran through this initially, I made two shortcuts: eliminated the sign change owing, as you said, to the innermost expression being squared; and I did \(9^8\) to save a level on the stack. The extra enter is indeed a mistake (corrected). Ceci n'est pas une signature. 

05102015, 08:51 PM
(This post was last modified: 05102015 08:56 PM by Mark Hardman.)
Post: #22




RE: A case against the x<>y key
(05102015 03:51 PM)hansklav Wrote: I certainly wouldn’t advise a starting RPNuser to do it like this on a 4level calculator without SOS. This is exactly the sort of example you would want in a later chapter in a beginner's guide to RPN. The four level stack is a hard limitation for all but a few nongraphing RPN calculators. The user needs to embrace the possibility of stack overflow instead of fearing it. Part of mastering the 4 level stack, is the ability to quickly "preparse" an expression for a plan of attack and for pitfalls and possible overflow. For me, I first parsed this as you did: a  b + c + d. Red flag, there is a nonassociative operation, I'm going to need to have a and b on the stack in that order at some time. It might as well be early on so I'm only using one stack level rather than two. That takes care of the first and second terms of the equation. The third term: no problem thereit can be done with three levels of the stack and still only use one stack level when complete. Last term: red flag, the innermost part of this term will potentially overflow the remaining three levels of the stack; but the 9^2^3 is really 9^8 (or can be done in two levels using x<>y). Good, we're safe from overflow and have a plan of attackGO! This took all of 5 seconds and saved me possible minutes during the course of evaluation. IMHO, the key to success with the 4 level stack is thinking about how a particular expression should be solved. Rules that the Beginning User "Has to" or "Should" follow can cause more harm than good. Ceci n'est pas une signature. 

05102015, 09:32 PM
Post: #23




RE: A case against the x<>y key
Does anyone know of an example in a HP produced manual that shows an example of this type of problem?


05102015, 09:37 PM
Post: #24




RE: A case against the x<>y key
The author of the WP 31S User’ Manual sent me the relevant page with the corrected key sequence.
Please note that the correction only involves the last few keystrokes (after 5 /). They were: … + 1 x<>y – Corrected: … – 1 + Also note that this way of doing things, starting at the innermost parentheses and working backwards to the leftmost part of the calculation, only takes 3 stack levels. Hans 

05102015, 09:44 PM
Post: #25




RE: A case against the x<>y key
(05102015 09:32 PM)Steve Simpkin Wrote: Does anyone know of an example in a HP produced manual that shows an example of this type of problem? There is the famous Mach number equation from the HP67/97 manual: \[\sqrt{ 5 \left [ \left ( \left \{ \Bigg [ \Bigg ( 1 + 0.2 \left [ \frac{350}{661.5} \right ]^{2} \Bigg )^{3.5}  1 \Bigg ] \Bigg [ 1 \left ( 6.875 \times 10^{6} \right ) 25,500 \Bigg ] ^{5.2656}\right \} + 1 \right )^{0.286} 1 \right ]}\] Ceci n'est pas une signature. 

05102015, 09:55 PM
Post: #26




RE: A case against the x<>y key
I knew it could be done on a four level stack, just not strictly left to right. The final term can be evaluated as 6 7 / 45 x<>y y^{x} but that isn't left to right and uses the x<>y operation which this thread is about.
Interestingly, on the original HP 35 this would become 6 7 / 45 y^{x} saving a keystroke and not using x<>y.  Pauli 

05102015, 11:01 PM
Post: #27




RE: A case against the x<>y key
(05102015 09:44 PM)Mark Hardman Wrote:(05102015 09:32 PM)Steve Simpkin Wrote: Does anyone know of an example in a HP produced manual that shows an example of this type of problem? I remember that problem very well from the HP25 manual as well. I think it doesn't have the same type of potential "trap" as the OP had in their example. The solution shown in the HP manual for the Mach problem did not use the X<>Y key for the "1" area of the problem but I believe they could have used it in this case without issue. 

05112015, 12:09 AM
(This post was last modified: 05142015 11:41 AM by hansklav.)
Post: #28




RE: A case against the x<>y key
(05102015 08:51 PM)Mark Hardman Wrote:(05102015 03:51 PM)hansklav Wrote: I certainly wouldn’t advise a starting RPNuser to do it like this on a 4level calculator without SOS. I contemplate adding this example to my Tutorial (first I have to ask its auctor intellectualis); if it will be added I will certainly be glad if I may use (parafrase) your text as one of the ways to solve it. Quote:IMHO, the key to success with the 4 level stack is thinking about how a particular expression should be solved. Quite so. Quote:Rules that the Beginning User "Has to" or "Should" follow can cause more harm than good. I beg to differ here. The Beginning User certainly will need some Rules of Thumb. These aren’t hard ‘Laws’ that ‘Should’ be followed, but a framework to start thinking about a calculation. I hope to have given some important Rules of Thumb in the ‘Cheat Sheet’ of my Tutorial. One of the Rules of Thumb is to start a calculation preferably from within the innermost parentheses and work outwards (in the rest of this post when I write ‘rule(s)’ I will mean Rule(s) of Thumb in the above explained sense). HP gives this rule starting from the Owner’s Handbook of the HP‑25 (1975). There are exceptions to this rule but in most cases it’s very helpful. That this particular calculation can be solved from lefttoright is a mere coincidence and doesn’t invalidate the rule (see the number of stack levels used in both strategies: 4 in the lefttoright method, 3 in the fromwithinout method). Given this first rule in many calculations one has to do some noncommutative operations ‘backwards’. The question (and the reason I started this tread) is: what is the best method to teach to beginners as a rule (of Thumb!) to do these operations backwards? One method is to look carefully to the structure of the calculation to see if doing things backwards can be avoided at all. That is Thomas Radtke’s strategy. But stackwise this may not be the most economical way, because you have to use one stack level for the intermediate result of the part within parentheses. So it may be good to have a rule (of thumb) to do all remaining operations backwards. My main point of this thread is that using the x<>y key is not the best strategy to teach as a rule (of thumb) to starting RPNusers, because sometimes it works correctly, but sometimes it doesn’t (see the error in the WP 31S manual). The other strategy is regarding each and every subtraction as an addition of the negative of the subtrahend. This strategy can be effected in two ways: using the CHS key and without using it (this last method it followed in the corrected page of the manual). The problem with the x<>y key is that it only works when the subtraction that has to be done backward is the rightmost operation of a series of additions and subtractions on the same level of parentheses (or the only operation). The problem with the method without using CHS is that it fails in this same spot: the rightmost operation of a series of additions and subtractions (unless the stack is empty, i.e. filled with zero's; but that's a trivial case). The method using CHS and + works in all cases and places, so that's my favourite candidate strategy to teach to starting RPNusers when doing a subtraction backwards. Hans 

05112015, 12:20 AM
Post: #29




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, you don't. As it happens, I started with the most complicated term in that equation, which happened to be at the righthand end, and then worked to the left, adding  and subtracting  terms, but never ran out of stack. It would have worked equally well going from left to right, though. So I'm afraid I'm still not seeing a problem. In practice, RPN users tend to be scientists and engineers, for whom the calculation represents physical quantities and logical steps in getting an answer. RPN meets their needs very well with a fourlevel stack. It only runs into trouble if you try to evaluate complex algebraic expressions lefttoright in a kind of mindlessly algorithmic fashion. I can't help feeling that you're approaching RPN with the wrong mindset.  Les [http://www.lesbell.com.au] 

05112015, 12:24 AM
Post: #30




RE: A case against the x<>y key
(05102015 08:51 PM)Mark Hardman Wrote: IMHO, the key to success with the 4 level stack is thinking about how a particular expression should be solved. Rules that the Beginning User "Has to" or "Should" follow can cause more harm than good. Exactly! As I just commented, for the typical user in HP's target market for RPN  scientists and engineers  the expression being evaluated has meaning, and they will tend to evaluate it in the light of that meaning, rather than robotically from left to right as a notverybright parsing algorithm would do.  Les [http://www.lesbell.com.au] 

05112015, 03:23 AM
Post: #31




RE: A case against the x<>y key
(05112015 12:09 AM)hansklav Wrote: One method is to look carefully to the structure of the calculation to see if doing things backwards can be avoided at all. That is Thomas Klemm’s strategy. Not sure what you refer to. I just pointed out that \(9^{2^3}\) is equal to \((9^{2^3})\) and not \((9)^{2^3}\). The fact that Mark corrected the superfluous ENTER but not the false position of CHS irritates me a little. Cheers Thomas 

05112015, 03:39 AM
Post: #32




RE: A case against the x<>y key
(05112015 03:23 AM)Thomas Klemm Wrote: Not sure what you refer to. I just pointed out that \(9^{2^3}\) is equal to \((9^{2^3})\) and not \((9)^{2^3}\). The fact that Mark corrected the superfluous ENTER but not the false position of CHS irritates me a little. This really illustrates the point I'm making: the problem is the ambiguity of "conventional" algebraic notation, which doesn't exist in RPN. A user who is solving his own problem, and not just mechanically inserting numbers into a formula, will know whether he wants \((9^{2^3})\) or \((9)^{2^3}\) and will naturally do the right thing.  Les [http://www.lesbell.com.au] 

05112015, 03:49 AM
Post: #33




RE: A case against the x<>y key  
05112015, 04:18 AM
Post: #34




RE: A case against the x<>y key
(05112015 03:49 AM)Thomas Klemm Wrote: There's nothing ambiguous in the notation of \(9^{2^3}\). What I meant is that it's ambiguous in the sense that it requires reference to a set of rules for precedence and associativity, which it seems not everyone knows or agrees on, if variations between programming language are any indication. RPN is complete, by comparison  press \(y^x\) and it executes immediately.  Les [http://www.lesbell.com.au] 

05112015, 05:07 AM
Post: #35




RE: A case against the x<>y key
(05112015 04:18 AM)Les Bell Wrote: What I meant is that it's ambiguous in the sense that it requires reference to a set of rules for precedence and associativity Sure. That's what makes the expression unambiguous. It's more convenient to write \(ax^2+bx+c\) instead of \(((a\times (x^2))+(b\times x))+c\). Quote:which it seems not everyone knows or agrees on If unsure about the convention you can still use parentheses to make the expression unambiguous. Quote:if variations between programming language are any indication. I don't see how programming languages have anything to do with a mathematical expression like \(9^{2^3}\). How would you even use that in a program? Quote:RPN is complete, by comparison  press \(y^x\) and it executes immediately. There are probably good reasons to use infix notation for mathematical expressions. But whether you use prefix, infix or postfix notation: they are all equivalent and unambiguous. Cheers Thomas 

05112015, 06:10 AM
Post: #36




RE: A case against the x<>y key
(05112015 05:07 AM)Thomas Klemm Wrote:(05112015 04:18 AM)Les Bell Wrote: which it seems not everyone knows or agrees on That's fine if the person writing the expression is unsure. Surely the bigger problem is the many readers who get it wrong? There have been times when I've been quite clear about what I mean, but I've parenthesized expressions to make it clear for the reader. (05112015 05:07 AM)Thomas Klemm Wrote:Quote:if variations between programming language are any indication. What I am getting at is that a) designers of programming languages implement precedence and associativity differently, which is why programming language textbooks often contain definitive tables, and b) programming languages are often the route by which people internalize and develop the concepts of precedence and associativity. I believe similar variation exists in algebraic calculators, which may also colour people's experience and expectations. This isn't the first thread to touch upon this problem. You seem to be adamant that algebraic notation is absolutely clear and unambiguous, and that any misinterpretation is down to stupidity on the part of the user. I agree that algebraic notation is  given a specified semantics common to both writer and reader  completely unambiguous, but I also tend to the view that people are only human and fallible, and miscommunication is possible because of the semantic variations that exist in this area. If that wasn't the case, this thread wouldn't exist. What you're saying is, in effect, "If people would just do it right every time  like I do  then they wouldn't get it wrong". While this is true, it's not very helpful  they do get it wrong, and I'm more interested in exploring why. I'd rather help people than scold them. My overall point is that, for many or most RPN users, the semantics of the problem domain governs their problemsolving keystrokes, and these problems never arise.  Les [http://www.lesbell.com.au] 

05112015, 09:49 AM
Post: #37




RE: A case against the x<>y key
(05112015 06:10 AM)Les Bell Wrote: My overall point is that, for many or most RPN users, the semantics of the problem domain governs their problemsolving keystrokes, and these problems never arise. I agree. I did try to solve the OP's example my way without looking at what others suggested and got the right answer straight away. 

05112015, 12:30 PM
Post: #38




RE: A case against the x<>y key
I tried doing this on my 20S just for giggles to see if it would give the correct result, but kept messing up something (usually involving parentheses) toward the end of the formula. It makes one really appreciate how easy it is to correct mistakes in RPN, e.g. I accidentally forgot to multiply by 8!, and a quick LAST X  LAST X got me right back to where I could. After a couple tries at getting it right on the 20S, I gave up and went back to the 32S.


05112015, 02:16 PM
Post: #39




RE: A case against the x<>y key
From an RPN keystroke programming perspective, I can't imagine not having and using x<>y. It was there on the first HP handheld programmable (HP65) and all subsequent ones, AFAIK, because it serves a legitimate purpose in stack manipulation. It is as necessary as the four arithmetic operation keys, and ENTER.
I would never advise anyone not to use it. Users of these calculators are assumed to know the behavior of each key. 

05112015, 03:59 PM
(This post was last modified: 05112015 04:01 PM by Massimo Gnerucci.)
Post: #40




RE: A case against the x<>y key
(05112015 02:16 PM)Don Shepherd Wrote: I can't imagine not having and using x<>y. It was there on the first HP handheld programmable (HP65) and all subsequent ones, It was there since the HP35. Or the 9100A, if you prefer. ;) Greetings, Massimo +×÷ ↔ left is right and right is wrong 

« Next Oldest  Next Newest »

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