Die zweitschönste Nebensache der Welt

Ich hätte ihn fast vergessen: den APL2 Keyboard Handler.

Ich kann mich noch erinnern wie David ihn auf einer GSE Tagung vorstellte. Ich glaube, das war in Augsburg. Enger Tagungsraum, ich kam zu spät und war unkonzentriert. In der Folge habe ich den Keyboard Handler einige male gestartet, konnte aber so recht nichts damit anfangen.

Der APL2 User's Guide widmet dem Handler einen kompletten Abschnitt (Seite 36f):

"The APL2 keyboard handler can also enable you to type APL characters in other applications. To enable APL input in other applications, either open the APL2 Keyboard Handler icon in the IBM APL2 folder or run the APL2KEY.EXE program. Then, select an APL font in the application in which you want to type APL characters."

Das funktioniert auf jeden Fall mit Excel und mit Word, aber leider nicht mit Powerpoint. Auch mein Mail-Client zickt mehr oder weniger. Dafür macht Notepad keine Probleme.

Das ist so nicht ganz korrekt. Es sollte heißen: Alles oder Ein. Ich weiß, Das ist kein Deutsch!

"Alles" meint Folgendes: Natürlich habe ich alle vorhandenen Lösungsfunktionen in einer Funktion verpackt, so dass ich mit einem Funktionsaufruf ein Sudoku lösen kann - soweit ich mit den implementierten Methoden komme:

RESULT SOLVE sudoku

SOLVE führt solange iterativ FILL, SCAN, ELIM u.a. aus, bis die Lösungsmatrix sich nicht mehr verändert. Ergänze ich SOLVE noch um ein Trial-and-Error, so löst SOLVE jedes Sudoku. Das zeigt mir dann aber nur, ob ein vorgegebenes Problem überhaupt lösbar ist, also ein gültiges Sudoku. Das interessiert mich aber nicht wirklich, dazu reicht schon eine Trial-and-Error Funktion.

So zeigt SOLVE wie weit ich mit den eingebauten Methoden komme. Mit eingeschalteter Erklärungsfunktion wird mir sogar Schritt für Schritt erläutert, wie sich der Lösung genähert wird.

Apropos "Schritt für Schritt" oder "Ein":

... ein Sudoku lösen: Ohne Versuch und Irrtum, nur durch logisches Kombinieren oder Ausschließen von Lösungen. So gehen menschliche Sudoku-Löser an die Sache, solange bis es mit diesen Methoden nicht weitergeht.

Nachdem ich meine Darstellung eines Sudokus bzw. seiner möglichen Lösungen im APL festgelegt hatte, habe ich verschiedene "logische" Lösungsmethoden implementiert. Nicht alle, aber die einfachsten und wichtigsten, da mit ihnen alle leichten, mittel- und die meisten schweren Sudokus lösbar sind. Die dazugehörigen Funktionen heißen FILL, SCAN, ELIM, ELIMB und PAIR.

Jede dieser Funktionen wendet eine spezifische Methode nacheinander entlang der Zeilen, der Spalten und Blöcke an. Dafür ist jeweils nur eine Implementierung nötig. Denn die Anwendung einer Methode auf die Zeilen eines Sudokus ist das gleiche wie die Anwendung der Methode auf die Spalten des zugehörigen transponierten Sudokus. Das gleiche gilt für Zeilen und Blöcke (wegen Transitivität dann auch für Spalten und Blöcke) .

Dafür war die Darstellung einer Sudoku-Lösung als logische Matrix vom Rang 5 gedacht.

So gefällt er mir ...

... mein Sudoku-Löser. Der, den ich nie schreiben wollte.

Es ist auch ok, wenn er - Stand heute - nicht alle Sudokus lösen kann. Leichte, mittelschwere und schwere scheinen kein Problem zu sein. Bei sehr schweren erhalte ich schon mal nur einen Zwischenstand.

Aber mein Sudoku-Löser soll mir beim Lösen von Sudokus helfen. Und das tut er auch: Wenn ich nicht weiterkomme, kann ich mir Tipps für eine weiterbringende Methode holen.

Aber nicht nur das: Mein Sudoku-Löser kann mir auch "erklären" was er Zug um Zug getan hat.

Es fehlen nun noch einige weitere "logische" Eliminierungsmethoden und die finale Lösungsmethode - Trial and Error. Letztere ist auch die, die der menschliche Löser anwenden muss, wenn er mit den "logischen" Methoden nicht mehr weiterkommt.

Gerüchte, alles Gerüchte.

