Lutz Prechelt      

Current home address:
Lutz Prechelt
Kilianstr. 18
70327 Stuttgart
Phone: +49/711/3808 104
Mobile: +49/163/6141500

As of April 2000, I have left the university and joined abaXX Technology in Stuttgart. I am still reading my email sent to the university, though. Before I left, the following information applied (except for the list of publications, none of it is being actively maintained any more):

I am a senior research associate. See information about my

• research,
• Lehre (teaching),
• WWW services, and
• other things.

Here is my online list of publications.
You find a few future appointments in my plan file.
Several resources that I found interesting and/or important are in my personal hostlist.

• empirical software engineering
• parallel computation
• neural network learning algorithms
• research methodology
• other projects

• How useful is the Personal Software Process (PSP) methodology? Can specific differences in behavior, productivity, or product quality be detected between programmers using a PSP and others? [pspeTR, pspe]
• Can PSP benefits be achieved without a PSP course? How? [deflog]
• Which errors are made by programmers in different languages, different work environments, after certain events, at different times of day etc.?
• Are run-time checked assertions (preconditions and postconditions) really useful? Do they help during maintenance? [assert]
• How, if any, does the depth of the inheritance tree of a program affect maintenance? [Inherit], [InheritTR].
• How useful are design patterns for communication during design, for program development, and for program maintenance? [PatDocTR1], [PatDoc], [PatMain], [Patseries]
• How can uses of design patterns be found in existing software (reverse engineering)? [PAT]
• How useful is automatic type checking in terms of productivity and program quality? [tcheck]
• Which tools can/should be built to support the Personal Software Process (PSP)?
• How useful are inner-procedural refinements for program comprehension? [Refine]

You can find short descriptions for some of these projects on the Karlsruhe Empirical Software Engineering Research Group (EIR) page. In particular, we usually publish the experiment materials and the raw data along with the results to simplify building upon our work by others. We do this in the form of so-called experiment packages.

Compilers for parallel computing

• One outflow of this idea is CuPit [CupitTR], a special-purpose language for neural network learning algorithms. Employing a special-purpose language allows for compiler optimizations that would not otherwise be feasible for dynamically changing, irregular problem structures [Cupit]. The idea was successful enough that we created a second version of the language [Cupit2TR] and compilers for SIMD, SMP, and sequential machines.
  The SIMD compiler source code is available as a literate programming document [CupitCompTR].

• Another result is REAPAR, a system for automatic parallelization of highly irregular recursive C programs on SMP machines [reapar].

• pruning algorithms [Prune],
• additive (constructive) algorithms [CasCor], and about
• stopping criteria to be used with the popular early stopping technique [Stopping] [StoppingTricks].

During this work, I found it useful to prepare and publish a standardized benchmark collection [Proben1], which is available from the Neural Bench Archive at CMU as proben1.tar.gz (1.8 MB) and also from ftp://ftp.ira.uka.de/pub/neuron/.

This later led to a NIPS 1995 workshop on NN benchmarking, which in turn resulted in the NN benchmarking resources page.

Research methodology

As a follow-up I did a similar investigation specifically for the evaluations of published neural network learning algorithms. The results were just as bad [NNeval].

Fortunately, things appear to have improved since that time.
I am trying to help with this process by publishing advice and infrastructure and by explicitly encouraging researchers to admit and publish their failures, because we could learn more from them if they were described explicitly as such instead of being disguised as successes (for instance by not testing claims at all). Therefore, I have founded the Forum for Negative Results, a permanent special section of the Journal of Universal Computer Science.

One recurring idea in my research (although not really a methodological one) is the idea of simplicity. I am always looking for cases, where we can have 80 percent of the possible benefits with only 20 percent or less of the cost or complexity of other approaches. [reapar], [PAT], and [deflog] are examples of what may result from this attitude.

Other projects

• A melody recognition interface [Tuneserver].
• A system for finding plagiarisms in a set of programs [jplag].
• Some work on cooperation, related to the prisoner's dilemma [INCA].
• In an earlier life, I have worked on natural-language-based retrieval from a knowledge representation system [YAKR].

• Try out the TuneServer melody recognition service. It recognizes about 10000 tunes from classical music. (Sorry, the service is currently nonfunctional because the university has now restricted the access to non-standard network ports such as the one used by the recognition server.)
• If you teach university programming courses and fear your students might cheat by copying their assignments from colleagues, register for use of the JPlag plagiarism detection system.
• You can find some (possibly useful) software tools written or maintained by me on my software page. In particular, you can get the C-Refine processor there, which introduces the very useful inner-procedural refinement language construct into C and C-like languages.
• From 1996 to 2000, I was the maintainer of the v.f.h. home page (in German).
• Until July 1999, I was the maintainer of the local Informatik-Mittelbauseite (in German), now maintained by Oliver Rogalla.

I was the organizer of the "International Knobeln Contest", which was conducted twice (in 1993 and 1994). See an old announcement, or lots of material about the contest, including all results and software, or the paper [INCA] that describes how the interaction model underlying the Knobeln game can be used as a model of interaction that avoids some of the deficiencies of the popular prisoner's dilemma model.

And for all the brave who had enough endurance to read up to this point here is a nice collection of disclaimers which I found on USENET over the years. (For best satisfaction I recommend consumption in small doses.)

Now for the bumper-sticker section: