Die zweitschönste Nebensache der Welt

Bisher kam ich in diesem Blog ohne APL-Zeichen aus. Doch jetzt geht es nicht mehr ohne. Es ist schwer, Lösungen mit APL ohne APL-Zeichen darzustellen.

Sehr schlaue Menschen entschieden mal, die APL-Symbole in den Unicode-Zeichensatz aufzunehmen. Eine der wahren weisen Entscheidungen. Moderne Browser unterstützen Unicode, daher ist es kein Problem APL-Code mit Browsern darzustellen:

"⍎" ist z.B. die Kodierung für "Execute" (⍎).
"A←(1,⍴A)⍴A" wird als A←(1,⍴A)⍴A dargestellt.

Wie dies letztendlich aussieht, hängt von den in den Browser-Einstellungen definierten Zeichensätzen ab.

Durch Nutzung von style-Attributen oder Cascading Style Sheets (css) läßt sich die Darstellung von APL-Sequenzen im Browser noch verbessern, vor allem wenn die unter "font-family" angegebene Schriftart auf dem Rechner installiert ist. Ich werde hier Adrian Smiths "APL385 Unicode" Font eintragen. In der Regel wird es keine Probleme geben, APL-Zeichen auf Rechnern ohne diese Schriftart im Browser darzustellen.

Die Verwendung von "APL385 Unicode" in

"<pre style="font-family:APL385 Unicode;monospace;">A&#x2190;(1,&#x2374;A)&#x2374;A</pre>"

sieht dann so auch:

A←(1,⍴A)⍴A

Das Cairos-System gab mir bishjer Anlass zu drei Vorträgen:

Den Erste ging zum Thema "Fußball, Mathematik und APL" unter dem damals schon zum zweiten Male verwendeten Titel "Der Ball ist rund, ein Spiel dauert 10 GB". Ich habe nicht mal ein Copyright auf diese Formulierung. Wenn sie schützenswert wäre, hätte Christiane den Anspruch auf das geistige Eigentum. Das erste mal hat unter dieser Headline Dirk einen von mir erstellten Foliensatz zum Thema Data Minig im Sport auf einer IBM-Veranstaltung in Dortmund vorgetragen.

Doch zurück zu APL und Fußball:

Ende 2003 bekam ich von Marcus simulierte Positionsdaten über die 10 Sekunden vor und während des ominösen Wembley-Tors. Das waren ca. 20.000 3D-Koordinaten. Mit meinen APL-Baukasten und ein wenig Mathematik konnte ich daraus die Spielzüge als einen Satz von Polynomen reproduzieren. Das war einfach, zu einfach, da es keine real-life Daten waren. Mit echten Daten aus dem Cairos-System hätte ich schon mehr Probleme gehabt. Damals war das System aber noch nicht so weit.

So war ich mit Hilfe von Taylor-Reihen schnell erfolgreich. Mit APL und Grundkenntnissen in Analysis machte das auch noch Spaß. Ich habe natürlich versucht, das alles per Präsentation auf einem GSE-APL Treffen rüberzubringen, also quasi zu Hause und im Trikot von Stefan Reuter.

Meine Erkenntnisse und Ergebnisse von damals konnte ich seitdem nicht mehr anwenden. Was bleibt ist ein Satz analytischer APL-Funktionen und ...

der Beweis, dass der Ball nicht hinter der Linie war!

Was wollen wir also erzählen?

Für Christian liegt das auf der Hand:

Als erstes muss das System beschrieben werden mit seinen Besonderheiten und Vorteilen vor allem gegenüber RFID- und WLAN-basierten Systemen. Die Lokalisierungsgenauigkeit des Cairos-Systems wird von diesen anderen Ansätzen bei weitem nicht erreicht.

Und dann wird als die spannendste Anwendung der Cairos-Technologie das Tracking eines Fußballs während des Spiels vorgestellt. Um das hier klar zu machen: Gestern Abend hätte es der deutschen Mannschaft nicht geholfen, wenn Ball und Spieler getrackt worden wären.

Ich hoffe Christian wird einige Beispiele von Daten und Analysen vorführen, die bei der U17-WM in Peru gesammelt wurden.

Zum Abschluß seines Parts will Christian noch einen Ausblick auf Lokalisierungsmöglichkeiten, also Einsatz des Cairos-Systems, in anderen Bereichen geben. Nicht nur Football statt Soccer, sondern auch außerhalb des Sports.

Mir bleibt danach der Blick mit der Lupe auf das was ich vor einem Jahr in Düsseldorf bei der GSE-APL-Tagung erzählt habe. Und das hat mit meinen Lieblingsbeschäftigungen zu tun: Mathematik und APL.

