Some comments (was Please, I hope people do not complain...) Message #9 Posted by Vieira, Luiz C. (Brazil) on 10 Oct 2002, 12:56 a.m., in response to message #1 by Ernie Malaga
Hi;
for those who lost the first part of the thread (that is resting in the Archives), the title "Please, I hope people do not complain..." is because I made a reference to TI calculators in an HP-Only (far from being a restriction; just a matter of selected subject) Forum. So, I decided to continue the conversation by e-mails rather than by the Forum; that's the reason for the former apologies.
Some comments over these posts. I referred to RPN and AOS some months ago, in other thread, as, respectively, math solution procedures and math notation. I see the difference between both like this:
13 + 28 = 41 (math notation)
1 (carry)
13
+28
---
41 (solution procedure)
There are ways to get to a solution by using both, descriptive solution and math notation. It's far well known that math notation is not the best way to "describe the way to get to the solution". When we have to deal with a math expression and find its solution (numeric result), each of us will find our own way to solve it. Many will have the same procedure, others will have particular, shorter or longer versions. The math expression (notation) itself will not need to be changed anyway.
By exclusively analyzing one of the right solution procedures, maybe it's possible to restore the original math expression. In some cases, this task will be annoying, hard and time consuming, when inefficient; if we are lucky enough to grab the best explained, full of references solution, it's easier to reach the original math expression.
I think this is the "beauty" of RPN/RPL programming: having access to the inner thoughts of the programmer. I'm not going to comment direct, keystroke procedures to solve a general or particular problem, because they are based on usage principles not specifically related to the text I wrote here; my focus IS programming.
There is always a programmer's "signature" hidden in an RPN/RPL program. We can also identify this signature in an AOS program, because in many situations, simply typing in the keys that are equivalent to the math expression will not do the job. I do not mean that this is always this way, but sometimes it is easier to write a program based in AOS logic; it can also be hard because of the same reasons.
I owned and programmed AOS calculators (TI57, 58, 59), also BASIC-style Casio handheld (I remember I firstly tried C in one Casio handheld that amazed me at the time I was in the University; 1986?). Depending on the knowledge and understanding of the programmer, RPN/RPL allow him to create his own path, to fully use the stack registers to get to the results or simply use x- and y-registers contents, to explore all possibilities in order to reduce program steps (memory space), among other possibilities. The same is valid in an AOS-based calculator, and the fact that I do not know how to use them deeply enough does not mean they do not have their inner, surprisingly secrets. (A note: I know the stack registers will always be used in the moment a number is typed in, but many programmers barely use Z and T registers, meaning they did not have to OR didn't get too deep inside the calculator's resources)
Anyway, there are some "tricks" RPN allows the programmer to use that I do not know if AOS does. In 1988 I was asked by a topographer to develop a program to compute a triangle area given its three sides in an HP11C. He asked the program to be as small as possible, and he also wanted to understand what the h... was that stack. I wrote him the following program:
001- 42 21 11 LBL A
002 - 36 ENTER
003 - 43 33 R^
004 - 40 +
005 - 43 33 R^
006 - 43 36 LSTx
007 - 33 Rv
008 - 40 +
009 - 43 36 LSTx
010 - 33 Rv
011 - 33 Rv
012 - 20 ×
013 - 34 x<>y
014 - 43 33 R^
015 - 2 2
016 - 16 CHS
017 - 10 ÷
018 - 20 ×
019 - 43 36 LSTx
020 - 43 11 x^2
021 - 40 +
022 - 34 x<>y
023 - 10 ÷
024 - 11 SQRT
025 - 43 24 COS-1
026 - 2 2
027 - 20 ×
028 - 23 SIN
029 - 20 ×
030 - 2 2
031 - 10 ÷
Just enter the sides in X, Y and Z and run the program: the area of the triangle is the resulting data. I remember I fused two or three algebraic expressions in only one to get to the program. Some months ago (about 13 years later), when collecting my precious data, I found the program listing and tried to restore the original expressions. Who in Heaven wonder what did I do... I simply cannot figure out the original expressions. I depicted the program step by step and I found an 'I-never-saw-that-before' algebraic expression that does not even resemble any triangle-area computing procedure. And I know this is the way I've been programming since I saw one of the most beautiful use of RPN: Paul Baker's program to find the roots of a second-degree equation using FOCAL (HP41). I'd be proud of myself if I wrote it. I include its listing here.
01 LBL "SOL"
02 ST/ Z
03 /
04 -2
05 /
06 ENTER^
07 ENTER^
08 X^2
09 R^
10 CF 00
11 X>Y?
12 SF 00
13 -
14 ABS
15 SQRT
16 ST- Z
17 X<>Y
18 FC? 00
19 +
.END.
I depicted the program as deeply as I could, and sometimes it's easy to identify parts of the expressions for the two roots, sometimes mixing both real and complex parts. After this program, my programming style changed because I was always trying to find the shortest, fastest, more efficient program. And by doing this, the solution procedure always goes farther than the math notation.
I believe everything else I write from now on will be more based on my own thoughts (as if I didn't do it since the first words in here...) than in the subject itself. Many thoughts expressed in this thread are against my own preferences, but they are right. In more than one time the word "option" was used; after this, any particular preference is, indeed, a matter of preference. If any path leads to Rome, all of them are correct.
I know this does not exhaust the major theme, so I expect comments, suggestions...
Cheers.
|