Die zweitschönste Nebensache der Welt

Die meisten Abweichungen zwischen APL2 Versionen für den Mainframe und für Workstations führen bei Ausführung auf einer Workstation umgehend zu einem Fehler. Bei selektiven Zuweisungen wäre das z.B. ein SYNTAX ERROR. So ärgerlich das auch sein mag - vor allem, wenn sie zu Hunderten auftauchen - man kann die Inkompatibilität stante pede beheben. Die Diagnose liegt auf Hand, mit der Behandlung kann sofort begonnen werden.

Leider ist dies nicht immer der Fall. Die fehlende Füllfunktion für den Each-Operator ("No fill function is implemented for the Each operator") muss nicht zum sofortigen Abbruch der betroffenen Anweisung führen. Die Auswirkungen der Inkompatibilität können auch erst viel später in den unendlichen Tiefen einer komplexen Anwendung auftreten.

So geschehen mit

⍕¨NUM_ARRAY

Wie häufig ist das rechte Argument von Format hier numerisch, im vorliegenden Fall allerdings auch leer. Das Ergebnis ist natürlich (wegen "Each") wiederum eine leere Struktur, aber leider eine numerische und keine alphanumerische, wie vernünftigerweise zu erwarten wäre - und wie es APL2 Mainframe auch vorsieht.

Nicht ganz so lange kann der Test auf Identität jeweils zweier aufeinanderfolgender Zeichenketten in einem Vektor aus 1 Million solcher Elemente dauern. Allerding nur auf dem Mainframe und mit "N-wise Reduce":

2≡/VEC

So harmlos dieser Ausdruck auch aussieht, er hat es in sich. Für den vorliegenden Fall langer Vektoren VEC mit relativ kurzen Zeichenketten (z.B. mit Länge 10) als Elemente habe ich nicht die Geduld gehabt ein Ergebnis abzuwarten. Denn selbst eine Schlewife, in deraufeinanderfolgende Vektorelemente vergleichen werden, wäre schon lange mit dem Thema durch gewesen. Erst rech natürlich die typische APL-Lösung ohne N-wise Reduce, selbst bei mehr als 1 Million zu vergleichender Objekte.

Später habe ich erfahren, das dieser Ausdruck mit den Daten wie hier beschrieben auf einem IBM Mainframe nach ca. 38 Stunden mit dem Ergebnis rausrückte. Für einen heutigen Großrechner eine halbe Ewigkeit.

Ich hatte von Anfang an ein gute Gefühl bei REPLACEX, eine der wichtigen Neuerungen des APL2 Service Level 11 vom November letzten Jahres. Im ICE von Hamburg nach Berlin hatte ich vor der GSE Herbsttagung 2007 Gelegenheit, REPLACEX ein wenig zu testen. Die Ergebnisse des Vergleichs mit REPLACEV, einer Funktion aus 1 UTILITY, mit verschieden langen Vektoren bzw. Teilvektoren waren überragend. Je länger die Zeichenkette, in der die Ersetzungen vorgenommen wurden, desto größer wurde der Unterschied zugunsten von REPLACEX.

REPLACEX funktionierte sogar noch, als REPLACEV mit WS FULL endgültig aufgeben musste. Dabei ist REPLACEV keine schlechte APL2-Variante für das Ersetzen der Vorkommen einer Zeichenkette durch eine beliebige andere.

Dies waren Versuche außerhalb jeglicher ernsthafter Anwendungen. Tatsächlich gehört das Ersetzen von Teilstrukturen durch Strukturen mit unterschiedlicher Dimension nicht zu den Stärken von APL, nicht nur in Sachen Performance. Das ist anders bei jeweils gleicher Größe. Der einfachste Fall, der im wirklichen Leben auch oft vorkommt, ist das Ersetzen von Dezimalpunkten durch Kommata und umgekehrt.

Ich vergaß ...

Wie bringe ich nun Workstation APL2 dazu, mit dem Ausdruck 3↑¨⍳N das zu tun, was die APL-Welt auch für N=0 erwartet?

