Die zweitschönste Nebensache der Welt

Wie gesehen kann der AP127 noch nicht mit dem XML-Datentyp umgehen, er kennt ihn schlicht und ergreifend nicht.

Das bedeutet aber nicht, dass jedes SQL-Statement, in dem XML-Daten angefasst werden, zwangsläufig zu einem AP127-Fehler führt. Solange das Ergebnis einer Query keine Daten vom Typ XML (988) enthält, ist alles gut.

Hierzu ein Beispiel mit der Tabelle XMLCUSTOMER:

select c.cid from xmlcustomer c where xmlexists(''$i/customerinfo[name = "Kathy Smith"]' passing c.info as "i")

XMLEXISTS ist ein neues Prädikat. Es prüft, ob ein XQuery-Ausdruck ein nicht-leeres Ergebnis bringt. Im Ergebnis der Query selbst tauchen dagegen nur die Integer-Werte der Spalte CID auf.

Auch diese Query verleitet den AP127 nicht zu einer Fehlermeldung:

select X.* FROM XMLCUSTOMER C, XMLTable(''$cu/customerinfo'' PASSING C.INFO as "cu" COLUMNS "NAME" CHAR(20) PATH ''name'', "STREET" CHAR(20) PATH ''addr/street'', "CITY" CHAR(20) PATH ''addr/city'') AS X

Denn die Tabelle X enthält nur dem AP127 bekannte Datentypen. Dass in der Query irgendwo XML-Dokumente verarbeitet werden, bekommt er nicht mit. Gut so!

Nichtdestotrotz wäre es mehr als sinnvoll, den AP127 mit dem Datentyp 988 vertraut zu machen.

"Eine, der Erfahrungen, die ich hierbei machen konnte, besteht in der Erkenntnis, daß das Verständnis von APL höhere intellektuelle Anforderungen stellt als das Verständnis anderer Sprachen."

Das mein Wolfgang Janko, ein veritabler Professor und Buchautor (APL 1, APL 2/I, APL 2/II u.a.). Wenn er das so schreibt, dann muss das wohl stimmen. Also dürfen wir uns getrost als Hoch-Intelligenzler bezeichnen, wenn wir es verstehen mit APL Probleme zu lösen? APL als Messlatte für Intelligenz, gar als Komponente eines IQ-Tests?

Nein, darauf möchte ich mich nicht einlassen. Ich bin allerdings überzeugt, es hilft in Strukturen denken zu können. Ansonsten wird man die Stärken von APL nicht vollständig schätzen können und möglicherweise jede Schleife, die in Basic geschrieben werden muss auch in APL schreiben.

Jankos Erkenntnis stammt aus dem Jahre 1981 und war zu lesen in der Computerwoche als Teil einer Kritik an einen CW-Artikel. Passend der Titel: "Intellektuelle lösen Algorithmen mit APL", eine Aussage, die dem Ruf von APL und seinen Protagonisten sicher nicht zuträglich war.

Es ist nun fast 40 Jahre her, dass das erste mal ein "CLEAR WS" auf einem Rechner angelegt wurde. Jedes IBM-APL erinnert mit dem Pseudo-WS CLEANSPACE (was ist bloß falsch an diesem WS-Namen) an den genauen Zeitpunkt dieses Ereignisse:

)LOAD 1 CLEANSPACE
SAVED 1966-11-27 23.53.59 (GMT+1)

Nun treibt es mich schon seit Monaten um, warum jetzt unbedingt die 40. Wiederkehr dieses Tages gefeiert werden muss. Denn ich habe erst meinen 50. Geburtstag mit großem Brimborium begangen. Zugegebenermaßen habe ich den 30. und den 40. mehr beachtet als die Jahrestage dazwischen.

Rein zahlentechnisch ist die 40 nicht sehr imposant. Sie ist im Dezimalsystem so gut wie die 30, 20 oder 60. Wir dezimal denkenden Menschen (es gibt Menschen, die in anderen Stellenwertsystemen denken) legen ganz gesonderten Wert auf die 50 oder 25 und 75: ein halbes Jahrhundert, ein viertel oder dreiviertel Jahrhundert. Die 40 ist mal gerade ein zweikommafünftel Jahrhundert.

