+- 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)
RE: A case against the x<>y key - Mark Hardman - 05-10-2015 08:14 PM
(05-10-2015 06:49 PM)Thomas Klemm 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.
Honestly, when I ran through this initially, I made two shortcuts: eliminated the sign change owing, as you said, to the inner-most expression being squared; and I did \(9^8\) to save a level on the stack.
The extra enter is indeed a mistake (corrected).
RE: A case against the x<>y key - Mark Hardman - 05-10-2015 08:51 PM
(05-10-2015 03:51 PM)hansklav Wrote: I certainly wouldn’t advise a starting RPN-user to do it like this on a 4-level calculator without SOS.
Hans
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 non-graphing 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 "pre-parse" 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 non-associative 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 there--it can be done with three levels of the stack and still only use one stack level when complete. Last term: red flag, the inner-most 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 attack--GO! 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.
RE: A case against the x<>y key - Steve Simpkin - 05-10-2015 09:32 PM
Does anyone know of an example in a HP produced manual that shows an example of this type of problem?
RE: A case against the x<>y key - hansklav - 05-10-2015 09:37 PM
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
RE: A case against the x<>y key - Mark Hardman - 05-10-2015 09:44 PM
(05-10-2015 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 HP-67/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 ]}\]
RE: A case against the x<>y key - Paul Dale - 05-10-2015 09:55 PM
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 yx 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 yx saving a keystroke and not using x<>y.
- Pauli
RE: A case against the x<>y key - Steve Simpkin - 05-10-2015 11:01 PM
(05-10-2015 09:44 PM)Mark Hardman Wrote:(05-10-2015 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 HP-67/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 ]}\]
I remember that problem very well from the HP-25 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.
RE: A case against the x<>y key - hansklav - 05-11-2015 12:09 AM
(05-10-2015 08:51 PM)Mark Hardman Wrote:(05-10-2015 03:51 PM)hansklav Wrote: I certainly wouldn’t advise a starting RPN-user to do it like this on a 4-level 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 non-graphing 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 "pre-parse" 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 non-associative 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 there--it can be done with three levels of the stack and still only use one stack level when complete. Last term: red flag, the inner-most 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 attack--GO! This took all of 5 seconds and saved me possible minutes during the course of evaluation.
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 left-to-right is a mere coincidence and doesn’t invalidate the rule (see the number of stack levels used in both strategies: 4 in the left-to-right method, 3 in the from-within-out method).
Given this first rule in many calculations one has to do some non-commutative 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 stack-wise 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 RPN-users, 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 RPN-users when doing a subtraction backwards.
Hans
RE: A case against the x<>y key - Les Bell - 05-11-2015 12:20 AM
(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, you don't. As it happens, I started with the most complicated term in that equation, which happened to be at the right-hand 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 four-level stack. It only runs into trouble if you try to evaluate complex algebraic expressions left-to-right in a kind of mindlessly algorithmic fashion. I can't help feeling that you're approaching RPN with the wrong mindset.
RE: A case against the x<>y key - Les Bell - 05-11-2015 12:24 AM
(05-10-2015 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 not-very-bright parsing algorithm would do.
RE: A case against the x<>y key - Thomas Klemm - 05-11-2015 03:23 AM
(05-11-2015 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
RE: A case against the x<>y key - Les Bell - 05-11-2015 03:39 AM
(05-11-2015 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.
RE: A case against the x<>y key - Thomas Klemm - 05-11-2015 03:49 AM
(05-11-2015 03:39 AM)Les Bell Wrote: the problem is the ambiguity of "conventional" algebraic notation, which doesn't exist in RPN.
There's nothing ambiguous in the notation of \(-9^{2^3}\).
Kind regards
Thomas
RE: A case against the x<>y key - Les Bell - 05-11-2015 04:18 AM
(05-11-2015 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.
RE: A case against the x<>y key - Thomas Klemm - 05-11-2015 05:07 AM
(05-11-2015 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
RE: A case against the x<>y key - Les Bell - 05-11-2015 06:10 AM
(05-11-2015 05:07 AM)Thomas Klemm Wrote:(05-11-2015 04:18 AM)Les Bell Wrote: which it seems not everyone knows or agrees on
If unsure about the convention you can still use parentheses to make the expression unambiguous.
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.
(05-11-2015 05:07 AM)Thomas Klemm Wrote: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?
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 problem-solving keystrokes, and these problems never arise.
RE: A case against the x<>y key - RMollov - 05-11-2015 09:49 AM
(05-11-2015 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 problem-solving 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.
RE: A case against the x<>y key - Dave Britten - 05-11-2015 12:30 PM
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.
RE: A case against the x<>y key - Don Shepherd - 05-11-2015 02:16 PM
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 (HP-65) 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.
RE: A case against the x<>y key - Massimo Gnerucci - 05-11-2015 03:59 PM
(05-11-2015 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 (HP-65) and all subsequent ones,
It was there since the HP-35.
Or the 9100A, if you prefer. ;)