+- 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 - hansklav - 05-11-2015 09:41 PM
(05-11-2015 03:23 AM)Thomas Klemm Wrote:(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.
I referred to you writing:
(05-10-2015 12:49 PM)Thomas Radtke Wrote: (…) 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.
That’s a sound way to do the calculation.
Hans
RE: A case against the x<>y key - Thomas Klemm - 05-11-2015 10:10 PM
(05-11-2015 09:41 PM)hansklav Wrote:(05-11-2015 03:23 AM)Thomas Klemm Wrote: Not sure what you refer to.
I referred to you writing:
(05-10-2015 12:49 PM)Thomas Radtke Wrote: (...)
So I guess you mixed the two of us.
Cheers
Thomas
RE: A case against the x<>y key - Les Bell - 05-11-2015 10:27 PM
(05-11-2015 02:16 PM)Don Shepherd Wrote: It is as necessary as the four arithmetic operation keys, and ENTER.
Amen! Back in 1973 I had the earliest Sinclair Scientific calculator, which had a three-level stack and no x<>y key. This quite often meant writing down and re-entering intermediate results - a process that was so frustrating that it led me to save all my wages from working through the Easter 1974 university break to buy an HP-45 - which did have x<>y, and a lot more.
(On the other hand, the Sinclair Scientific didn't have an ENTER key, but that wasn't as big a problem in practice - IIRC, after powering on, the stack was filled with zeros, so the first number was followed by "+", which added zero to it. Ugly, but. . . )
RE: A case against the x<>y key - d b - 05-12-2015 12:35 AM
Les; Did your Sinclair suffer from less that optimally de-bounced keys and battery wiggle power off too? Mine does, but on the other hand, the screen is a nice color.
RE: A case against the x<>y key - Dave Britten - 05-12-2015 01:07 AM
(05-12-2015 12:35 AM)Den Belillo (Martinez Ca.) Wrote: Les; Did your Sinclair suffer from less that optimally de-bounced keys and battery wiggle power off too? Mine does, but on the other hand, the screen is a nice color.
My Sinclair Cambridge Programmable definitely has those symptoms.
RE: A case against the x<>y key - Les Bell - 05-12-2015 01:41 AM
(05-12-2015 12:35 AM)Den Belillo (Martinez Ca.) Wrote: Les; Did your Sinclair suffer from less that optimally de-bounced keys and battery wiggle power off too? Mine does, but on the other hand, the screen is a nice color.
Probably - it was a long time ago. When I first built it, it didn't work at all, but I accidentally discovered that freezing it got it going, so I used to put it in the freezer, set up a control systems problem (Routh-Horwitz, etc.) then pull it out and run the numbers as fast as possible before the calculator warmed up and stopped working.
It turned out to be a faulty clock generator circuit - TI supplied a batch of faulty chips - and Sinclair Radionics reworked it. But it was so limited that it only served to make me save hard for that HP-45, and so I didn't use it for much longer. I've no idea what happened to it, but I don't really miss it much.
RE: A case against the x<>y key - Dwight Sturrock - 05-12-2015 11:39 PM
RPN has the luxury of x<>y, roll down and up, at least a 4 level stack with the clever T register. Wonderful tools for everyday and complicated calculations. As with any set of tools, practice makes perfect.
RE: A case against the x<>y key - hansklav - 05-17-2015 10:49 PM
(05-11-2015 10:27 PM)Les Bell Wrote:(05-11-2015 02:16 PM)Don Shepherd Wrote: It is as necessary as the four arithmetic operation keys, and ENTER.Amen! (…)
(05-12-2015 11:39 PM)Dwight Sturrock Wrote: RPN has the luxury of x<>y, roll down and up, at least a 4 level stack with the clever T register. Wonderful tools for everyday and complicated calculations. As with any set of tools, practice makes perfect.
The title of this thread was meant hyperbolically. I concur that the x<>y key or equivalent is invaluable on any RPN calculator.
But there are two aspects of this key that need attention:
1. It can be misused easier than a lot of us RPN'ers might be aware of (albeit misused by engineers or scientists only late at night and after a good glas of wine…)
2. In HP RPN calculator manuals it is the only key mentioned when non-commutative operations like subtraction or division have to be done ‘backwards’ (e.g HP 35s Users Guide, http://www.hp.com/ctg/Manual/c01579350.pdf, p.2.12ff). Its alternatives (CHS and 1/x) are neglected in these manuals (afaik the only exception being the HP-41CX Owner's Manual, Vol. 1, p. 22-23). From a didactic point of view this is unfortunate.
To illustrate these points I’ll give a few simple examples. In the following assume that the rightmost term (6) is the result of a number of operations within parentheses; to simulate a state of "stack-lift enabled" each calculation is started with 6 ENTER. Imagine you would like to preserve as many results from previous operations on the 4-level stack as possible.
The adagium "Inside out, left to right" was used in all four examples as the first solution (A-D (i)). This leads to a correct answer in all cases, but done in this way only preserves one previous result on the stack. In a first attempt to preserve one more stack level we do the calculation ‘backwards’.
Using x<>y to do a non-commutative operation backwards only works when the operator is in the rightmost position (A (iv)), and needs the use of CHS when there are two subtractions next to each other (B (v)). When the subtraction is in any other position doing the calculation backwards using x<>y fails (C-D (v)).
When we use what is taught to every secondary school student, namely that subtraction can be regarded as addition of a negative number we come to a natural solution using CHS and +, which is correct independent of the location of the subtraction (A-D (ii)). Realizing that addition of the negative is equal to subtraction makes it easier to see that its simplified form (A-D (iii)) is correct also.
And only now is it clear (at least to me) that the "Inside out, left to right" strategy can be simplified as well (A-D (iv)).
These examples make clear that for learners of RPN it might be better to solve ‘backwards’ subtractions using CHS and + first and only then learn to use the x<>y key as a special case.
Although in theory the same applies to divisions by changing them into multiplication of the reciprocal (using 1/x and ×), in practice this is less important because divisions seldom appear next to multiplications without the use of parentheses or horizontal fraction bars as vinculum. So in these cases, and also in stacked power operations, use of x<>y will hardly ever be a problem.
Hans
RE: A case against the x<>y key - Thomas Klemm - 05-18-2015 08:35 PM
(05-17-2015 10:49 PM)hansklav Wrote:
For those who use a browser that doesn't display a PDF as an image: Code Examples
Cheers
Thomas
RE: A case against the x<>y key - Thomas Klemm - 05-18-2015 10:06 PM
You could use the calculation of cos(x) as a practical example:
\(\begin{align*}
\cos(x) &= 1-\frac{x^2}{2!}+\frac{x^4}{4!}-\frac{x^6}{6!}+\frac{x^8}{8!}-\frac{x^{10}}{10!}+O(x^{12})\\
&= 1-\frac{x^2}{1\cdot2}(1-\frac{x^2}{3\cdot4}(1-\frac{x^2}{5\cdot6}(1-\frac{x^2}{7\cdot8}(1-\frac{x^2}{9\cdot10}))))+O(x^{12})
\end{align*}\)
Using the x<>y key:
x2 ENTER ENTER ENTER
90 ÷ 1 x<>y −
× 56 ÷ 1 x<>y −
× 30 ÷ 1 x<>y −
× 12 ÷ 1 x<>y −
× 2 ÷ 1 x<>y −
Using the CHS key:
x2 CHS ENTER ENTER ENTER
90 ÷ 1 +
× 56 ÷ 1 +
× 30 ÷ 1 +
× 12 ÷ 1 +
× 2 ÷ 1 +
Kind regards
Thomas