By Norbert Köckler

Die Idee zu diesem textual content entstammt meinem immer wieder unglaubigen Erstaunen daruber, daB selbst erfahrene Ingenieure, Physiker oder Mathematiker ihre seasoned gramme lieber vollstandig selbst schreiben als Programmpakete zu benutzen. Ja, selbst einige meiner Numerik-Diplomanden erachten es als eine Zumutung, wenn ich verlange, daB gewisse Teile ihrer Programme durch Bibliotheks-Routinen er setzt werden. Woran liegt das? those 1: "Programmpakete sind entweder intestine oder leicht bedienbar. " Diese those klingt sehr rigoros, enthiilt aber sicher einen wahren Kern. Da gibt es benutzerfreundliche Dialog-Systeme zur Losung numerischer Probleme auf einem laptop, die den Benutzer sanft von den Problemstellungen uber die Verfahrensauswahl bis zur Parameter-Eingabe und Losung geleiten, aber nichts zur Fehleranfiilligkeit der Algorithmen sagen, ungenaue Funktionen verarbeiten oder zweideutige Routi nen enthalten, Beispiele findet guy in [30]. Andererseits gibt es Pakete wie NAG!, die uber Hunderte von Routinen verfugen. Sie sind in vielen Jahren Arbeit mit sorgfaltiger Problemanalyse, Programmierung und try entstanden und werden durch neue Releases regelmaBig "gewartet." Ihr guide fUllt aber viele dicke Ordner. Das schreckt viele Benutzer abo Dabei wird guy doch belohnt mit fehlerfreien Programmen, moglichst exakten Ergebnissen, graphischen Darstellungsmaglichkeiten und genau definierten Programmablaufen. those 2: "Jedes Programm mit mehr als 50 Zeilen ist falsch. " Diese those trifft leider ebenso haufig zu, wie sie auf Widerspruch staBt. Durch die VerfUgbarkeit guter Programmpakete ist es immer sinnloser geworden, daB der Mathematiker, der Naturwissenschaftler oder der Ingenieur die Losungsroutinen fUr seine numerischen Standardprobleme selbst programmiert.