Commit 94c4b331 authored by David Eyers's avatar David Eyers

initial import of MD5 (otagothesis.tar.gz) = ac9e6d82a6cc5059324cd61b3d0bda78

parents
#
# Makefile for use with a latex document that has a bibliography.
#
# To use: Create a directory to hold the source files and copy this file
# into it with the name "Makefile".
# Set the TITLE, CHAPTERS, and OSTYPE variables.
#
# typing "make" will make and view a .pdf file.
#
# Other Options:
#
# make clean: remove all auxiliary and temp files.
#
# make nuke: same as clean but remove main pdf file as well.
#
# make touch: force recompilation
#
# make backup: rsync the directory onto another machine
#
TITLE = thesis
# Put the names of your separate chapter files here
CHAPTERS = intro.tex literature.tex new_ideas.tex implementation.tex results.tex conclusion.tex abstract.tex acknowledgements.tex appendices.tex
# Uncommenting the following line will convert xfig files to pdf using fig2dev.
# FIGFILES = ex1.fig ex2.fig
# Machine you wish to backup your files on. We assume it is running
# rsync and ssh, so format should be username@host.domain
BKP = rountree@xev.otago.ac.nz
# Sometimes you want to view your document after every compile, sometimes not.
# Set the following variable appropriately.
AUTOVIEW = yes
#AUTOVIEW = no
#
# ALTER THE FOLLOWING AT YOUR OWN RISK
#
OSTYPE = $(shell uname)
TEXFILE = $(TITLE).tex
PDFFILE = $(TITLE).pdf
BIBFILE = $(TITLE).bib
PDFFIGS = $(FIGFILES:.fig=.pdf)
VIEWCMD = gv
ifeq (Linux,$(OSTYPE))
VIEWCMD = gv
endif
ifeq (Darwin,$(OSTYPE))
VIEWCMD = open -a preview
endif
ifeq (no,$(AUTOVIEW))
VIEWCMD = echo finished
endif
THISDIR = $(shell basename $(PWD))
pdf : $(PDFFILE)
$(VIEWCMD) $<
$(PDFFILE) : $(TEXFILE) $(CHAPTERS) $(BIBFILE) $(PDFFIGS)
pdflatex $<
bibtex $(TITLE)
pdflatex $<
pdflatex $<
%.pdf: %.fig
fig2dev -L pdf $< > $@
.PHONY : clean nuke backup touch
clean :
rm -rf *~ *.log *.lof *.aux *.lot *.bbl *.blg *.toc \#*
touch : clean
touch $(TEXFILE) $(CHAPTERS) $(BIBFILE)
backup : clean
cd ..; rsync -v -v -az -e ssh $(THISDIR) $(BKP):
nuke : clean
rm -rf $(PDFFILE) $(PDFFIGS)
What you will find here:
The otagothesis package for Otago University Departments that use Harvard-style
citations, by Nathan Rountree <rountree@cs.otago.ac.nz>
The distribution includes a Makefile to save all the typing you usually
have to do to compile a LaTeX document.
If you want to take a look at the thesis template immediately:
type "make".
To check out the example thesis (which shows you how to do bibliographic
references and suchlike), change to the example_document directory
and type "make".
There is one critical file in the distribution:
otagothesis.sty
There are others which will make like easier if they are part of your
Latex distribution:
natbib.sty
plainnat.bst
moreverb.sty
graphicx.sty
It is a good idea to have a $HOME/tex directory in which you put the
otagothesis.sty file. To do this:
Create a directory "$HOME/tex" or similar.
Put the otagothesis.sty file in it.
Set the following environment variables in .cshrc or .bash_profile:
TEXINPUTS=:$HOME/tex
BSTINPUTS=:$HOME/tex (useful if you ever use something other than
plainnat.bst to format your bibliographies.)
The leading colon (":") ensures that the system path already associated
with TEXINPUTS doesn't get lost.
In the example_document directory you will find a long-ish document
which shows you how to include bibliographic references, figures and tables
properly. It also shows you some easy ways of doing code-listings and
code-dumps for appendices.
The otagothesis package is known to work under linux and MacOsX, under the
TeTeX distribution.
Put the abstract in this file
\ No newline at end of file
Put the acknowledgements in this file
\ No newline at end of file
%%
%% Now we have to get the source code in as a set of Appendices.
%% Source code will be Appendix A, with each file numbered X.y
%%
\appendix
%%
%% -> \chapter will cause the next bit to be labelled Appendix A
%% -> \section will give us A.1, \subsection A.1.1 etc.
%%
%% I suggest a section for each program and a subsection for each file
%% in the program. Alternatively, a chapter for each program, a
%% section for each library and a subsection for each file.
%%
\chapter{Source Code for thesis.dvi}
\linespread{1}
\footnotesize
\section{thesis.tex}
\listinginput[10]{1}{thesis.tex}
\subsection{abstract.tex}
\listinginput[10]{1}{abstract.tex}
\subsection{acknowledgements.tex}
\listinginput[10]{1}{acknowledgements.tex}
\subsection{intro.tex}
\listinginput[10]{1}{intro.tex}
\subsection{literature.tex}
\listinginput[10]{1}{literature.tex}
\subsection{new\_ideas.tex}
\listinginput[10]{1}{new_ideas.tex}
\subsection{implementation.tex}
\listinginput[10]{1}{implementation.tex}
\subsection{results.tex}
\listinginput[10]{1}{results.tex}
\subsection{conclusion.tex}
\listinginput[10]{1}{conclusion.tex}
\subsection{appendices.tex}
\listinginput[10]{1}{appendices.tex}
%%
%% \listinginput[x]{y}{filename} gives a listing of <filename>,
%% starting at line y with a line-number at every xth line.
%%
\chapter{Conclusion}
\label{chap:conclusion}
#
# Makefile for use with a latex document that has a bibliography.
#
# To use: Create a directory to hold the source files and copy this file
# into it with the name "Makefile".
# Set the TITLE, CHAPTERS, and OSTYPE variables.
#
# typing "make" will make and view a .pdf file.
#
# Other Options:
#
# make clean: remove all auxiliary and temp files.
#
# make nuke: same as clean but remove main pdf file as well.
#
# make touch: force recompilation
#
# make backup: rsync the directory onto another machine
#
TITLE = thesis
# Put the names of your separate chapter files here
CHAPTERS = intro.tex literature.tex new_ideas.tex implementation.tex results.tex conclusion.tex abstract.tex acknowledgements.tex appendices.tex
# Uncommenting the following line will convert xfig files to pdf using fig2dev.
# FIGFILES = ex1.fig ex2.fig
# Machine you wish to backup your files on. We assume it is running
# rsync and ssh, so format should be username@host.domain
BKP = rountree@xev.otago.ac.nz
# Sometimes you want to view your document after every compile, sometimes not.
# Set the following variable appropriately.
AUTOVIEW = yes
#AUTOVIEW = no
#
# ALTER THE FOLLOWING AT YOUR OWN RISK
#
OSTYPE = $(shell uname)
TEXFILE = $(TITLE).tex
PDFFILE = $(TITLE).pdf
BIBFILE = $(TITLE).bib
PDFFIGS = $(FIGFILES:.fig=.pdf)
VIEWCMD = gv
ifeq (Linux,$(OSTYPE))
VIEWCMD = gv
endif
ifeq (Darwin,$(OSTYPE))
VIEWCMD = open -a preview
endif
ifeq (no,$(AUTOVIEW))
VIEWCMD = echo finished
endif
THISDIR = $(shell basename $(PWD))
pdf : $(PDFFILE)
$(VIEWCMD) $<
$(PDFFILE) : $(TEXFILE) $(CHAPTERS) $(BIBFILE) $(PDFFIGS)
pdflatex $<
bibtex $(TITLE)
pdflatex $<
pdflatex $<
%.pdf: %.fig
fig2dev -L pdf $< > $@
.PHONY : clean nuke backup touch
clean :
rm -rf *~ *.log *.lof *.aux *.lot *.bbl *.blg *.toc \#*
touch : clean
touch $(TEXFILE) $(CHAPTERS) $(BIBFILE)
backup : clean
cd ..; rsync -v -v -az -e ssh $(THISDIR) $(BKP):
nuke : clean
rm -rf $(PDFFILE) $(PDFFIGS)
An abstract should be somewhere between 50 and
200 words long---the
absolute maximum at Otago is 500 words, but that is almost certainly
too long. Remember, you will probably get at least one article out of
your thesis and it would be nice to be able to recycle the abstract
without having to snip it.
All you need to do in the abstract is give a statement of the problem,
a {\em brief} explanation of the method and procedures used, and a
summary of conclusions. You do {\bf not} have to give away your
conclusions entirely; save that for the concluding chapter. Bear in
mind that the abstract is all that most people will bother to read, so
it had better be good!
This is the {\em acknowledgements} environment, defined in
{\tt otagothesis.sty}. If you have any preface material, this is where to
put it.
I would like to thank the following people:
\begin{itemize}
\item The Department of Computer Science, for employing me over the
Summer break in 1997/8;
\item My colleagues in the Database Lab, who {\em still} haven't
complained about the mess;
\item Janet, who puts up with me.
\end{itemize}
Thank you all.
%%
%% Now we have to get the source code in as a set of Appendices.
%% Source code will be Appendix A, with each file numbered X.y
%%
\appendix
%%
%% -> \chapter will cause the next bit to be labelled Appendix A
%% -> \section will give us A.1, \subsection A.1.1 etc.
%%
%% I suggest a section for each program and a subsection for each file
%% in the program. Alternatively, a chapter for each program, a
%% section for each library and a subsection for each file.
%%
\chapter{Source Code for thesis.dvi}
\linespread{1}
\footnotesize
\section{thesis.tex}
\listinginput[10]{1}{thesis.tex}
\subsection{abstract.tex}
\listinginput[10]{1}{abstract.tex}
\subsection{acknowledgements.tex}
\listinginput[10]{1}{acknowledgements.tex}
\subsection{intro.tex}
\listinginput[10]{1}{intro.tex}
\subsection{literature.tex}
\listinginput[10]{1}{literature.tex}
\subsection{new\_ideas.tex}
\listinginput[10]{1}{new_ideas.tex}
\subsection{implementation.tex}
\listinginput[10]{1}{implementation.tex}
\subsection{results.tex}
\listinginput[10]{1}{results.tex}
\subsection{conclusion.tex}
\listinginput[10]{1}{conclusion.tex}
\subsection{appendices.tex}
\listinginput[10]{1}{appendices.tex}
%%
%% \listinginput[x]{y}{filename} gives a listing of <filename>,
%% starting at line y with a line-number at every xth line.
%%
\chapter{Conclusion}
\label{chap:final}
Here are some final comments about putting together a thesis. They
are mostly opinion (and certainly opinionated) so take on board what
you will. This is free advice after all (and may be worth as much)
but it is meant to make life easier for you.
\section{10 Things You Need to Believe \ldots}
\subsection{Use Sections}
Chapters are BIG things. Write an opening paragraph to your chapter,
then mark in each section you are going to cover. Fill in the actual
content AFTER you have worked out just what the sections are going to
be.
\subsection{Do your Literature Review First}
Lots of people do their literature review after they have written
their program/done their experiment. Don't fall into this trap---you
think the write-up will only take six weeks, but it won't, because
the lit.\ review will take four. Create a BibTeX file while you do
the review, so you can cite as you go. You would be amazed at how
many people don't do this.
\subsection{Do Not Write a Diary}
Nobody is interested in how you went about writing your program. The
academic community is interested in how you have integrated the
existing theory with your own ideas, and the department is interested
in why you made particular design decisions. Remember that we are a
Humanities department as well as a Science department, so we want to
see some sort of convincing argument for your ideas.
\subsection{Avoid Visual Formatting}
Try not to use commands like \verb|\vspace, \pagebreak| or
\verb|\enlargethispage|. The whole point of \LaTeX\ is that it
provides a markup language that works perfectly 90\% of the time.
This means that when you have {\bf finished}, the last thing you
should do is print up a draft, then go through and mark any formatting
you don't like (there will probably be about one thing every ten
pages). That is the time to insert things like \verb|\pagebreak|
commands.
\subsection{Learn \LaTeX\ Early}
The learning curve for \LaTeX\ is steep but short. The idea is that
some poor sod like me does all the dirty work, and all you have to do
is {\em fill in the content}. However you may spend about a week
learning all the fiddly bits (like tables and figures), and you don't
want to be taking time away from the actual thesis writing.
\subsection{Read Some Documentation}
In the Systems Lab, we are going to make every attempt to have
printed documentation lying around. If you need quick help, check out
the file {\tt essential.dvi} on any Linux \LaTeX\ installation. It
is probably the best short guide to \LaTeX\ around, and even contains
lots of tricky maths examples.
\subsection{Save Paper}
On a mac, use the layout options to print two-up and double-sided. On a
linux machine, use {\tt psutils} to print your drafts. This way you
use a quarter of the paper. Here's what to do if you don't have
a duplex printer:
\begin{enumerate}
\item Use the twosided option and make the PDF file.
\item Use \verb|pdftops| to convert \verb|thesis.pdf| to \verb|thesis.ps|.
\item Use {\tt psbook} to arrange the pages for booklet printing;
\begin{quote}
e.g. {\tt psbook thesis.ps thesis.bk.ps}.
\end{quote}
\item Use {\tt psnup} to get the book to a booklet;
\begin{quote}
e.g. {\tt psnup -2 thesis.bk.ps thesis.2up.bk.ps}.
\end{quote}
\item Use {\tt psselect} to print up the even pages first (in reverse),
then the odd pages;
\begin{quote}
e.g.\\
type {\tt psselect -e -r thesis.2up.bk.ps | lpr}\\
Put the result into the sheet feeder, blank side up\\
type {\tt psselect -o thesis.2up.bk.ps | lpr}\\
\end{quote}
\end{enumerate}
That's the theory; in practice it goes something like this:
\begin{quote}
{\tt psbook thesis.ps | psnup -2 | psselect -e -r | lpr}\\
Now open the laserjet side-door and put the paper which came out after
the first command on the tray. Don't change its orientation or
anything: just pick it up, move it to the tray and drop it. Then:\\
{\tt psbook thesis.ps | psnup -2 | psselect -o | lpr}\\
\end{quote}
\subsection{Use \LaTeX, not Word}
Microsoft Word is not your friend. Word is not {\em anybody's} friend.
It is possible to write large documents in Word, but you have to be
{\bf so} strict on yourself (using heading styles, TOC entries, etc.)
that you may as well have used \LaTeX\ in the end anyway. Once a
problem is nailed in \LaTeX, it stays nailed. The same is not true of
Word. Pdflatex produces standard PDF which can be
printed anywhere, and is fast becoming a standard for on-line article
publication. Ask anyone how many problems they have had printing Word
documents to PostScript printers.
\subsection{The First Copy is Not the Final Copy}
Well, unless you're Isaac Asimov, or Mozart. Print up
draft copies of chapters and give them to your supervisor to read,
then implement any changes when they get returned. Then, a week
later, reread the chapter and change anything that makes you cringe.
\subsection{Spell Check your Work}
If you are using UNIX (as I have assumed throughout this document)
then the {\tt ispell} program is a pretty good spell checker. Also
get someone to check your punctuation and grammar, and be on the
lookout for spellchecker errors (like ``fro'' instead of ``for'',
which will not be picked up at all). Even the {\em worst} writer of
novels who gets published has a good grasp of grammar, because it is
unpleasant to read work which doesn't make sense. There is no point
in putting the examiner in a bad mood by turning the reading of your
thesis into an unpleasant chore.
\section{General Comments}
Traditionally, academic works are written using the passive
voice---``this was done'' rather than ``we did this''. Also, the use
of the personal pronoun ``I'' is avoided in favour of ``we''; but here
you must be careful. There are two ways of using ``we'': either {\em
in}clusively or {\em ex}clusively. Inclusively is pretty much alright
as it makes the reader feel like part of the story; e.g. ``Reducing
Equation 2.3 to Equation 2.4, we can see \ldots''. Exclusively sounds
pompous---``we now present a new algorithm which will solve this
problem \ldots'' and should be avoided unless writing a paper with
more than one author.
There are some other things worth remembering:
\begin{itemize}
\item When referring to another chapter or section, Use a capital
letter; e.g. ``see Chapter~3'' not ``see chapter~3''. Use a tilde
character $(\sim)$ to put a non-breaking space before the number. That
way you will never begin a new line with the number.
\item The layout suggested in this document (introduction, lit.\
review, new ideas, implementation, results, conclusion) is pretty
generic. If you stick to it, you will complete a thorough but boring
thesis. You will almost certainly need to digress occasionally, and
perhaps integrate the literature review more with your own work.
While academic writing isn't usually noted for its racey prose, it
doesn't have to be boring.
\end{itemize}
Finally, at the end of your thesis, don't be afraid to blow your own
trumpet. If you have done something new and original, restate just
what that is. The last part of the concluding chapter is what most
people read straight after the abstract, so it has to be just as pithy
and imagination-capturing.
#FIG 3.2
Landscape
Center
Inches
Letter
100.00
Single
-2
1200 2
1 3 0 1 0 7 50 -1 -1 0.000 1 0.0000 4050 1725 675 675 4050 1725 4725 1725
2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
1800 1125 3075 1125 3075 2325 1800 2325 1800 1125
#FIG 3.2
Landscape
Center
Inches
Letter
100.00
Single
-2
1200 2
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 4
2475 1725 1350 3750 3675 3675 2475 1725
2 4 0 1 0 7 50 -1 -1 0.000 0 0 7 0 0 5
6750 3375 6750 2325 5100 2325 5100 3375 6750 3375
#FIG 3.1
Portrait
Center
Inches
1200 2
2 1 0 2 -1 7 0 0 -1 0.000 0 0 -1 1 1 3
2 1 2.00 60.00 120.00
2 1 2.00 60.00 120.00
2700 1200 2700 4500 7200 4500
3 2 0 1 -1 7 0 0 -1 0.000 0 0 0 7
3300 4200 3900 3900 4500 3300 5100 2400 5700 2100 6300 3300
6900 3900
0.00 0.00 3654.12 4044.11 3804.12 3969.11 4061.70 3783.45
4376.01 3451.25 4658.06 3107.20 4900.33 2576.27 5223.83 2290.68
5452.51 2017.50 6194.99 2264.99 6115.71 3044.33 6387.41 3421.28
6537.41 3571.28 0.00 0.00
4 0 -1 0 0 0 12 0.0000 4 180 1785 3975 5400 Cups of Coffee per Day\001
4 0 -1 0 0 0 12 1.5708 4 180 1485 1500 3750 Programmer Output\001
4 0 -1 0 0 0 12 1.5708 4 180 1110 1800 3600 (lines of code)\001
4 0 -1 0 0 0 12 0.0000 4 135 270 2250 4200 100\001
4 0 -1 0 0 0 12 0.0000 4 135 270 2250 3600 300\001
4 0 -1 0 0 0 12 0.0000 4 135 270 2250 3000 500\001
4 0 -1 0 0 0 12 0.0000 4 135 270 2250 2400 700\001
4 0 -1 0 0 0 12 0.0000 4 135 270 2250 1800 900\001
4 0 -1 0 0 0 12 0.0000 4 135 90 3825 4875 2\001
4 0 -1 0 0 0 12 0.0000 4 135 90 3225 4875 1\001
4 0 -1 0 0 0 12 0.0000 4 135 90 4425 4875 3\001
4 0 -1 0 0 0 12 0.0000 4 135 90 5025 4875 4\001
4 0 -1 0 0 0 12 0.0000 4 135 90 5625 4875 5\001
4 0 -1 0 0 0 12 0.0000 4 135 90 6225 4875 6\001
4 0 -1 0 0 0 12 0.0000 4 135 90 6825 4875 7\001
\chapter{Implementation}
\label{chap:code}
In this chapter, a Computer Science student would be expected to
explain the design-decisions made regarding the program they have
written. Therefore, some way of including code snippets is required,
as well as some way of printing out all of the code as an appendix.
\section{Code Snippets}
The best package for printing out code snippets is {\tt moreverb}, by
Angus Duggan. This lets you print out code listings, with
numbered lines. For code snippets, I suggest you use the {\tt
listing} environment, like so:
\linespread{1} \small
\begin{quote}
\begin{verbatim}
\begin{listing}[1]{1}
... some code here ...
\end{listing}
\end{verbatim}
\end{quote}
\linespread{1.3} \normalsize
The example above will produce a code listing with numbers every line,
starting from line 1, like this:
\linespread{1} \small
\begin{quote}
\begin{listing}[1]{1}
#include <stdio.h>
int main(void) {
printf("hello world!\n");
}
\end{listing}
\end{quote}
\linespread{1.3} \normalsize
I also prefer to issue the command \verb|\linespread{1}\small| before
presenting code snippets, to condense the example somewhat. If you do
this, start a new paragraph just before the command, otherwise it
will be applied to the paragraph above. Also, remember to go back to
normal spacing after the code snippet by issuing the command\\
\verb|\linespread{1.3}\normalsize|.
\section{Code Dumps}
If you look at the file {\tt appendices.tex}, you will see how the
code for this document has been included as an appendix. The
command \verb|\listinginput| has been used---it works just like
\verb|\begin{listing}| except that it reads in a file.
For the purposes of reading your code into a document, I strongly
suggest that you make a directory under your {\tt thesis} directory
called {\tt src\_links}. Then, make symbolic links to all your code
in this directory. Next, use those links as the arguments to
\verb|\listinginput|. Now if you change some code in a file, those
changes will be reflected in your code dump.
This diff is collapsed.
\chapter{Literature Survey}
\label{chap:bib}
Since this chapter would normally contain your literature review and
background sections, it seems like a good time to discuss citations
and bibliographies. The file {\tt thesis.tex} is set to use Harvard
style citations, using the \verb|natbib| package.
The following sections describe how to use this package effectively.
\section{Reference Lists}
The {\tt otagothesis} package automatically renames your selected
bibliography to ``References'', since in Computer Science we only list