Software-Projekt SW05


- N a v i g a t i o n - - - - - - - -

- VI-ANEC
- Über das Institut
- Software-Projekte
- Hardware-Projekte
- Best-Paper-Best-Program-Awards
- Sponsoring
- Dienste
- Kontakt

Symbolic Genetic Programming innerhalb Mathematik-Programme


 

- - - - - - - - - - - - - - - - - - - -

 

- - - - - - - -
EA innerhalb Mathematikprogramme

Im Software-Projekt SW01 soll ein auf Internet-Technologien basiertes, verteiltes EA-System entworfen, und als Open-Source implementiert werden, wobei verschiedene, potentiell relevante Architekturen gegebener Systeme wie distributed.net, Javelin, Jini oder root auf ihre Eignung untersucht werden sollen. Eine weitere Klasse von gegebenen Architekturen sind symbolische Mathematik-Programme wie Mathematica, Maple, MuPAD oder Reduce bzw. numerische Mathematik-Programme wie Gauss, Matlab, O- Matrix, Ox, R- Lab, Scilab (ein Vergleich der Eigenschaften und ihrer Performance findet sich in "Comparison of mathematical programs for data analysis" von Stefan Steinhaus). Verbunden sind damit zwei Fragestellungen:

1) Eignet sich ein Mathematik-Programm als Grundlage für ein EA-, SOM-, Aktiv-Learning-System, d.h. können solche Systeme als Anwendung in der Programmiersprache des Mathematik-Programms geschrieben werden.

2) Eignet sich ein Mathematik-Programm als Grundlage für ein GP- bzw. allgemeiner für ein HP-(Heuristic-Programming)System (s.a. Software-Projekt SW02).

Evolvica
Als Beispiel dienen die EA-Programme, die Christian Jacob innerhalb Mathematica geschrieben hat, sowie insbesondere das Genetic Programming System Evolvica, das in der Programmiersprache von Mathematica geschrieben ist, und alle Funktionen nutzen kann, die im Mathematica-Kern enthalten sind, sowie alle Funktionen, die in den vielen Toolboxen zu Mathematica enthalten sind. D.h. alle diese Funktionen bilden Sprachelemente, die von einem GP-System genutzt werden können, was der besondere Vorteil dieser Betrachtung ist. Ein weiterer Vorteil ist die hochsprachliche, einfache Programmierung, wenn es darum geht, andere Heuristiken anstatt GP zu verwenden, um Programme automatisch zu erzeugen (s.a. Software-Projekt SW02).
Probleme mit kommerziellen Programmen
Im Gegensatz zu diesen Vorteilen steht einem Einsatz die Tatsache entgegen, dass Mathematica sowie eine grosse Anzahl von verfügbaren Toolboxen kommerzielle Produkte sind, sodass ein Szenario, in dem ein internet-basiertes, verteiltes System betrachtet wird, kaum durchführbar ist, wenn auf jedem Rechner des verteilten Systems ein Mathematica-Kern laufen soll, der Berechnungen durchführt. Die Fähigkeit, Mathematica-Programme zu kompilieren, verweist jedoch auf mögliche Lösungen, indem die komplexen Funktionen, die Teil eines automatisch erzeugten Programms sein sollen, zunächst kompiliert werden, und dann an verteilte GP-Clients verteilt werden. Mathematica oder ein anderes Mathematik-Programm wird somit während des Genetic-Programmings nicht mehr benötigt, da die lokalen GP-Systeme als Clients Programme erzeugen können, die auf die kompilierten, lokal vorliegenden Funktionen verweisen. Durch die lokale Ausführung der Programme können diese lokal evaluiert werden, und Individuen mit ihren Fitnesswerten können problemlos zwischen Populationen ausgetauscht werden, da alle GP-Clients lokal die gleichen kompilierten Funktionen besitzen.
Server-Strategie
Ein Szenario mit einer Online-Kompilierung ist ebenfalls möglich, doch aufgrund des hohen Aufwandes von Seiten des Servers ist dies problematisch. Bei einem solchen Szenario liegt ein Mathematica-Kern auf einem Server, und erzeugt Programm-Individuen innerhalb der Programmiersprache von Mathematica. Diese Programm-Individuen werden auf dem Server kompiliert, und der ausführbare Maschinencode wird an Clients versendet, die diesen evaluieren sollen. Da die Kompilierung selbst ein aufwendiger Optimierungsprozess ist, ist ein solches Szenario überhaupt nur dann in Erwägung zu ziehen, wenn der Server eine sehr grosse Rechenleistung besitzt, und wenn der Evaluierungsaufwand eines Individuums sehr gross ist. Sollte der Server ein Mehrprozessor-System sein, so ist dieses Szenario von der Lizenzpolitik des Herstellers des verwendeten, kommerziellen Mathematik-Programmes abhängig. Sollten Lizenzen pro Prozessor notwendig werden, so spricht dies gegen ein solches Szenario.
EA-Anwendungen in freien Programmen