Ganz ohne Änderung geht das natürlich nicht. Aber glücklicherweise ist ken "if N=0 then ... else ..." nötig, ich brauche nicht einmal eine neue Zeile. Mit APL ist vieles einfacher, als mit (fast) allen Programmiersprachen der uns bekannten Welt.

Es auch hier so, wie mit vielen Dingen in der Mathematik: Man nehme etwas hinzu, so dass man sich auf bekannten Grund bewegt, tue das, was man nicht lassen kann, und werfe abschließend Überflüssiges wieder weg.

Konkret in unserem Fall: 1↓3↑¨0,⍳N, wobei nun das Ergebnis für N=0 ein Leervektor vom richtigen Typ ist.

Hat man keinen Mainframe mit APL2 zur Hand, kann man sich eine konforme Implementierung bei APL+Win ansehen.

Die Liste der dokumentierten Abweichungen zwischen den APL2-Implementierungen auf dem Mainframe und für Workstations ist glücklicherweise recht kurz. Viele der hier dokumentierten Inkompatibiltäten haben mich bisher noch nicht tangiert. Andere haben es aber in sich und sollten so bald wie möglich aus der Dokumentation verschwinden, so wie auch folgende "Deviation".

Gestern hat mich wieder mal "No fill function is implemented for the Each operator" erwischt, besser gesagt eine Zeile eines vom Mainframe auf einen PC migrierte Funktion. Das Symptom war ein LENGTH ERROR, der Grund war die falsche Behandlung der Anwendung einer Funktion samt Each-Operator auf einen numerischen Leervektor.

Gemäß der reinen Lehre sollte 3↑¨⍳0 einen Leervektor aus dreielementigen numerischen Vektoren ergeben, oder anders ausgedrückt 0⍴⊂3⍴0. Das ist klar, wenn man N in 3↑¨⍳N sukzessive verringert. Stets erhält man einen Vektor der Länge N mit dreielementigen numerischen Vektoren als Elemente. Im Falle N=0 wählt APL2 für Letzteres den Prototyp ↑0⍴3↑¨⍳N, also 3⍴0.

Ich habe mich ja schon an den SYTNAX ERROR bei selektiven Zuweisungen der Form (R/M[;I])←V und aller möglichen Varianten gewöhnt. Für das Mainfame APL2 ist dies ein absolut gültiger Versuch, Werte in "M" zu verändern.

Das Workstation APL2 spielt da leider nicht mit. Glücklicherweise akzeptiert es aber die Indexfunktion anstelle der Indexierung mit den eckigen Klammern. So können vom Mainframe kommende selektive Zuweisungen dieser Art schnell ersetzt werden.

Das wird allerdings ein wenig nervig, wenn diese Syntax-Fehler kein Ende nehmen. Bei der hier vorliegen Inkompatibilität handelt es sich wohl um die am häufigsten vorkommende.

Deshalb, und weil es sich bei obiger Zuweisung mit den eckigen Klammern um eine elegante, gut zu lesende Schreibweise handelt, ist es mehr als wünschenswert, dass diese Abweichung des Workstation APL2 von Mainframe Standard endlich beseitigt wird.

Bekannterweise gibt es zwischen APL2 für den Mainframe und Workstation APL2 einige Unterschiede. Es sind nicht viele, aber bei größeren Anwendungen können sie die direkte Ausführbarkeit nach einer Portierung auf den PC ernsthaft behindern.

Diese dokumentierten Abweichungen betreffen im Wesentlichen die Sprache, wie sie in der APL2 Language Reference beschrieben ist. Schnittstellen wohin auch immer und sonstige APL2-Vorrichtungen unterliegen von vornherein keinem Kompatibilitätszwang.

Dazu gehören offensichtlich auch die "Supplied Routines", mitgelieferte assoziierbare Funktionen. Selbst Namensgleichheit bedeutet nicht automatisch Gleichheit in der Funktionsweise. Recht drastisch macht das CTN deutlich: