[18335fall08] some info on the final project paper

Steven G. Johnson stevenj.mit at gmail.com
Mon Nov 17 19:58:24 EST 2008


Hi gang,

As I said in class, the final project is due on the last day of class  
(Wed., Dec. 10), which officially is the last date that I am allowed  
to have assignments due.  I wanted to give you a few more tips on what  
I'm expecting your end result to look like.

In terms of results, I'm not expecting anything publication-worthy ---  
small scale tests of known algorithms on known problems is fine.  But  
it should still be clear and convincing.  e.g. if you are trying to  
demonstrate some trend, you should have enough data points and a well- 
thought-out numerical experiment for that purpose, clearly presented.

It's fine to use "canned" software like NLopt, LAPACK, etcetera,  
implementing the existing algorithms.  However, if your paper is about  
some algorithm X, or it is about a variety of algorithms for some  
purpose and you find X to be the best, then I do expect you to write  
at least a proof-of-concept implementation (e.g. in Matlab) of  
algorithm X in order to show that you understand the algorithm well  
enough to implement it yourself.   Your implementation does not have  
to be competitive in terms of performance or robustness with  
production-quality off-the-shelf software, however.

In terms of the paper, I expect it to be structured like a research  
paper, aimed at the level of your peers in the class.  It should include

1) introduction - motivate your project, explaining the basic problem  
your method address and where this problem arises.  give some  
background and history, both of the problem in general and the  
specific method(s) you are looking at, citing the relevant papers in  
the literature.  give an overview of what you did in the project and  
of the remainder of the paper

2) methods - describe the algorithms that you are looking at, and the  
implementation that you used.  (Possibly including pseudocode,  
although not pages of pseudocode, but no actual programming code  
should go here.)  If you compared several off-the-shelf algorithms,  
you don't need to explain all of them in great detail; it is okay to  
focus on one or two and given a brief overview of the others you  
compared.

You should have some explanation of *why* the method works, not just  
how. Depending on how theoretical your focus is, this may include  
proofs, or it may just consist of simple heuristic explanations.   
Diagrams are helpful and encouraged!

3) results - convincingly presented graphs and discussion of any  
numerical experiments you did.  In general, I expect you to look at  
both performance and accuracy (floating-point and/or other  
approximations) of your algorithm.  Ideally, you should also compare  
to at least one competing approach for the same problem.  Obviously,  
the precise nature of the problem you look at will determine precisely  
what numerical experiments you perform.  For example, if you have an  
approximate method, you might look at the performance as a function of  
the required accuracy in the solution.

Note also that the best way to measure performance might not be timing  
measurements (e.g. if you compare C code for one algorithm to Matlab  
code for another algorithm, timing comparisons might be very  
misleading because they are mainly comparing C vs. Matlab and not  
algorithm 1 vs. algorithm 2).  For example, if you are looking at  
different optimization algorithms, counting the number of times the  
objective function is evaluated to obtain the solution to within a  
given accuracy might be more appropriate.   Or if you are comparing  
ODE integrators for y' = F(y), you might compare the number of times  
F(y) is evaluated for a given level of accuracy.

4) discussion of results - explain features you observed.  For  
example, if you looked at roundoff errors, a theoretical analysis of  
roundoff and conditioning in your algorithm might be appropriate.

5) conclusion - a summary of your findings.  ("This algorithm sucks  
for this problem" is an okay finding, as long as you have convincingly  
demonstrated that the problem is intrinsic to the algorithm and not  
merely a flaw or bug in your implementation of it.)

As mentioned on the course web page, I expect the formatting of the  
paper to resemble a paper in the SIAM Journal on Numerical Analysis.   
(You can find templates on http://www.siam.org/journals/auth- 
info.php ... also, you can just look at some random papers in that  
journal to see what they look like.)  I don't care about every tiny  
detail, as long as it is basically similar.  Do *not* use preprint  
format (preprints are normally double spaced); use the single-spaced  
format like the published journal papers.

The paper should be 5-10 pages long, including figures.  This does not  
include source code; you should attach a printout of any code you  
wrote as an appendix.  (Do *not* print out source code you downloaded  
from elsewhere, unless you substantially modified it.  I don't want  
printouts of all of LAPACK, for example!)

--SGJ



More information about the 18335fall08 mailing list