Das wäre dann also ...

Das war mein Wunsch letztes Jahr, der als Requirement in die Liste der GSE-AG APL aufgenommen wurde. Keine Ahnung, wie die anderen Teilnehmer votiert haben. Trotzdem sollte ich jetzt mal genauer formulieren, was ich eigentlich meine. David hatte mir dazu schon ein oder zwei Fragen gestellt.

Leider habe ich sie nicht per E-Mail bekommen. Dort finde ich: "Printing grids would be nice, but it would be a lot of work" und weiter "If they need it immediately, I suggest you build something for them." Das habe ich auch getan mit meiner Excel-Schnittstelle:

Mit den XL_-Funktionen baue ich aus dem APL2 heraus im Excel das Grid noch einmal auf. Das Excel-Grid hat aber keine Verbindung mehr zum APL2, ist also komplett selbständig. Nun kann ich die Druckfunktion mit all ihren Einstellmöglichkeiten nutzen, um das Grid zu drucken.

Dies kann aber nur ein Workaround sein. Schöner wäre eine Lösung, die den APL145 um die Möglichkeit erweitert, ein aktives AP145-Grid zu speichern mit der Möglichkeit, den einen oder anderen Parameter hierzu zu setzen.

Letzteres ist also zu formulieren und zwar in Englisch ...

Liebes Tagebuch,

auch dies sollst du wissen: Der Vortrag, den ich vor einem Jahr über das Cairos-System, nach gelagerte Aufgaben und die Modellierung einer mathematischen Lösung mit APL2 in Düsseldorf gehalten habe, wurde inzwischen zweimal weitergereicht - dank Bernd und Dieter. Als Coreferent habe ich Christian Holzer gewonnen, es gibt keinen Besseren zu diesem Thema.

Hier nun der Abstrakt dazu:

Nun hält die Informationstechnologie Einzug in des Deutschen liebsten Hobbys: den Fußball. Mit Hilfe eines Tracking-Systems sollen in Zukunft Wembley-Tore verhindert werden. Diese Idee war der Start der Cairos AG, die sich zum Ziel gemacht hat, Entscheidungen durch genaueste Lokalisierung von Objekten zu ermöglichen und abzusichern.

Trotz einer extrem hohen Frequenz der Positionsmeldungen durch das Cairos-System erfordert es noch weitere Schritte, die Lage des „getrackten“ Objekts zu interpretieren. Am Beispiel Fußball bedeutet das, letztendlich zu entscheiden, ob der Ball sich im Tor, im Toraus, im Seitenaus oder noch im Spielfeld befindet. Mit Hilfe der Positionen der Spieler werden sich in Zukunft damit detaillierte Spielanalysen erstellen lassen.

Anhand des Einsatzes im Fußball wird das Cairos-System vorgestellt. Es wird ein weiterer Ausblick auf Anwendungen des Systems in anderen Bereichen gegeben.

Die Cairos technologies AG erhielt den diesjährigen Innovationspreis der Deutschen Wirtschaft.

Warum genestete Strukturen nutzen, die es erst mit APL Systemen der 2.Generation gibt, wenn auch "einfach" mit flachen Strukturen geht:

Ein Sudoku besteht doch aus 9 3x3-Blöcken, die als 3x3-Matrix angeordnet sind. Die Regeln des Rätsels bedeuten zusätzlich, dass die Bedeutung von Zeilen, Spalten und Blöcke jeweils austauschbar sind. Diese Symmetrie-Eigenschaft eines Sudokus ist hervorragend durch eine 3x3x3x3 Struktur darstellbar:

[1]  s_apl←3 3 3 3⍴Sudoku

Eine aus oben genannten Symmetriegründen gleichwertige Variante ist:

[2]  s_apl←1 3 2 4⍉3 3 3 3⍴Sudoku

In der ersten Darstellung [1] erhalte ich die 6.Zeile des 9x9 Sudokus als 3x3 Matrix mit s_apl[2;3;;], in Darstellung [2] dagegen mit s_apl[2;;3;]. So oder so bleibt die Struktur einer Sudoku-Zeile als Tripel aus jeweils 3 Werten erhalten. Das gleiche gilt für Spalten und trivialerweise für Blöcke.

Zeilen, Spalten und Blöcke eines Sudokus haben also die gleiche Darstellung, anders als in einem 9x9 Sudoku.

Hier der von mir am häufigsten gelesene Blog (warum nur?). Vorsicht: Hat nicht mit APL zu tun:

Wohnzimmerhostblogger

Diese Blogs habe ich gerade gefunden. Hier wird aber wohl auch nichts zu APL geschrieben werden. Aber zu Datenbanken und verwandte Software:

information on demand blogs

Da werde ich wohl regelmäßig rein sehen.

Vor einigen Wochen sah ich dann einen APL basierten Sudoku-Löser in Aktion - unter APL+Win und mit einem kompletten GUI sowie einer Erklärungskomponente. Das Vorbild für diese Anwendung ist Peter Wake's "Sudoku Solver by Logic". Soweit ich das sehen konnte beinhaltet die APL+Win Implementierung von Peter Majewski alle hier vorgestellten Lösungsalgorithmen einschließlich der Bewertungsfunktion für die Härte eines Sudokus.

Solch ein komplettes GUI für einen Sudoku-Löser zu erstellen ist schon sehr viel Aufwand - selbst mit APL+Win. Noch ein Grund nicht die Zeit zu verschwenden mit der Wiedererfindung des Rads.

Aber wie stellt man mit APL ein Sudoku bzw. eine Sudoku-Lösungsmatrix dar? Peter M. macht dies als 3x3-Matrix mit Elementen aus 3x3-Matrizen. Die Letzteren wiederum enthalten im Falle der Lösungsmatrix einen Vektor mit allen möglichen Lösungen - letztendlich also eine Matrix mit Tiefe 3.

Dagegen ist natürlich nichts zu sagen.

Damit ist es einfach auf "Blöcke" direkt zuzugreifen. So ist die Struktur eben "designt". Es ist aber nicht ganz so "straight forward" einzelne Zeilen oder Spalten einer Sudoku-Matrix zu bearbeiten. Da stellt die Tiefe der Struktur schon ein Hindernis dar.

Wie könnte also eine Alternative aussehen?

Trotz dieser prinzipiellen Ablehnung einen Sudoku-Löser zu implementieren, hatte ich bereits im Herbst letzten Jahres rein zu Demonstrationszwecken den trivialsten Algorithmus als "erste Hilfe" mit APL2 realisiert:





Untersuche alle möglichen Lösungen für jede Zelle. Soweit nur eine Lösung übrig bleibt, schreibe diese ins Feld.

Jede Zelle eines Sudokus ist hier ein Element in einer 9x9 Matrix. Die zugehörige Lösungsmatrix enthält dann in jedem der 9x9 Elemente einen Vektor mit allen möglichen Lösungen. Der erste, offensichtliche Algorithmus löscht aus jeder Zelle die Lösungen, die bereits in den Zellen der jeweils zugehörigen Zeile, Spalte und des zugehörigen Blocks als endgültige Lösung eingetragen wurden.

Das war einfach und mal eben in 5 Minuten nieder zuschreiben. Missbraucht habe ich dies für eine Demonstration, wie APL2 und Excel vorwärts und rückwärts miteinander kommunizieren können:

Hinter dem Knopf "erste Hilfe" liegt ein VB-Sub, die in einen APL2-Interpreter startet unddort eine APL2-Funktion ausführt, die wiederum das Sudoku-Grid ausliest, eine Lösungsmatrix erstellt, diese wie beschreiben reduziert und letztendlich nachschaut, welche Matrixelemente nur einen Lösungsvorschlag enthalten. Diese Felder werden dann vom APL2 aus im Excel-Grid rot markiert.

Ja, auch mich hat vor Langem die Sudoku-Sucht erwischt:

Zeitweise war die Lösung von Sudokus meine einzige Freizeitbeschäftigung. Zeitschriften, Bücher, CDs oder DVDs blieben links liegen. Natürlich war einer meiner ersten Gedanken, als ich die ersten Sudokus versuchte zu lösen, dies den Computer machen zu lassen - mit "Brute Force" oder mit intelligenteren Methoden.

Aber Sudoku-Löser gibt gibt es im Internet, ich weiß nicht wie viele, aber auf jeden Fall mehr als einen. Warum sollte ich also zu der wahrscheinlich großen Anzahl noch einen hinzufügen?

Möglicherweise wäre meiner einzigartig, da er in APL geschrieben wäre. Aber nicht mal das wäre der Fall gewesen.

Es gab da noch einen weiteren Grund, keinen eigenen Löser zu schreiben: Es macht Spaß, ein Sudoku selbst zu lösen. Dagegen finde ich es reiste Zeitverschwendung, ein Sudoku dem Computer zur Lösung zu übergeben. Das ist mühsam und bringt keinen Lustgewinn.

In comp.lang.apl fagte Don Kelly: " ... doesn't that take the purpose out of doing sudoku?" Dies war auch mein Grund, mich monatelang der Herausforderung eines eigenen Sudoku-Lösers zu entziehen.

Dies ist seit einigen Wochen nicht mehr der Fall. Warum? Dazu später ...

