My Star Wars fanboy credentials are a bit weak. I didn’t see the movies until I was 15, and it took three more years (and half a bottle of Jose Cuervo’s finest) until I finally saw greatness in the “I AM your father, Luke!” scene. For a couple of happy years, I remained a follower. I was involved in the purchase of a cam-ripped CD set of Episode One and subsequent crappy-quality monaural impromptu screenings at my school. I queued up in the wee hours of the morning with the costumed freaks for tickets for the first showing (to be informed by the cinema employee that all the premiere tickets were sold to a single corporate buyer, who used them in a giveaway).

Two movies later, I’m more annoyed by Jar-Jar Binks and stupid Anakin than I am awed by any genius that might be visible if I got drunk enough. Of course, I also have enough of a life to not care a lot anymore. However, I have to admit that I felt strangely satisfied when I found out that there actually was punishment for being an annoying nuisance in the Star Wars universe: As the genius author of Endor Holocaust proves conclusively, the demise of Death Star II at the end of ROTJ was definitely the end of Ewok life on Endor:

The severity of the effect on Endor must be much greater than the versions projected for Earthly nuclear wars and single asteroid impacts, since the amount of dust involved is comparable to a small moon rather than insignificant portions of the planetary crust. Such is the magnitude of the Endor event that it is yet unclear whether the atmosphere would even remain breathable. The chemistry of the air, land and water may be grossly altered (because of the burning meteoritic material). The explosion probably is accompanied by a huge burst of deadly radiation. Additionally, the remains of the Death Star II might have been highly radioactive, depending on the characteristics of the station’s power technology. The scope of mass-extinction will be nearly total. Only very simple lifeforms will survive on Endor, and the ewoks are not quite simple enough.

I need to re-watch episodes one to three again, looking for clues that suggest a similar demise for those damn Gungans.

This is adorable: Fefe reports that gcc optimizes code of the form

if(some_int > some_int + 100)

as “always true” in recent versions, apparently because ANSI C doesn’t require that signed integers wrap. Does this mean that 90% of Gentoo installations worldwide are now wide open to integer overflows? Muhaha.

Somebody believes that physicists need to experiment. Thus, physicis students need to learn to experiment. To this end, they are subjected to lab courses where they have to re-enact various classical experiments and ideally reproduce their results. From the first lab – whose output consists of measuring values and writing them in pre-formatted tables – upwards, the work tends to become more indepent. This year’s major addition was the requirement to produce a written documentation of each experiment, which suddenly led to increased interest in scientific publishing on my part.

I’ve been known to rant about OpenOffice.org in the past, but like every serious ranter, I need to face up to the question: What else? At the beginning of this semester, I didn’t have a serious answer (which is why the first two documents were produced in OO.o), but by now I’m all set up. Here’s a couple of reasons you don’t want to use OpenOffice:

• The formula editor sucks. Formulas in continous text always look strange. There’s no way to use styles for formula objects. If you want to change the fonts in all your equations, you need to do so manually for each one.
• Graphics support sucks. oowriter does handle EPS files on Linux, but apparently, the EPS support doesn’t work on Windows. It is supposed to work with a PS printer driver installed, but I couldn’t reproduce that. It also can’t use PDFs as graphics on either platform, which is a mystery to me since that is pretty much the lingua franca in document snippet exchange these days. I ended up using GhostScript to convert my EPS graphics to 1200 dpi GIF files, but I refuse to call that a solution.
• Graphing support sucks. OpenOffice can’t fit curves except for simple linear functions. It doesn’t support math typesetting in graphs. Besides, the user interface of the Chart module is a major PITA.

Of course, in typical UNIX fashion, the solution isn’t just one tool, but a whole toolchain. Here’s a short overview of the tools involved:

1. gnuplot – awesome graphing capabilities
2. GNU Emacs – mostly for its Gnuplot interaction mode
3. LaTeX – typesetting
4. Vim – LaTeX editor of choice
5. GNU Make – tying things together
6. OpenOffice.org Calc – data entry and basic math
7. calc2latex – LaTeX table generation
8. Subversion – version control

Before or during the experiment, I set up an OpenOffice spreadsheet to enter the data, usually along with some preliminary calculations to catch entirely ridiculous results while there’s still time to check for errors. This is where the data goes during the experiment. Afterwards, I usually spend a some time cleaning this up and going through post-processing, mostly for error calculations and more complex evaluations. Once the values are deemed finished, those that will enter plots are exported to separate text files for gnuplot to read. I use gnuplot-mode in EMACS to interactively develop the plot until it looks good in the X11 terminal (I should talk about the absolute awesomeness of gnuplot here, but that’s for another post), then store the resulting gnuplot script in a foo.gnuplot file. Stuff that ends up in tables is exported as table environments to bar.tex files via calc2latex. Including either a plot or a table in the main LaTeX document then only reguires an \include{foo} or \include{bar} and an addition to the Makefile. Here’s a quick overview of the Makefile I usually use to compile my documents:


.PHONY: view all clean


These standard commands should be executed even when everything looks like it’s up to date.


tables = Nullpunkt.tex Abklingzeit-Tabelle.tex Motor.tex


This variable contains the list of the generated tables.


plots = Kalibrierkurve.gnuplot Seilspannung.gnuplot Abklingzeit.gnuplot Resonanzkurven.gnuplot Nullpunkt-Diagramm.gnuplot Nullpunkt2-Diagramm.gnuplot Phasenraum.gnuplot Phasenlage-1_25V.gnuplot Phasenlage-8V.gnuplot Phasenlage-15V.gnuplot Schwingung-0A.gnuplot Phasenraum2.gnuplot Schwebung1.gnuplot Schwebung2.gnuplot


This list contains the names of the gnuplot scripts that generate my plots.


gentex = $(plots:gnuplot=tex)<br/>
geneps = $(plots:gnuplot=eps)<br/>
figures = $(plots:gnuplot=pdf)<br/>


These variables then contain the list of the various intermediate files that gnuplot produces.


all: Protokoll-Pendel.pdf


The standard build result.


clean:<br/>
&nbsp;&nbsp;&nbsp;&nbsp;-rm *.pdf *.aux *.log *.eps $(gentex) $(geneps)


A crude clean target, to make that “make clean” remove all the generated files. Note the ‘-’ at the beginning that causes make to ignore errors.


Protokoll-Pendel.pdf: Protokoll-Pendel.tex $(figures) $(tables) <br/>
&nbsp;&nbsp;&nbsp;&nbsp;pdflatex $&lt; <br/>
&nbsp;&nbsp;&nbsp;&nbsp;pdflatex $&lt; <br/>
&nbsp;&nbsp;&nbsp;&nbsp;make view <br/>


This builds the main file twice (for references and the ToC) and displays it whenever one of the parts changes.


view:<br/>
&nbsp;&nbsp;&nbsp;&nbsp;xpdf Protokoll-Pendel.pdf &amp;


Display the result in xpdf.


%.pdf: %.eps<br/>
&nbsp;&nbsp;&nbsp;&nbsp;@echo "eps2pdf: $&lt; -> $@"<br/>
&nbsp;&nbsp;&nbsp;&nbsp;epstopdf $&lt; <br/>


General rule to convert the EPS graphics from gnuplot to PDFs needed by pdflatex. This isn’t necessary if you’re using normal LaTeX, but I hate DVIs, so I work with PDF directly.


%.eps: %.gnuplot<br/>
&nbsp;&nbsp;&nbsp;&nbsp;(<br/>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;echo set term epslatex color<br/>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;echo set out \"$(@)\" <br/>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;cat $&lt;<br/>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;echo set out<br/>
&nbsp;&nbsp;&nbsp;&nbsp;) | gnuplot -<br/>
&nbsp;&nbsp;&nbsp;&nbsp;perl -npe 's/\./,/g;' -i $(subst eps,tex,$@)<br/>


This is the rule that actually creates the plots. The first command wraps the interactive gnuplot script with the header and footer needed to generate an appropriate output file. The second command replaces the ‘.’ decimal separator in the generated TeX file with the comma that is appropriate in German documents.

With these few lines of magic in place, writing the actual document in Vim becomes rather comfortable. I use vim’s :make command to see the current state of the document whenever I feel like that, and it works nicely, no matter whether I’m editing a plot, a table or the main TeX source. It’s reasonably quick to a add a new plot or a new table, and document history is nicely traceable through svn.

What could be better in the current workflow?

• Modelling. The part that is still dominated by OpenOffice Calc is cumbersome and inelegant. Entering a slightly complex formula is complicated and error-prone since there is no symbolic notation – a typical cell formula looks something like this: =0.0000004*PI()*$A12*$B$3/$B$5*(($B$4/2+$B$5)/SQRT($B$6^2+($B$4/2+$B$5)^2) - $B$4/2/SQRT($B$6^2+($B$4/2)^2)). That would be a lot nicer if there was a way to give names to cells in Calc. I’ve been hoping to find a clever way to do this in Maple, but I haven’t yet figured out how to do it.
• Table export. While calc2latex is really a highly useful package, I still do a lot of manual postprocessing on the generated files until the formatting looks good. This is a major timesink that I need to get rid of. Probable routes include hacking calc2latex to automatically consider my formatting preferences, learning enough TeX to make a custom table environment that fits my wishes or writing a postprocessor to automate the changes.
• Makefile maintenance. Keeping track of plots and tables is not too much work, but in principle it should well be possible to just scan the main TeX file and automagically find out what its dependencies are. Something like gcc -M would be truly elegant.
• Plot Data. Currently, changes in the datafiles that the plots reference do not trigger regeneration of the plots. Another automatic dependency scanner, I guess.

As always, comments and suggestions are welcome!

The game of life, is to keep the SF’s score low. If you do something bad in life, the SF gets two points. If you don’t do something good that you should have done, the SF gets one point. You never score, so the SF always wins.

Allegedly from Paul Erdős . The SF is, of course, the Supreme Fascist.

Old news, but it took me until today to find it: Wolfram Research produced a MIDI generator that algorithmically composes music in a variety of styles. The piano pieces sound surprisingly like piano music from human composers.

Even though it’s supposed to be a ring-tone generator, nothing I got out of it was quite as rousing as my current tone, the rendition of The British Grenadiers from the Barry Lyndon soundtrack, so that stays as it is.