[qv]<IDL>Manual>APPENDIXA.BRAVO!1

This appendix presents the basic material that a computer novice needs both to read this manual and to start to use IDL. It is of necessity fairly cryptic, as it could not be made much longer than it is without enlarging the already swollen manual beyond all reason. Its aim is to provide a brief introduction to some ideas that are necessary to understand and use IDL - it is not a complete treatment of any of them. Further information and a more gradually paced coverage of the material presented here may be found in the references cited in the sections below. If these also fail, talk to someone who has had experience with the system - most people who work with computers are happy to share their knowledge, and have often had the same problems themselves not long ago.

Computers do nothing of their own volition. Anything that a computer does, irrespective of whether it is "right" or "wrong" from the user’s point of view, is done under the control of some program - a completely specified sequence of operations. If this was all there was to it, computers wouldn’t be very useful, as programming the actual physical computer is both difficult and tedious, and few individual problems are worth that much effort. The reason that computers are so useful is that it is possible to write programs that solve a class of problems rather than just one. This frees the user from the task of defining the operations to solve his specific problem, and leaves him the simpler task of selecting a program whose problem class includes his problem, and specifying to it which problem it is to solve.

Programs vary widely in the range of problems that they will solve. Almost no program exists solely to solve one problem, as such a program would only be run once! Most programs allow the user to specify either different sequences of operations to be performed, or different data on which to perform them. In either case, the user must give instructions to the program. Because of the variation in the range of problems solved, different programs expect their instructions to be given in different ways. The user must always be aware of which program he is giving instructions to, and be careful to give it instructions of the form it expects.

The Harvard Radcliffe Student Time-sharing System (abbreviated HRSTS) is the computing system on which IDL is used. HRSTS is what is called an interactive system. This means that the user gives his commands via a typewriter-like device called a terminal, and gets the output from each command printed on the terminal before he gives his next command. This gives the user immediate feedback if he has made an error and so allows him to work effectively. However, it also makes it easy for him to become confused as to which program he is talking to and to give a command to the wrong program. Interactive programs try to avoid this by printing a distinctive identification (called a prompt) when they are waiting for information. Some programs, which know exactly what information they need, can describe it in detail. Thus, if you receive the message "ENTER LENGTH OF ELEPHANT’S TRUNK IN INCHES", it is (fairly) clear what the program expects you to say next. However, many programs are not able to decide what should come next (e.g. when the user has a lot of choice), and all they can do is to announce when they are listening, by printing a single character like *. As different programs tend to use different prompt symbols, such a prompt is generally also sufficient to tell the user which program produced it. The prompts of some commonly used HRSTS programs will be mentioned as they are discussed below.

Programs, in any modern computing system, are transient. This is because the resources that they use (core memory and the central processor) are in heavy demand. As soon as one program is finished with them, they are snapped up for use by another. When this happens (e.g. when the user runs another program, or logs out from the system) all memory of the results computed and everything else is lost. For many applications, that is fine - the user takes away all the results he needs on a piece of paper and is content. Often, however, particularly with big projects, the problem is not solved to completion in one session and the user must save the partial results, or the data they came from, so that he may return and continue later. The device by which this is done is the file. A file is an area of slow speed magnetic storage on which the user can record information that is to be preserved after his program exits. Each user has a certain amount of this storage set aside for him when his account is created. Typically, this storage is on a disc, and is permanent in the sense that the information recorded on it will stay there indefinitely until it is removed by the user. The exact methods for writing information onto a file vary from program to program and will not be discussed here. HRSTS, like all modern computing systems, provides the user with some programs for handling the files that he has created, examining their contents, deleting ones he no longer needs, and so on.

The first program the user interacts with once he signs onto HRSTS is called the Shell. (For details about getting an account, signing on, and living with your balky terminal, see the HRSTS Terminal User’s Guide (HRSTS,1974)). The prompt that identifies the Shell is the at-sign, @; whenever the system types a line consisting of nothing but an at-sign, the user is expected to give a command from the set of Shell commands, which are documented in HRSTS (1974). Shell commands are mainly concerned with providing facilities, like those the user needs to manage his files, which all users of HRSTS need. An example of such a command is FILES, which requests the system to type the list of files that the user has stored under his account. To give this command, the user must wait until he is prompted by an at-sign (otherwise the Shell is not listening). Then, the user types FI. The Shell is designed to recognise any command after its first two letters have been typed (to save the user typing), and to type out the rest of it (so the user can be sure that it is what he meant). Hence, the system types LES (completing the word FILES), and then waits for confirmation. If the FILES command was not what the user had in mind, he could cancel it by typing control-U (press the key labelled CTRL and hold it down while typing a U). Otherwise, he would type a carriage return (press the key labelled RETURN) and the system would carry out the command by typing the requested list of file names. In either case, the at-sign will appear again and the Shell is ready for another command.