Schon vor Jahren hörte ich, dass IBM Cognos kaufen will. Soll heißen, dass Cognos gerne von IBM gekauft würde.

Daraus ist bisher nichts geworden. Vielleicht demnächst in diesem Kino ...

Publik wurde vor einem Jahr, dass Microsoft SAP kaufen wollte. Hat nicht funktioniert. Gut so. Aber die Drohung besteht weiterhin. Dazu passt folgendes Gerücht, das Christiane mir gestern erzählte:

IBM will SAP kaufen. Das passt schon besser in meine "politische" Landschaft. Das ist gut für alle SAP Kunden mit einer Oracle-Datenbank. Die würden dann eine vernünftige Datenbank geradezu automatisch erhalten. Ferdinand for SAP President!

Ganz nebenher: SAP wäre ja auch mit dem Klammerbeutel gepudert, wenn sie nicht versuchen würden, ihre Kunden von den Oracle-Datenbanken weg zu bewegen.

Jetzt wird es lustig:

FJH hat Pylon gekauft (das ist noch nicht wirklich lustig), nur, damit FJH attraktiv für SAP ist. FJH, heißt es, würde gerne bei SAP unterkriechen. Bei SAPs desaströsen Erfahrungen im Versicherungsgeschäft keine schlechte Idee.

Mal sehen, was als nächstes passiert.

Ich bin ja kein Oracle-Experte. Ich habe nicht mal eine Oracle-Datenbank auf meinem Rechner installiert. Ich möchte dies diesem armen, unschuldigem Ding auch nicht zumuten.

Daher muss ich mich auf anderer Leute Erfahrungen verlassen. Auf Leute also, die es wissen müssen, da sie mit beiden Datenbanken - Oracle und DB2 - arbeiten.

Gestern traf ich so jemanden: Thomas Ruf. Ein alter Profi mit reichlich praktischer Erfahrung mit beiden Datenbanken.

Und der sagte, dass eine Anwendung, die er betreute, mit DB2 wesentlich besser performte als mit einer Oracle-Datenbank - um 80%. Eigentlich kaum zu glauben. So etwas sagt man nicht vor Publikum, wenn da überhaupt nichts dran ist.

Ludger hat schon vor ungefähr 10 Jahren ähnliche Erfahrungen gemacht, vielleicht nicht gerade in der Größenordnung von 80%.

Mast- und Schotenbruch für alle Oracle-Looser, äh, -User!

Ich habe mein Bestes getan, um Alan davon zu überzeugen, seine MySQL-Datenbank nach DB2 Express-C zu migrieren. Das hat auch fast geklappt, bis er fragte, ob DB2 Indizes auf BLOBs legen kann. Natürlich geht das nicht! Aber macht das überhaupt Sinn?

Hat Alan hier möglicherweise etwas falsch verstanden? Meinte er vielleicht, dass MySQL die Möglichkeit bietet in LOBs zu suchen?

Also mal sehen, was MySQL dazu sagt ...

Dabei stoße ich auf einen Link zu einem Migration Tool Kit. Das ist spannend! Für DB2 gibt es das ja auch.

Nur MySQL und DB2 scheinen sich geflissentlich zu ignorieren: Beide bieten Migrationshilfen vom MS-SQL Server oder von Oracle an, aber nicht von DB2 (oder Informix) bzw. MySQL.

Zumindest ist dies jeweils nicht dokumentiert. Denn mit Hilfe des DB2 Migration Toolkits wurde bereits testweise mindestens eine MySQL-Datenbank nach DB2 portiert. Das geht also, ist aber nur nicht dokumentiert.

Alans Frage beantwortet das alles nicht.

Ja, ich weiß: Ich treibe mit dieser Operation mehr als doppelt soviel Aufwand wie nötig.

Denn es ist S[i;;]=S[j;;] genau dann,wenn S[j;;]=S[i;;]. Und die Information, dass jede Spalte mit sich selbst identisch ist, ist auch nichts Neues. Die gewünschte Information steht also bereits oberhalb der Diagonalen der 9x9-Ergebnismatrix. Ist UTM0 die obere 9x9-Dreiecksmatrix ohne Diagolale, also

0 1 1 1 . . . 1
0 0 1 1 . . . 1
0 0 0 1 . . . 1
....
0 0 0 0 0 0 1
0 0 0 0 0 0 0

so enthält

UTM0^^⌿¨(⊂[2 3]S)∘.=(⊂[2 3]S)

bereits die gewünschten Informationen. Also mehr als 50% Luftoperationen!

Also warum die Vergleiche nicht nur für Indexpaare i,j mit i<j durchführen?