Warum also gerade im Falle von APL den 40. Geburtstag groß feiern? Haben wir Angst, dass wir den 50. nicht mehr erleben? Oder weil wir APLer Zahlen aus der Sicht eines Waschbären betrachten - im Oktalsystem, wegen der 8 Finger, vier an jeder Pfote? Hier sind 40 Dezimaljahre 50 Oktaljahre, also tatsächlich ein halbes Jahrhundert.

Nein, wir sind keine Waschbären. Die Antwort ist natürlich im Computer zu finden: Wir stellen für den Rechner Zahlen gerne und oft im Hexadezimalsystem dar, und da ist unsere dezimal 40 hexadezimal eben die 25, ein viertel Jahrhundert, ein Silberjubiläum.

Es gibt Leute, denen wäre das alles so oder so egal: Die würden erst das 42. Jubiläum feiern.

Beim Stöbern durch uralte CW-Artikel, die die drei Buchstaben "APL" in dieser Reihenfolge beinhalten, habe ich einen Lobgesang von IBM auf APL gefunden - aus dem Jahre 1980. Das passiert denen heute bestimmt nicht mehr. Hier die Höhepunkte:

"Das heutige IBM-Angebot setzt die Kendallsche Tradition (erheblich erweitert) fort; APL - A Programming Language - ist immer dabei."

Das waren noch Zeiten! Good old Big Blue.

"Das allgegenwärtige APL, einsetzbar auf /370-, 43XX- und 303X-Systemen, offeriert IBM als "klare Sprache"; denn "die Integration aller Benutzer innerhalb eines Unternehmens erfordert" eben eine solche."

In Sachen "klare Sprache" in Sinne von klarer, mathematischer Struktur bin ich da ganz auf Seiten der IBM von 1980. Für die IBM der Gegenwart ist Java die "klare Sprache". Welch ein Fortschritt: Tausende Programmierer, die Tonnen von buggy Spagetti-Code produzieren. Klar ist hier nur, dass diese Codemassen jeden Fortschritt in der Hardware kompensierten.

Meine alten APL-Funktionen performen inzwischen fast so schnell wie das Licht. Hier kann ich Ernte der Realisierung des "Moorschen Gesetzes" einfahren, nicht so bei Word und Konsorten (ich sollte hier DB2 explizit aus der Kritik heraus halten). APL ist kompakt, Java ist objektorientiert, C ist weder das eine noch da andere.

Weiter im Text mit Staunen:

Auf der Suche nach meinem ersten APL-Buch habe ich einige sehr alte CW-Artikel zu APL gefunden. Ende 1981, wahrscheinlich im November, lieh ich mir zur Vorbereitung auf meinen Job als Systemanalytiker "APL 1" von Wolfgang Janko in der UB Düsseldorf aus. Das Buch musste ich natürlich wieder zurückgeben, den gelesenen Stoff habe ich behalten.

Das Buch habe ich in der Zwischenzeit nicht mehr in der Hand gehabt. Nach 25 Jahren meine ich, dass es mir fehlt. Also googlete ich nach "Janko APL" und fand einen CW-Artikel aus dem Jahre 1982. APL und 1982, da war doch was? Tatsächlich tanzte in diesem Jahr der APL-Kongress in Heidelberg und Janko war der Vortänzer. In besagtem Artikel kamen also anlässlich dieses Ereignisses einige Mitglieder des Organisationskommitees zu Worte.

Und dabei kamen interessante Aussagen heraus. Ich zitiere aus dem CW-Artikel "APL als Sprache für Manager entdeckt", übrigens ein Titel, der zum Lästern geradezu auffordert.

"APL, benannt nach dem vor 20 Jahren erschienenen Buch "A Programming Language" von Kenneth E. Iverson, hat nach Überzeugung der Kongreßveranstalter Zukunft."

Das können wir heute nach 24 Jahren beurteilen. Ich bin überzeugt, dass APL immer noch eine Zukunft haben müsste, wenn die IT-Menschheit einigermaßen vernünftig strukturiert wäre.

Das habe ich nun davon, dass ich mich nicht an eine sinnvolle Empfehlung zur Benutzung von Windows gehalten habe. Hätte ich mich aber daran gehalten, wäre ich nicht auf dieses seltsame Verhalten von DB2 gestoßen.

Meinen vorherigen Rechner "Number9" habe ich ausschließlich den User "Administrator" benutzt. Dies habe ich inzwischen für meinen aktuellen Rechner geändert. Auf unseren Linux-Systemen arbeite ich schließlich auch nicht standardmäßig als "root". Number9 hat natürlich auch ein DB2, seit Kurzem sogar in zwei unterschiedlichen Versionen. Da ich mich normalerweise unter meiner Windows UserID auch bei DB2 anmelde, habe ich mich wohl nie explizit mit UserID und Passwort mit einer Datenbank verbunden ("connect to ...") - weder über das DB2-Befehlsfenster, noch über den AP127 mit APL2. Ich bin nun mal schreibfaul.

Nun geschah es aber letzte Woche, dass DB2 von mir UserID und Passwort haben wollte (da ich mich mit dem zweiten DB2-Exemplar als entfernte Instanz verbinden wollte). Der

connect to apl2lib9 user Administrator

im Befehlszeilenprozessor funktionierte klaglos. Aber der Connect über AP127 zickte: Nach

CTL127←'CONNECT' 'APL2LIB9' 'Administrator' PASSW

beschwert sich AP127 mit einem(1 0 0 1 162): "THE USERID ARGUMENT TO CONNECT MUST BE A CHARACTER VECTOR OF LENGTH 1 TO 8".

Ted Codd mag zwar Anfang der 90er den Begriff OLAP (Online Analytical Processing) kreiert haben, aber er hat damit nicht die mehrdimensionale Speicherung und Analyse von Daten erfunden.

Dies geschah lange bevor Codds meinte, die Computerwelt mit seinen komischen 12 OLAP-Regeln beglücken zu müssen.

1998 schrieb Mark Hammond in der PC Week unter dem Titel "It's not Greek to me":

OLAP has its roots in a multidimensional language called APL, developed in 1962, that used Greek symbols and ran on IBM mainframes.

Für einen APLer war und ist das Denken in und das Arbeiten mit multidimensionalen Strukturen selbstverständlich. Von daher haben wir den Hype um OLAP nie so recht verstanden. Wir hatten ja schon lange alles, was OLAP angeblich ausmacht, und noch vieles mehr.

Anbieter von OLAP-Software können noch viel von APL lernen. Nur die Speicherung von dünn besetzten Würfeln ist bei den meisten OLAP-Systemen effizienter gelöst.

APL+Win hat mit der Version 6.2 eine neue Grundfunktion spendiert bekommen: UNIQUE. Damit einher geht auch die Notwendigkeit für die Belegung eines Symbols. Das ist typisch für APL. Es ist nicht gerade überraschend, dass für UNIQUE "Cup" ∪ gewählt wurde.

Syntaktisch ist ∪x äquivalent zum Unique-Idiom:

((x⍳x)=⍳⍴x)/x

Also: rechtes Argument ist ein beliebiger Vektor. Das Ergebnis ist wiederum stets ein Vektor, der alle unterschiedlichen Element des rechten Arguments enthält in der Reihenfolge ihres ersten Auftretens.

Die Implementierung von UNIQUE scheint keine Performance-Vorteile im Vergleich zum Idiom zu bringen. Der Vorteil der Nutzung liegt also alleine in der bequemeren Schreibweise.

Ich halte das für ausreichend, um ∪ statt des Idioms zu nutzen.

Sowohl UNIQUE als auch das Idiom sind vergleichsweise sehr langsam für Floating Point Argumente. Das liegt wohl daran, dass hier jeweils zur Bestimmung von Gleichheit ⎕ct herangezogen werden muss.

