Prototypes for some of the main projects

The code on this site is obviously available to anyone who chooses to download it. It is however copyright by its author, Walter F. Taylor. It is not guaranteed in any way, either as to its suitability for any use, or as to any performance standard. The programs are in easily-inspected ASCII code. The C-code is quite transparent, and it is easily seen that the programs take no action besides writing to standard-output. Therefore, any modestly trained person can see that they are virus-free. However, making that determination is ultimately up to you. In fact, as far as I know, there is no way that this material could directly harm anything, but nevertheless, you use it at your own risk.

It is not terribly appropriate, in this course, for me to waste a lot of our time teaching such peripheral issues as syntax for input/output, file access, clock and calendar access, and so on. (In some courses, these might be the main point, but not here.) Therefore I am making available various shell programs that will give you a prototype for how to set these things up.

These shells are like shells on the beach: they have the outer form, but the true life of the creature (the mathematics) is absent. You can run the programs, but you will get results that are obviously either false or incomplete. Your main job, of course, is to supply programming that carries out the mathematics that we are learning.

Please do not take a completely passive approach to these shells. They can help you with the syntax, and they can show you what is possible. But if you don't make them your own (or at least the parts of them that you like) they won't help you much, and may even hinder you! Know what is going on with them. By the same token, I am not giving out shells targeted to each specific project; rather I ask you to adapt what is here; it is plenty to work with.

In addition to shells, there is one sample program (in three versions: simple_curve.c, curve.c and curve.p) that is given to you completely. This is the program for a sin-curve that is also given completely on pages 83-84 of the book.

The shells (especially routines.c below) also contain some decorative features (coordinate axis, picture frames, clip region to make the picture clean, and so on), which are really quite decorative. Use of these decorative features is completely optional. Use them or adapt them as you like, but don't waste a lot of time on such stuff.

There also are some files besides shell programs, such as data sets, header files (xxxx.h) and an auxiliary file routines.c.

The curve-drawing program on pages 83-84

Simple_curve.c is almost word for word the same as the code that is written on pages 83-84. (It has however been modified in various obvious ways to make it into a fully function C program.) Ultimately, it is your choice whether to continue in this very simple way or to adopt the more complex approach of curve.c below. However, I will say this: anything is fine if you get it right the first time! But when errors creep into a complex program, modularity of programming is very important. Here modularity means that a program is built from small chunks that can be individually tested and relied upon.

By the way, I may offer suggestions, but I don't grade programming as such. (In fact I rarely read entire programs written by others. It is a monumental chore, even if well documented.) I believe that your own efforts at debugging and perfecting your work will give you plenty of feedback, some of it very undeniable.

intcurve.c This is much like simple_curve.c, but it outputs only integers. How, you ask, could this work? The secret is to make the window coordinates very big. Why, you ask, would one want this? We really have no need for it. But if you want to use the currently existing version of to_pc.c, then you have to have your entire .di file in integers (no floating-point numbers). Only the truly curious will want to waste time on this one.

curve.p This is more or less the same as simple_curve.c, only in pascal. I don't know very much about it. I think it works.

curve.c This is a much more elaborate program to generate the curve described on pages 83-87. Mathematically, it does not accomplish any more that simple_curve.c, but it is nevertheless enhanced in two ways:

1. There is a more elaborate programming style:
- The full program is actually lodged in three different files, curve.c (above), routines.c (below) and coords.h (below). The idea is that the latter two files contain material that would be used for many projects, and hence would be changed less often, whereas curve.c will be modified completely for each new project. This is only an ideal; you can of course change whatever you want.
- There is a defined data-type for "point," the definition of this data type is in coords.h.
- We are able to separate the definition of the function to be graphed (in this case the sine function) from the loop that computes many function-values. In fact the sine function, here called "f," is lodged in curve.c, and the loop, called "print_path()," is lodged in routines.c. The link between them is the call to print_path() in the main() of curve.c. The cool thing is that the loop is written for you, once and for all! In some of the projects, you will want to draw a sequence of curves. This is easily coded simply by writing a sequence of print_path statements.
2. Some features have been added:
- Such enhancements as axes, a frame, labels, etc.
- In routines.c, we use two coordinate systems. There is an output coordinate system, in inches, and a second coordinate system, for internal use only, that shows x and y values along the curve. The routines move_to() (etc.) give the external coord sys. The routines pic_move_to() (etc.) give the internal one. (The coordinate change occurs in the definition of pic_to_inches().) These are all lodged in routines.c.
- I included automatic date-stamp and user-name. If you need to delete these, you can easily locate them. It is sometimes handy to know that you are picking up your own work from the printer, and to know which is your most recent picture.

coords.h Called a header file. These typically contain defined data types, etc. This file must be in the same directory when you compile curve.c in unix. In curve.c and routines.c you will see #include lines asking for the inclusion of coords.h. (Header files are handled a little differently in Borland.) The header file that I am giving you here already contains various other types that might be useful in the future, such as for matrices and so on.

routines.c Subroutines used by curve.c, and available for future use in other curve-building programs. If you plan to use these, it is best to study them and make them your own. In unix, your first compile might look like

	         cc curve.c routines.c -lm

(Here -lm invokes the so-called math library. It tells the computer to find the definitions of such things as, in this case, the sine function.) If things go well, you will then have routines.o in your directory. After that, if you modifiy only curve.c, you can recompile with

	         cc curve.c routines.o -lm

thereby saving the need to recompile routines.c.

The raster-drawing program on pages 128-130

It is certainly implied in the book, but I will say it here explicitly. This program for rasterized (sampled, pixeled) images is completely separate from the device-independent languages, and separate from to_ps and to_pdf. It has no use for them, so don't try! Just use it on its own. Here it is. For an ansi-compliant version that can be used as C++, see this. There is also a dithered example.

New 12/17/99 Here is a program for making sampled PostScript images with 256 gray values (eight bits). This appears to be the maximum allowed in PostScript. To use it, you need a double intensity function g(x,y); then proceed as before, skipping any random dithering. (PS supplies some non-random dithering instead -- see footnote on page 134.) If you have a working picture that uses random dithering, you should be able to switch to this method almost instantly.

You probably will like the 8-bit results better than with random dithering, although you definitely will see irritating boundaries between the 256 discrete gray values. (To really get away from these while not totally exploding the file size, one probably needs to go to some compressed and digitally-filtered image formats such as .gif or .jpg.) One possible additional drawback is that sampling with eight bits creates a file almost eight times as big as when one samples a single bit (pure black or pure white).

Actually the code for the 8-bit sampled image is simpler than the code for the 2-bit (B&W) sampled image. The innermost loop of the latter code, which packs eight bits into one byte, is (obviously) not needed if each sample has eight bits in the first place. Otherwise, the code is almost the same. (The begin_bitmap() subroutine does need to mention the 8.)

Working with Matrices

In C (not to mention C++), there are two ways of working with matrices, and never the twain shall meet. In the past, students have worked successfully with either of these two approaches:

1. In matrix.c an m x n matrix is treated as an m x n array of floating-point numbers. The advantage here is that the dimensions m and n can be decided later, and that programming code can be very compact and transparent. (E.g., one tiny loop multiplies two matrices; try it and see.) The disadvantage is that subroutines (e.g. to multiply two matrices) must be called by passing the arrays' addresses, since arrays do not have values as such. In this situation, a small coding error can lead to large errors that are hard to track down. In any case, this file matrix.c may be useful to you as a template for the reduction of matrices. The file matrix.p is similar, but in pascal.
2. In coords.h you will find a number of definitions of specific low-dimensional vectors and matrices. Some useful subroutines (multiplications, and related calculations) are included in the fragmentary C-code matrix_routines.c. Although coding with these types is a little more cumbersome, the resulting code is easy to read, and subroutines are benign, because they are passed only values. They also interact well with the definition of (two- or three-dimensional) points as data types defined in coords.h. In my solutions of the major projects, I have habitually defined all the matrices of Chapters 4 and 5 as structs of these types.

However you choose to work with matrices, you will sooner or later need fully debugged routines for matrix calculations (at least for the product of two matrices).

For Chapter 3

bezier.c -- A shell for writing B-splines and interpolating curves. This corresponds to the third arrow on page 180. It is also described in words on pages 180-181. It is also called for in Exercise 1 on page 181. Moreover it is the main tool for working the project known as the Bezier group. As you will soon see, this shell is a really pathetic imitation of the real thing. (I have laid out a framework that sorts the cases for you, but I have not included any of the necessary mathematical calculations from section 3.2.) Here is some graphpaper for your Bezier project, if you think it would be useful.

For Chapter 6

flatworld.c - A shell for the projection of the globe (Section 6.1). It is a working version of the C-code that is described on page 320. It inputs the database, does almost none of the calculations, and then outputs latitude and longitude as if they were rectangular coordinates. Away from the poles, its output looks more or less like real geography -- to see this, try Exercise 7 on page 321.

continents.dat -- the data file needed for the globe-projection project. It is described in Section 6.1.1, pages 317-318. It is a little coarse but it sufficed for making the picture on page 317. I have heard that finer databases exist. If anybody knows how to find one, let me know. You of course are going to need rotations, etc., as outlined in pages 323-333.

starshell.c - A shell for the making of star charts (Section 6.2). It is a working version of the C-code that is described on page 344-346. It inputs the database and does a simple analysis of each field. The display() subroutine outputs that information as text, just so you can see that it is getting the right information. What is wanted for display() is obviously something very different: we want .di output that shows where to put little dots representing stars. (This is where case 'd' of to_ps.c becomes useful. I have not yet written 'd' into to_pdf.) It would also be nice to have each star's name placed near its icon. And again, rotations and such will be used here, as you know.

stars.dat -- the data for stars. This is the brief version of the famous Yale Star Catalog. Copyright Yale University. Used by permission for educational purposes. Its form and meaning are described on pages 342-343.

star_colors -- Here is something I took off an astronomy newsgroup ten years ago. Someone has correlated star types with RGB-values, in case you want to make a colored picture of the stars. It is probably not useful coding as it stands, but it contains all the necessary information. The information is to be taken with a grain of salt, for three reasons:

Each type represents a family of similar stars, but no two stars have exactly the same radiation spectrum.
In any case, three parameters (red, green, blue) cannot adequately represent a radiation spectrum. What is claimed about the RGB-values here is that they will give a picture that is about right to the human eye.
I am unable really to say anything about the quality of its source. However, the resulting pictures look pretty good to me. (I made one once.)