The Museum of HP Calculators

HP Forum Archive 16

 Excerpts from my bookMessage #1 Posted by Tom Barber on 10 Sept 2006, 11:28 p.m. Now that I find myself in the position of wanting to offer a few excerpts from my book, I decided that it would not made sense to leave it under that other thread. ("Favorite short RPL program") At the same time, my other thought is whether it is appropriate at all to do this here. Even if the moderators have no problem with it, I don't feel entirely comfortable doing this here, so I will limit it to two or three posts under this thread, and unless others have questions, I'll try not to wear out my welcome. If it goes beyond the bounds of what is appropriate, I assume that the moderators will let me know, and at that point it will come to an abrupt conclusion. The first excerpt that I will give (I keep misspelling “excerpt” as “except”) is from the explanation of the effect of the CAS modes Numeric and Approx. Every one of the explanations of the actual effect of these modes that I was able to find in the various printed and PDF manuals provided by HP, were grossly incomplete and inadequate. They are all what I would characterize as allusions (I spelled that word correctly). I was never ever to escape the feeling that whoever wrote those explanations didn’t really understand the exact effect of those modes on the behavior of the calculator. And nowhere did I find any hint of the fact that they do not behave the same in RPN mode as they do in Algebraic mode. Not only do they behave differently in the two operating modes, the related behavior when neither of those modes is set, whereby the user is prompted to set the Approx mode, is different in the two operating modes. Try this on for size: “When neither Numeric nor Approx is selected, the calculator avoids carrying out operations that will introduce real numbers in the results. ... If there is a simpler way to represent the result of an operation without introducing any real numbers, then that simplification will often be performed. ... In Algebraic mode, if you try to perform a binary operation that combines a real number with a symbolic constant, or with the pending result of a unary operation that can’t be performed because to do so would introduce a real number, the calculator will prompt you to set the Approx mode. One effect of setting the Approx mode in either operating mode is that integers will be converted to real upon input, automatically. In Algebraic mode, Approx has the additional effect of causing all operations to be carried out, excepting only operations that involve undefined variables. In RPN mode, however, symbolic constants will not be replaced with real numbers unless Numeric is set, so if only Approx is set, operations that involve symbolic constants will still not be performed. In either operating mode, Numeric has the effect that Approx has in Algebraic mode, but undefined variables will cause an error in lieu of a result if Numeric is set, whereas if only Approx is set, undefined variable names will silently carry through to the result. … There are situations in RPN mode where the calculator will prompt you to set Approx, but these are mostly limited to when you use EVAL to evaluate an algebraic expression, or when an integrand expression combines integer and real. If you use EVAL to evaluate an algebraic expression in RPN mode, the effect of Approx will be the same as it is in Algebraic mode.” Whenever I write something of this sort, I take it for granted that I have overlooked something and that it is not 100% correct. Nevertheless, I am confident that this is substantially more complete than any of the laughably incomplete explanations that I was able to find in any of the manuals that come from HP. Tom

 Re: Excerpts from my bookMessage #2 Posted by Tom Barber on 10 Sept 2006, 11:58 p.m.,in response to message #1 by Tom Barber Here is how I explain how the recursive evaluation of the RPN command line works. " The command line itself is evaluated in like manner as a program, which is roughly as follows: ```PROCEDURE Evaluate Program: FOR each token occurring immediately within the program: IF the token is a name IF the name is quoted push the name onto the stack ELSE CALL PROCEDURE Evaluate Name ELSE IF the token is a command or operator perform the command or operation ELSE push the object onto the stack NEXT PROCEDURE Evaluate Name: IF the name is the name of a subdirectory make that directory the current directory ELSE IF the name is the name of a local variable push the content of the local variable onto the stack ELSE IF the name is the name of a global variable that contains a name CALL PROCEDURE Evaluate Name for the contained name ELSE IF the name is the name of a global variable that contains a program CALL PROCEDURE Evaluate Program for the contained program ELSE IF the name is the name of a defined global variable push the content of the global variable onto the stack ELSE push the undefined name onto the stack ``` The way that lists appearing in the command line are handled depends on the operating mode. In Algebraic mode, lists embedded in the command line are evaluated, and names or algebraic expressions appearing as elements of a list are handled in like manner as when they appear outside of a list, i.e., if they are not quoted, they will be evaluated. In RPN mode, lists are never evaluated automatically, and that of course means that except for when a list is forcibly evaluated, the elements of a list in RPN mode are protected from evaluation so long as the list itself is not forcibly evaluated. When a list is forcibly evaluated in RPN mode, algebraic expressions appearing as elements of the list will be pushed onto the stack intact, whereas names and programs appearing as elements of the list will be evaluated. Hence, when a list is forcibly evaluated in RPN mode, names and programs occurring as elements of the list will be evaluated in accordance with the procedural descriptions shown above. Whenever a list is forcibly evaluated in RPN mode, the evaluation occurs as follows: ```PROCEDURE Evaluate List: FOR each element of the list IF the element is a name CALL PROCEDURE Evaluate Name ELSE IF the element is a program CALL PROCEDURE Evaluate Program ELSE IF the element is a command name perform the command ELSE push the object onto the stack NEXT ``` "

 Re: Excerpts from my bookMessage #3 Posted by Tom Barber on 11 Sept 2006, 12:05 a.m.,in response to message #1 by Tom Barber Here is an excerpt from the RPL programming chapter, and the section that talks about using strings to encapsulate programs: "There are significant advantages to writing and maintaining your programs as strings, i.e., using strings to encapsulate your programs. Each time that the editor exits, the content is evaluated in the familiar manner of the command line interpreter. As programs are pushed onto the stack, subtle changes occur. The voluntary white space characters that have no effect in the program, which includes line breaks, are stripped. Moreover, even though the editor permits you to put comments in your program, it strips them out of the program as the program exits the editor. (Comments start with the ‘@’ character and continue until the next line break.) If you encapsulate your programs within strings, your indentation and comments will be preserved. When you use the type-aware editor (EDITB or VISITB) to edit the program-within-a-string, the backslashes that are needed to escape the double quote characters embedded in the program, are inserted for you automatically, and the double quotes that occur at the start and end of the entire string variable when the other editor (EDIT or VISIT) is used, are suppressed. You write the program just the same as you would ordinarily write the program, and if you put a comment right at the start of the program, you will always know whether you are looking at the program-within-a-string copy of the program, or the copy that is generated from it. As for converting the program-within-a-string to a regular program, you could of course open the string variable within the generic text editor and proceed to delete the quotes at the start and end of the string, and then perform a global substitution to get rid of the escape characters. But there is an easier way. When OBJ-> is applied to a string, the command line interpreter receives the proper content of the string, i.e., the string as it appears within the type-aware editor. As long as you have put the << >> program delimiters immediately inside the string, the interpreter will behave as though you had entered that program into the command line directly. If the proper content of the string is a syntactically correct program, it will be pushed onto the stack."

 Re: Excerpts from my bookMessage #4 Posted by Tom Barber on 11 Sept 2006, 12:12 a.m.,in response to message #1 by Tom Barber Here is a little tidbit from the chapter on the text editor: "[Style] opens a submenu where the keys will apply font attributes to the current selection and to any text that you type subsequently. The font attribute survives the editing session for strings only, but you can apply font attributes to strings embedded in programs for displaying to the user. The effect of pressing the key is to toggle between whether that attribute is active or inactive. If you select text and then press the key, the attribute will be activated and applied to the selection, and will be deactivated as soon as you move the cursor. If you press the key when no text is selected, the attribute will be applied to text that you enter until you press one of the cursor navigation keys. If you select text that has the attribute, with the intent to remove the attribute, you have to press the key twice in succession. If you assign the reverse font to the selection, it will be displayed normally, and it will be impossible to distinguish between the text in the selection and the text to which the reverse attribute has been applied. Putting the BEGIN and END marks at the same location will allow you to see where the reverse font attribute is applied."

 Re: Excerpts from my bookMessage #5 Posted by Tom Barber on 11 Sept 2006, 12:36 a.m.,in response to message #1 by Tom Barber I think this will be the last one. Here are a couple of excerpts from the chapter that deals with complex numbers and ordered pairs: "When you input an ordered pair in polar coordinates, in certain circumstances it will be converted immediately to a symbolic representation that involves trig functions. Except for when that occurs, or for when you use a Unit object to override the currently selected angle measure, the polar angle is interpreted in accordance with the angle measure in effect at the time the ordered pair is entered. Subsequent changes to the selected angle measure will change the numerical value that you see for the polar angle in the display (if polar coordinates are selected), and this reflects the fact that changing the selected angle measure does not change the ordered pair itself. If you use the C->R command to return the real and imaginary parts of the ordered pair to the stack, you always get the same pair of real numbers for the ordered pair that you entered, no matter which coordinate system and angle measure are in effect when the command is performed. The V-> command, however, returns the coordinates of the vector per the coordinate system and angle measure in effect when the command is performed. It is appropriate to think of this as an actual coordinate system conversion, and if it is done with polar coordinates selected and using an angle measure different from the angle measure used when the ordered pair was entered (in polar coordinates), angle measure conversion will be performed as well. Keep in mind, however, that the interpretation of the value that you give for the polar angle is sometimes deferred, and this introduces the possibility for the value that you give to be interpreted using the wrong angle measure later on. I’ll say more about this in a bit, of course. ... When entering ordered pairs, depending on the operating mode, the coordinate system, and whether you use quotes, the coordinates may be restricted to integers or real numbers. Except for the cases where conversion to symbolic form occurs, integers are converted to real. Note also that if Approx is set, integers are converted to real regardless, and when using quotes in RPN mode, this will influence whether the conversion to symbolic form will occur. When entering ordered pairs in Algebraic mode, if you use polar coordinates, the coordinates are restricted, and if you use rectangular coordinates, then unless both coordinates are real numbers, the ordered pair will be converted to the equivalent complex number in symbolic form. When entering ordered pairs in RPN mode, the coordinates are restricted unless you use quotes, and if you use quotes, then unless both coordinates are real numbers, the ordered pair will be converted to the alternate symbolic form. The alternate symbolic form for an ordered pair entered in polar coordinates is: ‘r*cos(pa) + r*sin(pa)*i’ and in this case, unless you use a Unit object for the polar angle, interpretation of the angle value is pending. " Note that pa in the symbolic expression above represents the polar angle, and I used that here because the characters for the Greek letters aren't supported, or if they are, I don't know how to access them. In any case, in the book, the customary Greek letter is used of course.

 Re: Excerpts from my bookMessage #6 Posted by Namir on 11 Sept 2006, 10:26 a.m.,in response to message #1 by Tom Barber Hi Tom, I ordered a copy of your book through your eBay auction. I look forward to receving it and learning from it. I hope you are open for feedback to improve on it for the netc edition. Regards, Namir

Go back to the main exhibit hall