Im Vergleich zur Darstellung von Umlauten in einem Grid ist die Situation bei Listviews komplexer. Das Wesentliche vorweg: Auch hier gibt es Unterschiede zwischen CSD 8 und CSD 7 (und früher).

Betrachten wir zuerst Schriftarten, die keine APL-Zeichen enthalten, also z.B. MS Shell Dlg, MS Sans Serif oder Tahoma. Sollten mit CSD 7 Umlaute auch als solche in einem Listview dargestellt werden, mussten sie vorher z.B. durch APL2_TO_WINDOWS umgesetzt werden. Mit CSD 8 sollte man das nicht tun, denn sie werden bereits ohne Umwandlung korrekt angezeigt.

Unicode-Fonts enthalten zwar APL-Zeichen, verhalten im Vergleich von CSD 7 und CSD 8 wie Schriftarten ohne APL-Zeichen.

Mag sein, dass der Computer nicht ausschließlich in den USA erfunden wurde, aber die EDV- bzw. IT-Standards wurden eben dort in den letzten Jahrzehnten gesetzt. So auch die Zeichensätze, seien es ASCII oder EBCD. Und was dort nicht bekannt war, floss eben nicht in die Definitionen ein.

Dazu gehören leider auch unsere Umlaute und das Eszet. Nach nun mehr als 30 Jahre Arbeit mit Computern befürchte ich, dass wir allgemein länderspezifische Sonderzeichen immer noch nicht im Griff haben (Unicode lässt grüßen). Das fällt diesmal beim Wechsel von APL2 CSD7 auf CSD 8 auf, zwar nur marginal, aber immerhin:

Die Darstellung der Umlaute in einem APL2-Grid war schon immer abhängig vom gewählten Zeichensatz. Sie wurden korrekt ausgegeben, soweit der Zeichensatz der Wahl z.B. "APL2 Image" war, bei anderen wurden Umlaute erst als solche angezeigt, wenn sie vorher z.B. durch APL2_TO_WINDOWS (aus 2 WINDOWS) umgewandelt wurden.

Dies gilt auch fast so für die CSD 8, aber nur fast: Den Unterschied macht die Schriftart MS Sans Serif. Das ist der Font, der verwendet wird, soweit kein spezieller Font spezifiziert wurde. Schickt man nun Umlaute vorher - wie bei früheren Releases nötig - durch APL_TO_WINDOWS, so werden im Grid irgendwelche Zeichen ausgegeben, aber keine Umlaute.

Das ist gar keine so eine schlechte Idee:

Nein, nicht das Anmelden einer Marke "Homologische Algebra" - so etwas tut man nicht. Aber Software zu diesem Gebiet zu entwickeln, das wäre schon eine Herausforderung. Aber leider hatte schon 1982 oder früher jemand diese Idee: J.O.Shallit, damals University of California, betrieb damals "Computational Simplicial Homolgy in APL" (APL82 Conference Proceedings). Warum er Homologie mit APL umsetzte, begründete er folgendermaßen:

"In many ways, APL is the ideal language to express algebraic concepts. First, its function-oriented structure applies naturally in algebraic systems. Second, its powerful array processing allows easy manipulation of matrices. Finally, APL's conciseness and power make development and testing easy"

Dem ist nur hinzuzufügen, dass das heute mit den APL-Implementierungen der 2.Generation mehr den je gilt. Ich kenne auch keine Programmiersprache, die diese Eigenschaften mit APL gemein hat. Java hat dies bestimmt nicht.

Unter uns gesagt, Shallits Aussagen sind nicht nur für algebraische Systeme gültig, sondern auch für viele andere Gebiete, wie z.B. der Versicherungsmathematik. Aber nicht weiter sagen!

Da hatte ich mich in den letzten Jahren meines Studiums mit Homologischer Algebra beschäftigt, um dann schon nach einigen Monaten außerhalb der Uni einen Artikel zu finden, der mein altes Lieblingsthema mit meinem damaligen neuen Lieblingsthema verband. Da fühlt man sich doch gleich zu Hause.

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!