A case against the x<>y key

05112015, 09:41 PM
(This post was last modified: 05112015 09:44 PM by hansklav.)
Post: #41




RE: A case against the x<>y key
(05112015 03:23 AM)Thomas Klemm Wrote:(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. I referred to you writing: (05102015 12:49 PM)Thomas Radtke Wrote: (…) 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. That’s a sound way to do the calculation. Hans 

05112015, 10:10 PM
Post: #42




RE: A case against the x<>y key  
05112015, 10:27 PM
Post: #43




RE: A case against the x<>y key
(05112015 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 threelevel stack and no x<>y key. This quite often meant writing down and reentering 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 HP45  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. . . )  Les [http://www.lesbell.com.au] 

05122015, 12:35 AM
Post: #44




RE: A case against the x<>y key
Les; Did your Sinclair suffer from less that optimally debounced keys and battery wiggle power off too? Mine does, but on the other hand, the screen is a nice color.


05122015, 01:07 AM
Post: #45




RE: A case against the x<>y key  
05122015, 01:41 AM
Post: #46




RE: A case against the x<>y key
(05122015 12:35 AM)Den Belillo (Martinez Ca.) Wrote: Les; Did your Sinclair suffer from less that optimally debounced 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 (RouthHorwitz, 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 HP45, 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.  Les [http://www.lesbell.com.au] 

05122015, 11:39 PM
Post: #47




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


05172015, 10:49 PM
(This post was last modified: 05182015 10:51 PM by hansklav.)
Post: #48




RE: A case against the x<>y key
(05112015 10:27 PM)Les Bell Wrote:(05112015 02:16 PM)Don Shepherd Wrote: It is as necessary as the four arithmetic operation keys, and ENTER.Amen! (…) (05122015 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 noncommutative 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 HP41CX Owner's Manual, Vol. 1, p. 2223). 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 "stacklift enabled" each calculation is started with 6 ENTER. Imagine you would like to preserve as many results from previous operations on the 4level stack as possible. The adagium "Inside out, left to right" was used in all four examples as the first solution (AD (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 noncommutative 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 (CD (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 (AD (ii)). Realizing that addition of the negative is equal to subtraction makes it easier to see that its simplified form (AD (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 (AD (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 

05182015, 08:35 PM
Post: #49




RE: A case against the x<>y key
(05172015 10:49 PM)hansklav Wrote: For those who use a browser that doesn't display a PDF as an image: Code Examples Cheers Thomas 

05182015, 10:06 PM
Post: #50




RE: A case against the x<>y key
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: x^{2} 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: x^{2} CHS ENTER ENTER ENTER 90 ÷ 1 + × 56 ÷ 1 + × 30 ÷ 1 + × 12 ÷ 1 + × 2 ÷ 1 + Kind regards Thomas 

« Next Oldest  Next Newest »

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