Da APL2-Entwickler nun ohne Kosten DB2 für APL-Anwendungen verwenden können, wird das Thema Datenbanken für uns immer interessanten. Und das noch mehr, wenn es sich nicht nur um relationales Datenbanken handelt, die auch noch XML "können".

Ich habe letzte Woche an einer Veranstaltung teilgenommen, in der die kommende Version von DB2 - DB2 Viper - vorgestellt wurde. Hier aus meiner Sicht die Highlights:

DB2 Viper ist eine hybride Datenbank. Sie verarbeitet Daten nicht nur in Tabellen nach dem relationalen Modell, sondern auch hierarchisch mit XML beschriebene Daten. Dazu gibt es einen neuen Datentyp XML, d.h. ich kann in Tabellen Spalten anlegen, deren Elemente XML-Daten enthalten.

In Gegensatz zu anderen Datenbanksystemen, die XML-Dokumente speichern können (Oracle, MS-SQL oder DB2 8.x), werden die Daten nicht als langer, unstrukturierten String als CLOB gespeichert, sondern bereits "geparst" als hierarchisch strukturiertes Objekt. Das bringt gravierende Vorteile für die Verarbeitung sowie die Performance.

Neben SQL ist nun auch XQUERY als zweite standardisierte Zugriffssprache implementiert. Mehr noch: Ich kann mit SQL auf XML-Daten zugreifen und umgekehrt mit XQUERY auch relationale Daten selektieren.

Ich werde also meine Java-, Windows- oder APL-XML-Parser beiseite legen und XML-Dokumente gleich in der Datenbank zu speichern. Das bedeutet einmal Parsen beim Speichern und nie mehr Parsen beim Lesen und Weiterverarbeiten.

Für Leute, die mit APL2 arbeiten geht das dann alles mit dem AP127. Nancy muss dann AP127 Refenence Manual umschreiben. Der Titel kann dann eigentlich nicht mehr nur "Using SQL" heißen. Es könnte dann mit "Using SQL and XQUERY" betitelt werden.

Im Dezember habe ich damit begonnen, alle meine APL2-Elaborate zu katalogisieren. Was und wie ist schon mehr als ein Thema für sich. Die Katalogtabellen habe ich anfangs in AP12-Dateien gespeichert. Da eine dieser Tabellen sehr groß war, waren die Zugriffszeiten entsprechend mit Wartezeit versehen.

Spaßeshalber habe ich den Katalog nach DB2 migriert. Das machte für mich Sinn, da ich dieses System bereits installiert hatte und APL2 mit dem AP127 eine "native" Schnittstelle zu DB2 besitzt. Die Arbeit hat sich gelohnt:

Die Zugriffszeit vor allen für Queries sind erheblich kürzer!

So kann ich den Katalog vernünftig einsetzen.

Schade ist nur, dass nicht jeder mit APL2 auch DB2 bekommt. DB2 kostet (wie auch APL2). Aber Rettung naht in Gestalt von

DB2 Express-C,

einer kostenlosen, voll-funktionsfähigen Version für Software-Entwickler (und das sind wir APLer doch alle). Runter laden, installieren und mit dem AP127 nutzen. Es ist jetzt so einfach, Daten mit APL2 relational zu speichern.

Es geht aber noch einfacher: DB2 Express-C ist kostenlos. Es sollte doch möglich sein, damit ein Paket mit APL2 zu schnüren. Die Frage ist nur, ob IBM (wer auch immer) da mitmacht.

Liebes Tagebuch ...

Nein, ich habe und hatte noch nie ein Tagebuch. Einige Monate missbrauchte ich einen kleinen grünen Kalender, um meine Gedanke zu Gott und die Welt nieder zuschreiben.

Hier habe ich nichts dergleichen vor!

Dies soll der Platz sein, um über eine meiner Lieblingsbeschäftigungen zu schreiben: mit APL meinen Rechner zu quälen, mit APL ihm schnell und präzise meinen Willen aufzuzwingen.

Ich sage es gleich: Das klappt seit Jahrzehnten hervorragend. Besser als mit Cobol, Fortran, VB oder Java (oder womit ich das sonst noch versucht habe).

Unsere Welt steht auf dem soliden Fundament der Mathematik. Mit Mathematik lässt sich alles beschreiben, was uns bewegt bzw. was sich um uns bewegt. APL ist eine "mathematische" Programmiersprache. Ergo: mit APL lässt sich die Welt besser beschreiben, als mit Programmiersprachen, die nicht auf mathematische Konzepte zurückgreifen.

Das war einfach und kurz. Wenn es polemisch klingt, war dies beabsichtigt.

Mit APL einen Computer zähmen macht Spaß. Darum soll es mir hier gehen.