Die zweitschönste Nebensache der Welt

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.