A case against the x<>y key

[hansklav]

(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