In diesem Artikel möchte ich über die Erfahrungen mit Mathematica in einer industriellen Entwicklungsumgebung berichten. Dabei sollen weniger die "Computer-Algebra-Experten" angesprochen werden, die über Unterschiede zu konkurrierenden Systemen (z.B. Macsyma) informiert sein wollen. Vielmehr denke ich an die Anwender, die entweder vorgefertigte Software benutzen oder auch eigene Routinen in "C" oder Pascal anfertigen, um beispielsweise im Bereich Signalanalyse, Regelungstechnik, Bildverarbeitung usw. Prototypen und fertige Anwendungen zu entwickeln.
Es mag überraschen, dass ausgerechnet ein Computer-Algebra-System, welches, wie der Name ausdrückt, vor allem für den Umgang mit mathematischen Datenstrukturen geschaffen wurde, nun eine Lücke in der industriellen Software-Entwicklung und System-Analyse schließen soll. In der Praxis zeigt sich aber, dass eine Umgebung, welche die strukturelle Komplexität mathematischer Objekte umfasst, auch sehr gut Perspektiven für praxisnahe Entwicklungen anbieten kann, generell für eine neue Sichtweise im Umgang mit Datenstrukturen und darauf operierenden Routinen sorgt. Dass dies auch objekt-orientiertem Programmieren nachgesagt werden kann, ist klar.
Die Sichtweise eines Computer-Algebra-Systems wie Mathematica ist jedoch noch ein Stück konsequenter. Die damit verbundenen Vor- und Nachteile sind je nach Anwendung sehr verschieden. Dennoch werde ich versuchen, typische Merkmale aus Anwendersicht zu extrahieren.
Seit dem Auftauchen des Schlagwortes von der "Software-Krise" wurden die Anforderungen an eine Programmiersprache in einer Vielzahl von Artikeln bereits erschöpfend diskutiert. Angesichts der relativ geringen Unterschiede der dabei behandelten Sprachen untereinander (z.B. Pascal, Modula II und "C") kann man im Falle von Mathematica von einem durchaus revolutionären Konzept sprechen. Zwar ist klar, dass eine Verwandtschaft zu vielleicht bekannteren Programmiersprachen wie z.B. Lisp nicht geleugnet werden kann, doch hat Mathematica in wesentlichen Punkten weit mehr zu bieten, als man es von "Sprachen" gemeinhin gewohnt ist.
Zuerst einmal denkt man bei dem Begriff Mathematica wohl eher an eines der vielen für Spezialisten existierenden Software-Produkte, in diesem Fall maßgeschneidert auf die Bedürfnisse des Mathematikers (für die Lösung spezieller Formeln etwa), zumindest jedoch dem Bereich wissenschaftlicher Anwendung zuzuordnen. Diese Aufgabe erfüllt Mathematica sicherlich auch, allerdings ist hierdurch das Potential dieses Computer-Algebra-Systems noch lange nicht ausgeschöpft. Im Umgang mit diversen auf die Ingenieurstätigkeit ausgerichteten (manchmal recht teuren!) "Baukästen" (z.B. zur Untersuchung und Darstellung von Signalen im Zeitbereich) komme ich persönlich oft zu der Überzeugung, auf Gedeih und Verderb dem manchmal zu knappen Horizont der nicht immer professionellen Entwickler ausgeliefert zu sein. Da passiert es durchaus, dass am Ende einer längeren Entwicklungsphase eine Art Schallgrenze erreicht wird, wo bestimmte Funktionalitäten fehlen, die man plötzlich benötigt (und die sich am Anfang einer Entwicklung auch nicht immer klar formulieren lassen), obwohl eine Implementierung auf der Hand läge. Diese nachträglich einzubauen ist aber wegen der Geschlossenheit der Systeme oft nicht möglich. Das soll nun nicht heißen, dass es im Gegensatz dazu in Mathematica keine Grenzen gäbe. Zumindest jedoch sind diese dann weniger struktureller Natur, sondern meist rein technisch bedingt. Um nun konkreter zu werden, versuche ich kurz Mathematica zu beschreiben um anschließend am Beispiel zu demonstrieren, wie Mathematica in technischen Bereichen eingesetzt werden kann.
Mathematica ist ein Interpreter. Man gibt ein Kommando ein und erhält postwendend eine Ausgabe. Dadurch eignet sich Mathematica einerseits sehr gut als "Tischrechner", mit dem man kleine Rechenprobleme fix lösen kann. Darüber hinaus kann man jedoch (wie in prozeduralen Sprachkonzepten üblich) Funktionen definieren, mit Übergabeparametern, lokalen Variablen und zurückgegebenen Funktionswerten. Mathematica arbeitet listen-orientiert. Insbesondere können die Funktionen dabei weitaus mächtigere Datenstrukturen zurückgeben als etwa bei "C" oder Pascal. Natürlich existieren auch die bekannten Schleifen-Konstrukte, IF-Abfragen und was man sonst so alles beim Programmieren braucht. Die Anzahl übergebener Parameter ist variabel, diverse Optionen lassen sich hierdurch sehr gut vordefinieren und als Standards setzen, so dass nur Abweichungen hiervon (etwa Farben oder Stil eines Plots) eingegeben werden müssen. Daneben lassen sich alle Routinen sehr gut dokumentieren. Dieser Text erscheint dann als "Online-Hilfe" bei Bedarf. Als sehr nützlich erweist sich die Möglichkeit, verschiedene Funktionen mit gleichen Namen versehen zu können. Das System entscheidet sich bei Aufruf für den Programmteil, der laut Parameterliste an dieser Stelle dann zugelassen ist (im Sinne einer objekt-orientierten Programmierung). Doch sollte man sich hüten, nur "prozedural" zu programmieren. Nicht, dass dies nicht möglich wäre. Man würde jedoch viele der Besonderheiten und Vorteile von Mathematica ungenutzt lassen. Denn in Mathematica können Regeln für den Umgang mit vom Anwender vorgegebenen Objekten funktional definiert werden.
Als Beispiel sei die Implementierung von Routinen für den Gebrauch komplexer Zahlen genannt, bei der Funktionalgleichungen für Konjugieren, Bildung von Real- und Imaginärteil usw. dem System einmal eingegeben werden, um darauf aufbauend symbolische Rechnungen ausführen zu lassen. Der Gebrauch gerade dieser Aspekte der Sprache Mathematica erfordert einige Umgewöhnung seitens des Anwenders. Eine Entscheidung darüber muss aber nicht sofort getroffen werden. Auch die rein prozedurale Programmierung bringt in fast allen Fällen bereits erhebliche Vorteile.
Neben diesen sprachlichen Eigenschaften ist Mathematica eine mathematisch-naturwissenschaftliche Wissensbasis, in der viele Algorithmen bereits als fester Bestandteil des sog. "Kernels" implementiert sind (z. B. Differentiation, Integration, numerische Algorithmen, Fourier-Transformation für beliebige Vektorlängen, Besselfunktionen u.v.m.). Ein besonderer Hinweis sei hier auf die Grafikfähigkeit des Systems gegeben: Mächtige Grafik-Ausgaberoutinen sind standardmäßig implementiert. Plots werden automatisch skaliert; gegebenenfalls werden Maxima abgeschnitten, um "größtmöglichen Informationsgehalt" zu zeigen (natürlich abschaltbar). Dreidimensionale Grafikausgaben sind ebenfalls möglich. Zusätzlich werden mit Mathematica eine Vielzahl von Bibliotheken geliefert, die sich, einmal importiert, wie Kernelfunktionen handhaben lassen. Beispielsweise existieren Module für lineare Algebra, Statistik, Chemie, Physik, Laplace-Transformation, Zahlentheorie, Geometrie usw. Die Mächtigkeit eines einzelnen dieses Pakets stellt dabei den Funktionsumfang der auf dem Markt befindlichen "Spezialisten" oft sogar in den Schatten. Eigene Modifikationen und Erweiterungen müssen nicht "erkämpft" oder über Umwege und Tricks erzwungen werden, sondern sind erwünscht; die Integration ist sehr einfach. Zahlreiche Benutzer-Gruppen unterstützen die Anwender mit vielen Megabytes an Sourcen.
Nachdem ich nun die beiden Haupt-Eigenschaften von Mathematica, Programmiersprache und Wissensbasis, kurz geschildert habe, versuche ich nun, einen Eindruck von der Anwendbarkeit speziell im technisch-industriellen Bereich zu geben. Leider kommt mit dieser Diskussion auch der sicherlich größte Nachteil ins Spiel: Mathematica ist kein High-Speed-System und benötigt viel Speicher. Auch ist der erforderliche Zeitaufwand für die Einarbeitung von Mitarbeitern nicht zu unterschätzen.
Wo bleiben also die Einsatzfelder?
Einerseits kann beim Entwurf von Algorithmen eine erste Realisierung sehr schnell in Mathematica erfolgen. Der durch die Verfügbarkeit der oben genannten Standardpakete gewonnene Zeitvorteil ist je nach Anwendung sehr groß. Braucht man die so entwickelte Lösung als schnelle Implementierung auf einem Zielsystem, so muss eine erneute Programmierung (etwa in "C") erfolgen (bei insgesamt meist immer noch deutlichem Zeitgewinn). Dies ist denke ich auch das Standard Einsatzgebiet von Mathematica in der Industrie.
Eine weitere, wahrscheinlich nicht so naheliegende Anwendung, möchte ich ebenfalls erwähnen: In vielen Fällen wird der größte Teil der Entwicklung von Software für die Erstellung von Prototypen verbraucht. Testphasen werden in der Regel von zig Compiler-Läufen, DEBUG-Befehlen, PRINT-Anweisungen, Deklaration von teilweise nur wenige Tage überlebenden Datenstrukturen, Testumgebungen usw. begleitet. Dabei ließen sich viele Probleme anhand einfacher Modellbildungen auf der Basis einer der Bezeichnung "Hochsprache" wirklich gerecht werdenden Programmiersprache bereits vorher aufdecken. Ein praktisch sofort verfügbarer Grafikausdruck in Mathematica zeigt meist wesentlich mehr über die Dynamik einer Variablen als die Ausgabe von PRINT-Anweisungen, zusätzliche Analyse-Möglichkeiten (Statistik, numerische oder symbolische Berechnungen) laufen parallel zur Programmentwicklung ohne den zeitaufreibenden Umweg über jedes Mal neu zu schaffende Schnittstellen zwischen Entwicklungsumgebung und Analyse-Werkzeug, als Parameterliste (im Klartext!) übergebene Optionen lassen die flexible Benutzung der gleichen Routine in verschiedenen Variationen zu. Darüber hinaus ist der Programmablauf bzw. die Interaktion zwischen verschiedenen Programmteilen sehr viel leichter einzusehen, wenn, abgeschottet von der starren Syntax konventioneller Sprachen (die menschlichem Denken nur unzureichend entspricht) entwickelt werden kann. Oder anders formuliert: Die Programmentwicklung kann häufig zerlegt werden in eine Reihe "niederer", teilweise hardware-naher Funktionen, und einen übergeordneten, die Struktur des Programmablaufs und das Zusammenspiel der Hilfsroutinen bestimmenden Bestandteil (die "Mensch-Maschine-Schnittstelle"). Die Abwicklung der Entwicklungs- und Testphase für diesen letztgenannten Programmteil bietet sich unter Mathematica förmlich an.
An technischen Voraussetzungen für diese Form der Programmentwicklung benötigt man natürlich wieder Schnittstellen zum Betriebssystem und den hier aufzurufenden (z.B. "C"-) Routinen. Hierzu ist zu sagen, dass mit Mathlink, einem Teilpaket von Mathematica, diese Funktionalität im Prinzip gegeben ist, in der derzeit aktuellen DOS-Version 2.2 jedoch noch nicht implementiert ist. Man ist unter DOS somit auf den leider umständlichen Umweg über Dateien angewiesen.
Konträr zu diesem Anwendungsfall kann man sich auch einen zentralen Mathematica-Kernel denken, auf dem die "unteren" Routinen (Statistik, Datenmanipulationen usw.) ausgeführt werden. Die Interaktion mit dem Anwender übernimmt ein geeignetes Frontend auf dem gleichen oder einem über ein Netz angeschlossenen Rechner. Angesichts hervorragender Oberflächen in der DOS-Welt ist die Verbindung Mathematica-Kernel (z.B. unter UNIX oder VMS) mit einer Reihe angeschlossener PC's sehr komfortabel und preisgünstig realisierbar. Diese Kombination Mathematica-Kernel/anwenderfreundliches Frontend liefert ebenfalls ein sehr wichtiges Beispiel für den (industriellen) Einsatz von Mathematica als Zielsystem.
Koordinatentransformation in der Bildverarbeitung
Als Demonstrationsbeispiel für eine Mathematica-Entwicklungsumgebung habe ich Routinen aus der Bildverarbeitung gewählt. Einerseits schlägt hier die langsame (durch dynamische Datenstrukturen bedingte) Ausführungsgeschwindigkeit als besonderer Minuspunkt zu Buche (in der Entwicklungsphase kann dieser Nachteil wohl toleriert werden). Andererseits kann nahezu jeder mit diesem Thema intuitiv eine Vorstellung verbinden, so dass die Übertragung auf das eigene Gebiet vermutlich sehr leicht fällt. Ziel war es, Prozeduren zu schaffen, die die Behandlung von Bilddaten unter unterschiedlichsten Aspekten ermöglichen sollten (beispielsweise die bei Rotation günstige Umwandlung von Polar- in kartesische Koordinaten ohne explizite Anweisung). Dadurch wurde ein Entwicklungssystem ermöglicht, bei dem der Einsatz der die Bilddaten manipulierenden Algorithmen (z.B. Fourier-Transformationen) ohne die Beschränkung einer zu starren Syntax möglich ist. In gewissem Sinne kann man auch von einem Betriebssystem für die Bildverarbeitung sprechen, dessen Ziel es ist, die unterschiedliche rechnerische Handhabung verschiedener Formate dem Anwender durch eine übergeordnete Schicht zu verdecken (am Beispiel des Schlagworts "Multimedia" mit seinen unzähligen Bild- und Tonsignalvarianten fallen einem sicher auf Anhieb sehr viele weitere potentielle Einsatzgebiete ein).
Folgende Funktionen wurden daher implementiert:
Es würde den Rahmen dieses Artikels sprengen, nun alle Sourcen hier abzudrucken. Stellvertretend möchte ich mich auf die Besprechung einer kleinen Auswahl beschränken:
Das Modul Point bietet eine bequeme Möglichkeit, mit Punkten in der Ebene zu arbeiten. Das wesentliche Feature des Modul Point ist, dass verschiedene Koordinatensysteme automatisch ineinander umgewandelt werden. Darüber hinaus soll die Möglichkeit existieren, eine beliebige Punktrepräsentation in eine bestimmte Zielrepräsentation zu normalisieren. Dies tritt z.B. bei Algorithmen auf, die kartesische Koordinaten benutzen, die aber trotzdem mit Polarkoordinaten gefüttert werden sollen. Das Modul Point ist nicht in sich abgeschlossen, sondern es kann bei Bedarf vom Benutzer/Programmierer um weitere Koordinatensysteme erweitert werden.
Es gibt einige Grundstrukturen:
Beispiel
ToRules[CartesianPoint[1, 2]] ergibt {x -> 1, y ->2},
ToRules[ PolarPoint[2, 3]] ergibt {a -> 2, phi ->3}.
Die Umwandlung eines Punktes P in eine bestimmte Repräsentation Q erfolgt durch Q[P]:
Es sei P = PolarPoint[1., Pi/2]
CartesianPoint[P] ergibt CartesianPoint[6.12303 10-17, 1.]
mit Chop[%] (unterdrückt "sehr kleine Zahlen") ergibt sich der richtige Wert
CartesianPoint[0.,1.].
Die Umwandlung von Repräsentationen ist nicht automatisch numerisch, sondern symbolisch. Das bedeutet, dass CartesianPoint[PolarPoint[10 + 20I]] nicht gleich CartesianPoint[10, 20] ist. Dies ist natürlich, da Ausdrücke wie etwa Sin[ArcTan[x]] nicht standardisiert vereinfacht werden.
Die Repräsentationen, unter denen der Benutzer auswählen kann, sind vielfältig:
Um einen kurzen Einblick in die Implementierung zu geben, erfolgt hier die Wiedergabe von ein paar Zeilen Programm-Code:
(* zuerst der Online-Hilfstext von Mathematica: *)
PointQ::usage = "PointQ[P] testet, ob ein Punkt der Ebene repraesentiert wird."
CartesianPoint::usage = "CartesianPoint[P] mit PointQ[P] repraesentiert einen Punkt der Ebene CartesianPoint[x, y]. Man erhaelt {x->..., y->...} nach Anwendung von ToRules."
PolarPoint::usage = "PolarPoint[P] mit PointQ[P] repraesentiert einen Punkt der Ebene PolarPoint[a, phi]. Man erhaelt {a->..., phi->...} nach Anwendung von ToRules."
In der Implementierung wird die Funktionalitt dieser Darstellungensarten ausgedrückt:
(* die Implementierung: *)
(* CartesianPoint ist ein Punkttyp: *)
PointQ[_CartesianPoint] := True
(* Linearitaet: *)
r_ * CartesianPoint[x_, y_] := CartesianPoint[r x, r y]
CartesianPoint[x1_, y1_] + CartesianPoint[x2_, y2_] := CartesianPoint[x1+x2, y1+y2]
(* Konversion moeglichst vieler Arten: *)
CartesianPoint[CartesianPoint[x_, y_]] := CartesianPoint[x, y]
(* kartesisch nach polar konvertieren: *)
CartesianPoint[PolarPoint[a_, phi_]] := CartesianPoint[a Cos[phi], a Sin[phi]]
(* z eine komplexe Zahl: *)
CartesianPoint[z_] := CartesianPoint[Re[z], Im[z]]
(* PolarPoint ist ein Punkttyp: *)
PointQ[_PolarPoint] := True
(* Linearitaet: *)
s_ * PolarPoint[a_, phi_] := PolarPoint[s a, phi]
P_PolarPoint + Q_PolarPoint := PolarPoint[CartesianPoint[P] + CartesianPoint[Q]]
(* PolarPoint-Konvertierung, unvollstaendig: *)
PolarPoint[CartesianPoint[x_, y_]] := PolarPoint[Sqrt[x^2+y^2], ArcTan[x, y]]
PolarPoint[a_ * E^(I phi_)] := PolarPoint[a, phi]
(* Ende Programm-Text *)
Auch wenn die Syntax von Mathematica dem Leser nicht hinreichend bekannt ist, lassen sich doch wichtige Programmierprinzipien aus dem abgedruckten Beispiel leicht ableiten.
Die Aufgabe des Moduls Koordinatenraster ist die Zerlegung der (Bild-) Ebene in Zellen. Diese werden dann als Einträge einer Matrix interpretiert. Entspricht diese Zerlegung einem kartesischen Koordinatensystem, so sind die Zeilen und Spalten dieser Matrix auch die Zeilen und Spalten der Bildmatrix. Andernfalls handelt es sich um verallgemeinerte Zeilen und Spalten (beispielsweise bei der dem Polarkoordinatensystem entsprechenden Zerlegung der Ebene in Kreissegmente). Der Referenzpunkt einer Zelle wird für jeden Rastertyp gleich als der Flächenschwerpunkt definiert.
Ein kartesisches Raster wird eindeutig spezifiziert durch Angabe der Größen xMin, xMax, Columns, yMin, yMax und Rows. Ein kartesisches Raster wird aber auch eindeutig spezifiziert durch Werte für die Größen xMin, xDelta, xStep, yMin, yDelta und yStep. Es ist natürlich auch möglich, ein Raster durch xMax, xDelta, xStep, yDelta, yStep und yMid festzulegen etc. Die Art der Spezifikation sollte von vornherein nicht festgelegt sein. Für ein Raster fallen je nach Situation immer andere Größen an. Die hier vorgestellte Lösung dieses Problems bringt deshalb die volle Flexibilität von Mathematica ein. Zur Spezifikation eines Rasters stehen einige Relationen zur Verfügung. Diese Relationen werden in Mathematica formuliert als Gleichungen (Links == Rechts) und logisch (mit NICHT, UND, ODER) verknüpft zu einem Gleichungssystem.
EQ1 = (xMin == 10) UND (xMax == 20) UND (Columns == 10)
UND (yMin == 10) UND (yStep == 1) UND (yDelta == 10).
Aus dem so entstandenen Gleichungssystem wird nun ein (kartesisches) Raster konstruiert, indem das System um einige feste Relationen ergänzt wird (z.B. xDelta = xMax - xMin) und das gesamte Gleichungssystem nach allen interessierenden Größen aufgelöst wird. Dabei kann das Gleichungssystem auch über- oder unterbestimmt sein, oder es ist gar nicht eindeutig lösbar (xMin2 == 4). Jeder dieser Fälle hat aber auch in der Anwendung seine Berechtigung:
Ein inkonsistentes System enthält keine Information und kann etwa aus anderen Berechnungen hervorgegangen sein. Ein überbestimmtes System ergibt sich, wenn alle Größen bekannt sind (etwa weil es sich um ein schon konstruiertes Raster handelt). Ein unterbestimmtes System entsteht, wenn noch nicht alle Größen bekannt sind oder wenn einige Größen vorsätzlich in symbolischer Form angegeben wurden. In diesem Fall werden alle interessanten Größen des Rasters als Funktionen in den offenen Symbolen ausgedrückt. Ein nicht eindeutiges System entsteht nur bei Relationen, die über einfache Linearitäten hinausgehen, etwa wenn ein kartesisches Raster an einen Punkt eines Kreises angeheftet werden soll. Eine wichtige Erweiterung des Gleichungslösens besteht darin, zur Spezifikation eines neuen Rasters ein altes mit heranzuziehen. Die Aufgabe dabei ist also, fast alle Größen eines alten Rasters zu übernehmen aber einige auch zu ändern. Mit dieser Technik lassen sich Raster sehr elegant miteinander verbinden. Viele Probleme eines starren Ansatzes, der sich auf einen festen Satz von charakteristischen Größen stützt, treten bei dem flexiblen Ansatz nicht auf.
In der Implementierung folgen nun weitere Module, die alle eines zum Ziel haben: Die (rechnerische) Behandlung eines Grauwertbildes unabhängig von einer speziellen Darstellung zu ermöglichen. Während das gleiche Beispiel in klassischen Hochsprachen vom Programmierer einiges an Konvertierungsakrobatik abverlangt, erledigt im Falle von Mathematica die Sprache an sich zusammen mit dem eingegebenen funktionalen Wissen diese Aufgabe automatisch. Dies ist umso wichtiger, je größer die Distanz zu den programmierten Routinen wird, sei es, dass einige Monate seit Benutzung des Paketes vergangen sind, oder weil ein Software-Projekt von verschiedenen Mitarbeitern behandelt wird, die sich mühselig in die jeweils individuelle Schreibweise des anderen einarbeiten müssen. Beides wird durch die Programmierung auf dem hohen Abstraktionsgrad von Mathematica verhindert (zumindest abgeschwächt), so dass in der Praxis eine schnelle und zuverlässige Projektentwicklung garantiert ist, sofern man bereit ist, in die entsprechende Einarbeitungszeit zu investieren.
Abschließend möchte ich kurz auf ein Feature eingehen, welches nur mit Mathematica auf NeXT-, Windows- und Macintosh-Rechnern verfügbar ist: Das Frontend , die sogenannte "Notebook-Oberfläche" zum Kernel besteht hier aus einem speziellen Editor, bei dem Programmtext, Programmausgabe, Grafik und Dokumentation beliebig (auch hierarchisch) gemischt und angeordnet werden können. Mit diesem Werkzeug lassen sich längere Programmsitzungen ausgezeichnet dokumentieren, wobei die Grafik vorbildlich sowohl als Postscript-Information als auch simultan (für schnellen Bildaufbau) als Bitmap gespeichert wird. Letzteres lässt sich daher verlustfrei (z. B. bei voller Platte) löschen. Abschnitte lassen sich komplett "wegklicken" und mit Überschriften versehen, so dass hiermit ein Konzept der Vermischung aus Programmtext, Grafik und Dokumentation möglich ist, die die Idee eines "Literate Programming" (nach D. Knuth) noch bei weitem übertrifft. Tatsächlich müsste sich sogar mit bescheidenem Aufwand ein Dokumentationstool programmieren lassen, welches konventionelle Programmtexte hierarchisch importiert und darstellt, die eingebundene Dokumentation in speziellen Fonts wiedergibt und den Programmablauf unter Zuhilfenahme eines Programms zur Erstellung von Flussdiagrammen in Postscript jederzeit abrufbar visualisiert. Beim "Durchblättern" durch das Programmpaket würde man ausgehend von einer Art Inhaltsverzeichnis die einzelnen Teilabschnitte bis hinunter in eine unterste Ebene nacheinander "aufklappen" können. Die notwendigen Änderungen an den darzustellenden Programmtexten wären geringfügig. Wie Sie sehen, sind der Kreativität beim Einsatz von Mathematica kaum Grenzen gesetzt. Mathematica ist mittlerweile in der Version 2.2 erhältlich und biete viele neue Möglichkeiten.
