Program submission

We will be writing applications, not applets, by using the standard Java language as defined by Sun. Submit all your source (.java) files and the byte code (.class) files. Your top class, which contains the main() method, must be called A#, where # is the assignment number. The other classes can have names of your choice. Use the submit program with user=cs582 and tag=482_#, (for cs482 students) or 582_# (for cs582 students). For example, the first assignment for cs482 should be submitted with:

Note that 'submit' will only work if you are logged into your account in a scf machine and your files are in a directory in your scf account. If you developed the code elsewhere, you need to ftp to a scf machine before submitting. Important Note: We will test your programs in a SUN using the versions of Java and Java 3D indicated in the Java Information web page in the course web site. These are the versions available in the USC SUNs in the user rooms. Newer versions have been released but they are not yet available here and there is no guarantee that code developed in a newer version will run in the older ones we will use for testing.

Documentation Submission

Assignments normally require that you submit a write-up containing pertinent analysis and a description of the high-level design of your program plus the program itself. The write-up should be sufficiently detailed for one to understand what data structures are used, and how the algorithms work without reading the actual code. To describe data structures we recommend that you use diagrams, and to describe algorithms and the flow of control we recommend pseudo-code. Both should be supplemented with prose when appropriate. Non-self explanatory aspects of the graphic user interface should be documented, with sketches if appropriate.

Priorities

In this course highest priority will be given to correctness and clarity. Other important characteristics such as efficiency, extensibility, portability, user "friendliness", etc., will be viewed as secondary. (This does not mean that "ridiculously inefficient" programming will be encouraged...)

Correctness has many facets; we'll emphasize geometric correctness. For example, we won't mind if a program crashes when the user makes a mistake and enters a real when a character is expected. Graceful recovery of such errors is very important in "real-world" interactive programs, but requires a substantial amount of programming effort. On the other hand, since this is a course on geometry, we'll expect no geometric errors. For example, a program to intersect lines must not crash and must do something sensible when the input lines are parallel. (There are many such unpleasant situations in computational geometry ... as you'll find out!)

Clarity is very important in programming. We'll read some of your code, and we expect it to be understandable! A program should begin with a description of what it does and how it does it. Similar remarks apply to each procedure. Use mnemonic variable and procedure names, use upper and lower case characters in your code, explain what variables mean, comment programs liberally. Comments will help us, but they'll help you as well. Do not forget to put your name in your files.

Grading

We'll grade the write-up and the program. For the latter we'll take into consideration execution (how well it handles our tests, some of which are nasty...), correctness, readability, efficiency, and a mix of ill-defined characteristics usually called "good programming practices". Grading will reflect the priorities discussed above.