Frei kopierbare Mathematik-Programme können demgegenüber für GP-Anwendungen direkt angewendet werden, indem ein GP-Client das Mathematik-Programm und die GP-Anwendung beinhaltet. Geht man von einer Population pro Client aus, so werden die Programm-Individuen lokal innerhalb des Mathematik-Programms erzeugt, evaluiert, selektiert und an andere Populationen z.B. über ein Blackboard versendet. Diese Mathematik-Programme können somit in einem Internet-Agenten gekapselt sein, die über ein Blackboard kommunizieren, wodurch eine Integration von Mathematik-Programmen in eine Java/Jini-Architektur ebenso denkbar wäre, wie andere Kommunikationsformen in einem allgemeinen Multiple-Agent-System.

Als Programm für symbolische Mathematik wäre beispielsweise MuPAD geeignet, während für numerische Mathematik Scilab für eine Kapselung potentiell geeignet wäre. MuPAD ist ausser für Windows frei kopierbar, jedoch nicht Public Domain, während Scilab frei kopierbar ist, und im Source-Code verfügbar ist.

Eignungsprüfungen

Die Aufgabe, die in diesem Zusammenhang besteht, ist zunächst die Eignungsprüfung von Mathematik-Programmen mit einer eigenen Programmiersprache bezüglich der Implementierung eines GP- bzw. HP-Systems als Anwendungsprogramm, das Funktionen des Mathematik-Programmes als Sprachkomponenten verwendet. Dabei sollen nicht nur General-Purpose-Programme betrachtet werden, sondern auch Programme, die spezielle mathematische Bereiche abdecken, insbesondere solche, die für Fragestellungen der theoretischen Physik eingesetzt werden. Es existieren unterschiedlichste GP-Systeme, die auf verschiedenen Datenstrukturen aufbauen, sodass sich für die Sprachkonstrukte, die in den jeweiligen Programmiersprachen der Mathematik-Programme vorliegen, adäquate Entsprechungen erzeugen lassen.

Das Gesamtkonzept kann somit in Einzelprobleme zerlegt werden, die sich im Rahmen einer Diplomarbeit bearbeiten lassen, wenn man von der Reimplementierung eines adäquaten Systems ausgeht, wie z.B.

- Genetic-Programming-System in MuPAD

- Genetic-Programming-System in Scilab

- Genetic-Programming-System in Reduce

Die Verwendung von frei kopierbaren bzw. kostengünstigen Mathematik-Programmen eröffnet insbesondere die Möglichkeit, Diplomarbeiten an Fakultäten mittel- und osteuropäischer Universitäten zu vergeben.

- - - - - - - -
Interface zwischen numerischem und symbolischen Mathematikprogrammen
Ein unabhängiges Teilprojekt bezieht sich auf die Erzeugung einer Infrastruktur zwischen verschiedenen Mathematikprogrammen. Z.B. besitzt das numerische Mathematikprogramm Scilab ein Interface zu dem symbolischen, kommerziellen Mathematikprogramm Maple. Im Rahmen der Nutzung nicht-kommerzieller Programme, und der Bildung von GP-Applikationen innerhalb dieser Programme, wäre es ratsam, ein Interface zwischen Scilab und einem nicht-kommerziellen wie MuPAD zu bilden. Die GP-Applikationen beider Programme könnten auf diese Weise kommunizieren, und eventuell applikationsübergreifende Individuen erzeugen, die Strukturen besitzen, die aus beiden Programmen stammen. Zur Evaluation wird jeweils das andere Programm aufgerufen.

 


Zum Seitenanfang


VI-ANEC | Über das Institut | Software-Projekte | Hardware-Projekte | Best-Paper-/Best-Program-Awards | Sponsoring | Dienste | Kontakt


www server concept design © 1999 by VI-ANEC

Dokument zuletzt geändert am 05.12.1999