ECS 158 Final Project (Homework/Final Exam) Instructions
Contents:
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.)
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 (LATEX 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.)
- 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..."
- You are required to use
LATEX
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 LATEX .
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
LATEX
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.
- 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.
- Technical content of the work.
- Adherence to instructions.
- Professional quality of the work.