Almost all Shell commands run other programs - in fact, the main function of the Shell is to act as a runner of other programs for the user. However, while such a program is running, the Shell hasn’t "gone away" as it does when you log out. It waits until the program that you have asked for is done, and then the Shell takes over again. For example, the command PPL runs the PPL interpreter, which will request input from the user (using a different prompt, of course). When PPL is later terminated, the Shell reappears and the user will be interacting with it again. The @ prompt will appear when this happens, notifying the user that Shell commands (such as FILES) will again be accepted.

A useful Shell command, and an exception to the above rule that Shell commands run other programs, is BYE, the command to end your terminal session and log you out from the system. Typing BY after the at-sign causes the system to type E, which completes the command, then (LOGOUT) (CONFIRM). The (CONFIRM) means that the system wants you to be sure you truly mean to logout from HRSTS, and didn’t just type BY by accident. If you do mean to logout, type a carriage return for confirmation; if not, cancel the BYE with a control-U as before. The BYE command must be given at the end of every session with the terminal.

IDL is a special purpose programming language for data analysis. It was formed by adding special tools that are useful for data analysis to an existing general purpose programming language - the Polymorphic Programming Language (PPL) of Taft and Standish (1974). However, nearly all of the facilities of PPL, and much of its logical structure, still survive in IDL, partly as a result of a conscious attempt to take advantage of the excellent manuals and courses (e.g. Nat. Sci. 110) on PPL available at Harvard. This section attempts to describe the basic ideas of PPL that are a part of IDL and which are critical to its understanding. The IDL user can make effective use of many more of PPL’s facilities than are described here, and is encouraged to become acquainted with them.

PPL is started from the Shell with the PPL command. The first two letters are, as usual, sufficient to precipitate command recognition and completion. PPL will begin by typing a couple of lines of messages, then will type its prompt, which is to tab the terminal’s type head 8 characters to the right. Once in PPL, the system enters what is called line mode. This means that, in contrast to the Shell where two characters are sufficient to specify a command, in PPL the user must type an entire line of characters and terminate it with a carriage return to signal that the line is complete. PPL will act on the line just typed in, and then prompt for a new one, until the PPL program is terminated.

PPL will take one of two different kinds of action on a line of input, depending on what it contains. PPL will either (1) evaluate and print the value of expressions written in the PPL language, or (2) accept new function definitions from the user. The definition of functions will not be further discussed here; it is a fairly advanced feature of PPL and is not required by the novice IDL user. Full descriptions can be found in Standish (1974) and Taft and Standish (1974).

Expressions that compute values are the most common type of input to PPL or IDL. The basic idea of an expression is that it is a description of some computation. Typically, that computation will have a value, and that value can either be the end result of the computation, or can be used as input to some larger computation. We will use arithmetic examples to give some flavour for how this works, but the idea is by no means specific to arithmetic.

3-1... describes the operation of
... subtracting one from three.
... Its value is two.
4*7+3... 4*7 means 4 times 7, + 3 is 31.
... Note that this is different from
... 4*(7+3), which is 4*10 or 40.
... Unless parentheses are present,
... multiplication and division are
... performed before addition and
... subtraction
4.2/7... we can also use fractional numbers
... this expression evaluates to 0.6 .fill

So far, we have been using arithmetic symbols, like +, that are similar to those that we are familiar with. However, there is a limit to how many of these can fit on a keyboard. Eventually, we have to break away from these operators and use names to describe individual operations. When we use names rather than special characters to denote operations, the operation is called a function. An example of a function is the operation that finds the square root of a number - written SQRT(x) where x is the number whose square root is to be found. All function calls look much like this. They consist of the function’s name (here, SQRT), followed by one or more ↑&arguments\& (here only one, the number x), separated by commas and enclosed in parentheses. One can mix function calls with operator expressions freely. For example, we have

We have been using three dots as a typographic device to set our comments off from the the examples above. As it happens, three dots also acts as a comment marker in PPL. PPL does nothing with the rest of a line after the first occurrence of three dots. Hence, our typographic device could also have been typed into PPL without ill effect!

Values, such as those computed by these sample expressions, can be used in two ways in PPL. First, they can be printed for you to see: this is what happens if you just type the expression (try the above examples). The second way to use values is to save them in variables so they can be used later. This use of the term variable is different from that common in statistics (where it is used to refer to one observation made on many different subjects). Here, we mean a place in which a value (of any type) may be saved. The user can form as many variables as he needs simply by specifying, for each variable, a distinct name (a sequence of letters and numbers, beginning with a letter) by which he will refer to it. A value is saved in the variable (or stored into it) with the assignment operation, symbolized <- (shift-O on most terminals). Thus,

Some functions do not produce values, but instead make changes to the environment. Such a function is the READ function that takes input from a file, or the WRITE function which puts output onto a file. The most useful of these is the SYS function, which terminates PPL and takes you back to the Shell. Once there, you can log out with the BYE command. Note that, when a function has no arguments at all, like SYS, one can write either SYS or the more formally correct SYS(), as one pleases.

Another useful function of this type is the PROTOCOL function. This function causes a complete copy of your dialogue with PPL to be saved in a file in your disk area. This can be very useful when working on a video terminal (one that prints not on paper but on a screen like a television screen). Such terminals provide you with no written record of what you have done during the session - the PROTOCOL command avoids you having to copy results off the screen by hand. To use it, type PROTOCOL at the point in your terminal session from which you wish a record kept. Everything that appears on your terminal from that point on until either you leave PPL or issue the UNPROTOCOL command will be saved in the file PPL.PROTOCOL in your disk area. At the end of the session you can print that file on the high speed printer to examine at your leisure.

@ PPL (CONFIRM) (ret)
UNIX PPL V0.5 17-OCT-74 FOR NEWS AS OF 3-NOV-74, PLEASE TYPE:
READ("LIB:NEWS")

RADIUS <- 6.3&... store the value of the radius
... in a suitably named variable
PI <- 3.14159... store the value of pi also
AREA <- PI*RADIUS 2
... Exponentiation, , is performed
... before multiplication or
... division. Thus, this means
... PI*(R 2) not (PI*R) 2.
AREA
124.69... PPL types the answer. Why? Because we
... told it to store the computed result in
... the variable AREA. Now, we type AREA on
... a line by itself. This is an expression
... so it is evaluated and its value is
... typed, as always.
SYS (ret)... now leaving PPL
@ BYE (LOGOUT) (CONFIRM) (ret)

There are also functions that take more than one argument. A familiar one is ADD(x,y), which takes two numeric arguments and computes their sum. So, ADD(8,4.73) is 12.73. Now you may be thinking "But to add those two numbers I could just type 8+4.73!" Quite right, but this is no more than a pretty way of saying ADD(8,4.73). In PPL, functions of one or two arguments can be associated with operators, like +, in such a way that, when the operator is written in an expression, the corresponding function is used. Operators that are associated with functions of one argument are called unary operators; those associated with two-argument functions binary operators. The one-argument function MINUS has the unary operator - associated with it, so that

So far, all our examples have involved values that were numeric. The notion of a value, however, applies equally well to information represented in quite different ways. Differences in representation are referred to in PPL as different datatypes. For example, character data, used by IDL for labeling, is of datatype STRING and consists of a sequence of characters placed one after the other. The user can type in a string value by enclosing the chosen character sequence in quotation marks (otherwise some strings might be confused with variable names). PPL (confusingly) types string values back without quotes. Try this:

GX<-"HI THERE!"... Assign the value "HI THERE!"
... to the variable GX, and then
GX... ask for it
HI THERE!... and get it without quotes

Our previous discussion of "numeric values" was incomplete. Numbers, like other data, can be represented in slightly different ways, each way suited for slightly different things. Numbers in PPL can be of three types, integer (called INT), real (REAL) or double-precision (DBL). Integers are the whole numbers ..., -1, 0, 1, 2, 3, ... and are written without a decimal point. REALs are the fractional numbers 1.5, 3.1415926, -6.0, etc., and are written with a decimal point. DBLs are like REALs but have more digits of significance (14 instead of 7). The average IDL user needs to know little more than their names.

At this stage, you should have enough conceptual background to read the manual and to understand the language and concepts being used. You should also have enough factual information to begin to use IDL on HRSTS. There is much more that you could profitably learn, that we did not mention here because of limitations of space. The references cited in this section contain much more information on these and other topics and, although little of it might appear to be relevant at first sight, we urge you to spend as much time as you can spare learning whatever you can from them. It is only in this way that you will lose the feeling of being on alien ground that often makes one’s initial contact with computers so much less rewarding than it can be.