ECS 158 Final Project (Homework/Final Exam) Instructions

DUE DATE:

December 11, 11:59 p.m. NO LATE SUBMISSIONS! (Near the deadline, keep submitting even though you are not done, so as to ensure that you have something submitted.)

I assign a Term Project at the end of every undergraduate class that I teach. In the programming-oriented courses, the goals are to give students a chance to learn to find and synthesize information, and write about it in a coherent, professional manner. (In ECS 132, the goal is to give students a chance to apply the course material in unstructured, "real life" settings, and again, to write about it effectively.)

Project description:

Your project title will be "Introduction to the Julia Language," with contents as implied by that title. Julia is a scripting language similar to Python/R. Here are the details:

Pitch the technological level of your report at programmers with good systems knowledge and background in parallel computation.

You'll need to download Julia from the home page, just the free core, of course. Support for Julia exists for the Vim, Emacs etc., and I've heard that the free IDE, Juno, is pretty nice.

Your report must include a section (L^AT_EX command \section) for each of the following topics:
- History and motivation for Julia -- why have yet another scripting language?
- General structure: What does it look like syntactically? Does it have any unusual language constructs?
- The inventors of the language claim that it is very fast, with speed approaching that of C/C++. How valid are the claims? Some people have charged that the Julia people are biasing their timing experiments in their favor.
- To whatever extent Julia is indeed fast, what makes it fast? And fast on what kinds of apps?
  
  This section is especially important.
- What kinds of parallel computation facilities does Julia have? How are they similar/dissimilar to the ones we've seen in OpenMP, MPI and R's parallel package? Note that here you will be addressing the nature of the operation of those facilities, NOT the syntax in which they are expressed.
- Code example: Recode in Julia almost any one of the examples in our textbook. It must be an example in C/C++. Before coding, get approval from me as to your choice of example.
  
  This must be a full code example, with some timing comparisons between Julia and the code in the book.
Be careful about the sources you use. The Web is an outstanding resource (I am not one to believe something is more accurate just because it in a book rather than on the Web), but much of the material on the Web is written by people who themselves have only a superficial understanding of what they are writing. And keep a healthy skepticism in terms of possible bias, as noted above.

The quality of your project will depend largely on how adventurous and curious you are. If you set out to write something really useful, then it will be so.

I will display the best project papers on our Web page. (Let me know if you object to this.)

Some general issues:

As you know, this Project counts both as a Homework assignment and as a substitute for an in-class Final Exam. All in all, it will require time similar to approximately 1.5 Homework assignments. START EARLY! A lot of things you think will be easy, postponable to the last minute, may prove to be much harder than you think. In every class I teach, there are one or two groups who don't finish, and again, note that there are no late submissions.

A typical good-quality report will run, say, 4-5 pages, excluding code listings, graphs and figures. But there is no magic formula; a really excellent report might be shorter than this, and a mediocre one might be much longer.

Please note the open-ended nature of the Project. As you can see, other than the required topic list above, these Project specs don't take the form of "Step 1, do this, Step 2, do that..."

Writeup:

You are required to use L^AT_EX to write up your report, with the output being a PDF file. I have a quick tutorial. Also, all the .tex files for our own ECS 158 textbook are in http://heather.cs.ucdavis.edu/~matloff/158/PLN ; by comparing output to input, you can see how to do lots of things in L^AT_EX .

Make sure that your graphs are in either .png, .jpg or .pdf format. You may find the following code useful:
```
# prints the currently displayed graph to the
# file filename; suffix can be "pdf", "png" or "jpg"
pr2file <- function (filename)
{
    origdev <- dev.cur()
    parts <- strsplit(filename,".",fixed=TRUE)
    nparts <- length(parts[[1]])
    suff <- parts[[1]][nparts]
    if (suff == "pdf") {
        pdf(filename)
    }
    else if (suff == "png") {
        png(filename)
    }
    else jpeg(filename)
    devnum <- dev.cur()
    dev.set(origdev)
    dev.copy(which = devnum)
    dev.set(devnum)
    dev.off()
    dev.set(origdev)
}
   
```
I recommend that you use R's ggplot2 package to generate your graphs; see my tutorial at the end of my ECS 132 book. In any case, all graphs and figures must be input by your .tex file, and appear within your report itself.

It is of the utmost importance that your report be of PROFESSIONAL QUALITY. This means:

Clarity! This is very difficult, but quite achievable if you work at it. Ask friends not in the class to read it and tell you if it makes sense. Keep in mind that if you do the writeup at the last minute, the biggest casualty will be clarity.

Correct spelling, grammar and usage!

Professional-quality presentation! It doesn't necessarily have to be fancy, but should not look sloppy.

Use any standard citation system for your references. And of course, do not cite without attribution.

To be avoided like the plague:
- Avoid vague use of the word "it." Example: "It is embarrassingly parallel"--exactly WHAT is embarrassingly parallel?
- "If you wouldn't eat it, don't serve it." This used to be a sign to employees in fast food restaurants, admonishing them not to serve sloppily cooked food. In our case here, "If you wouldn't find the premise of an analysis credible, don't present that analysis."
Your report MUST be named Project.pdf.

You must include an appendix (use the LaTeX \appendix command, with \section for each topic), with the following contents.
- Your code, clearly commented, using the L^AT_EX listings package. Also include in a text portion (i.e. NOT in your code) an explanation of the highlights of your code.
- Include a brief account of "who did what" in this Project among the various group members. Not everybody need have done exactly equal work, but something of the nature "Transported a USB key to campus" doesn't count as a contribution. :-) (A group actually said this in their report one time about the contribution of a certain member.)

Adhere to the UCD Code of Ethics. Having persons outside your team do any of the work, including the writing, or engaging in paid help of any kind, is unacceptable.

IMPORTANT SUBMISSION DETAILS:

Your group submits just ONE copy of the report.

Submit your report, including all files (.tex, .pdf, .c,.R etc.) to my handin site on CSIF, directory 158project (see Syllabus). The name of your file must be of the form email1.email2....tar, where each emaili is the UCD e-mail address of group member i, e.g. bclinton.gbush.bobama.tar. Note the periods separating fields. Your .tar file must contain only regular files, NO SUBDIRECTORIES. (Points automatically docked.)

Make sure that all partners' names are on the report, and that the e-mail addresses in the file name are EXACTLY the official UCD e-mail addresses for the students. These are the addresses at which you have been receiving your Quiz results. DON'T RISK HAVING A TEAM MEMBER FAILING TO GET CREDIT FOR THE PROJECT.

Grading criteria:

Technical content of the work.

Adherence to instructions.

Professional quality of the work.