Die zweitschönste Nebensache der Welt

... war die Idee UNIQUE zur APL-Grundfunktion zu erheben. Dies war schon im APL2 IUP der Fall. Aber nicht nur dort:

Vor mehr als einem Jahr, mit Version 6.2, wurde der Sprachumfang von APL-Win um eine Unique-Funktion erweitert. Ich fand das und finde das immer noch nachahmenswürdig.

Beide APL implementieren ein "Unique", die jeweiligen Funktionen unterscheiden sich allerdings in einem wesentlichen Punkt:

Das Ergebnis des APL2 IUP "Unique" ist eine boolesche Maske, mit der das jeweils erste Auftreten der unterschiedlichen Elemente einer APL-Struktur markiert wird. Mit der hiermit definierten Funktion ∩ gilt dann für Vektoren x

(∩x) ≡ (x⍳x)=⍳⍴x

Das Ergebnis des APL+Win "Unique" enthält die verschiedene Elemente eines Vektor jeweils einmal in der Reihenfolge ihres Auftretens im vorgegebenen Vektor, also

(∪x) ≡ ((x⍳x)=⍳⍴x)/x

... mir etwas von IBM zu Weihnachten hätte wünschen dürfen (mit ernsthafter Aussicht auf Erfüllung), hätte ich sicher "Unique" als APL2-Grundfunktion auf dem Wunschzettel notiert. Ich bin der festen Überzeugung, dass das gleichnamige Idiom ein eigenes Symbol verdient hätte - nicht nur, weil ich mein ∆UNIQUE so häufig einsetze.

Allerdings darf ich diese Idee nicht mein eigen nennen:

Es war einmal das APL2 "Installed User Program", sozusagen die APL2 Version 0.5, ein voll funktionsfähiges APL2 für den Mainframe der frühen 80er, mit dem IBM die Akzeptanz der vielen Neuerungen gegenüber dem guten, alten VSAPL durch den geneigten APL-Kunden testen wollte. Dieses APL2 IUP realisierte "Unique" als monadische Grundfunktion mit dem Symbol ∩. Unter Shift-C ist dieses Zeichen heute noch mit gängigen APL2-Tastaturen erreichbar, aber leider nahezu nutzlos.

Ich finde, diesem armen, vergessenen Symbol sollte wieder Leben eingehaucht werden!

Auf welche Weise, lässt sich im APL2 IUP Language Manual nachlesen (gut, wenn man es im Regal stehen hat):

Um aus einer Liste beliebiger Elemente alle unterschiedlichen zu ermitteln gibt es seit APL-Gedenken das Unique-Idiom: VauiotaVauistgleichiotarhovaucompressvau (ohne explizite Nennung der Klammern). Seit APL2 können damit auch z.B. aus einer Liste von Namen der jeweils zuerst auftretende extrahiert werden.

Nun gibt es zu diesem Idiom mindestens eine Alternative: Sortiere alle Elemente des Vektors, untersuche paarweise jeweils aufeinanderfolgende Elemente auf Ungleichheit und reduzierte mit dem Ergebnis die ursprüngliche Liste. Angewandt auf Listen von Zeichenkette hielt ich diese Schreibweise in Sachen Performance für konkurrenzfähig zu UNIQUE - allerdings nur auf dem PC.

Denn auf dem Mainframe wird UNIQUE als Idiom erkannt und als Ganzes ausgeführt. Klar, dass dies deutliche Vorteile gegenüber Alternativen ergibt, dafür gibt es die Idiomerkennung schließlich.

Soweit ich weiß, gibt es sie nicht auf der Workstation Plattform. Also habe ich mal UNIQUE gegen die beschriebene Alternative gemessen und war überrascht:

Das Zeichnen von Niveaulinien sind nur eine Möglichkeit, den Graphen einer reellen Funktion in zwei Veränderlichen zu visualisieren. Beeindruckender, aber schwieriger zu erstellen, sind hierfür Oberflächendiagramme. Auch diese sind mit Graphpak einfach und schnell zu erstellen, allerdings nicht ganz so einfach wie zweidimensionale Plotts.

SURFACE heißt der Graphpak-Retter in der Not, sich dreidimensionale Graphen zu veranschaulichen:

'' SURFACE(0 TO 1,0.01)∘.F 0 TO 1,0.01

Ein wenig mehr Arbeit als für das Niveaulinien-Diagramm muss man in die Beschriftung der Achsen investieren:

50 100 SLBLX 0.5 1

50 100 SLBLY⌽0 0.5

Schön wäre es an dieser Stelle, ein wenig Interaktivität einführen zu können: Klick auf das Diagramm, um es dann per Ziehen mit der Maus um eine beliebige Achse zu drehen. Betrachtet man die Geschichte der Entwicklung von Graphpak, versteht man, warum dies wohl ein Traum bleiben wird.

Werden mehr als einmal Niveaulinien für Funktionen erstellt, empfiehlt sich die beschriebene Sequenz von APL2-Anweisungen in einem Operator zu verewigen. Als Operand dient die zu plottende Funktion, in der Regel also eine dyadische Funktion mit numerischen Argumenten und numerischem explizitem Ergebnis.

Damit hätten wir folgende Anweisungen zum Zeichnen der Linien für die Höhen c der Funktion f: x (c NIVEAU f) y oder (c NIVEAU f) x y oder (c NIVEAU f) x für x=y.

Im Operator selbst stecken neben Zeilen zum Verständnis der Argumente der abgeleiteten Funktion nur noch die bereits beschiebenen Statements für die Konturen und der beschrifteten Achsen.

Das vereinfacht die Erstellung dieser Höhenlinien doch erheblich:

c←0.02 0.04 0.06 0.08 0.1 0.12 0.140625

(c NIVEAU f) 0 TO 1, 0.01  

 

Allerdings sind diese zwei Zeilen nicht vollständig für die Linien in nebenstehendem Diagramm verantwortlich. Mit SPLOT habe ich noch die beiden blauen Linien eingezeichnet. SPLOT ist PLOT mit linkem Argument, und dies ist in diesem Fall unverzichtbar:

Einfache Liniendiagramme, die Erstellung von Graphen für Funktionen in einer reellen Variablen, sind mit Graphpak mehr als trivial. Ein oder zwei Zeilen, und schon sehe ich den Funktionsverlauf, so kompliziert die Funktion auch sein mag.

Die Darstellung von Funktionsfolgen ist kaum schwieriger:

x←¯10 to 10,0.1

PLOT x,⊃[1](⍳n)s¨⊂x

Das ist alles.

Bis hier braucht man kein Handbuch, für das Folgende ist die Konsultation des Graphpak Users's zu empfehlen: Der Visualisierung von reellen Funktionen in zwei Veränderlichen auf dem ebenen Bildschirm.

Da wäre als erste Darstellungsform das Höhenlinien- oder Niveaudiagramm, in Software gegossen als Graphpak-Funktion CONTOUR. Um die Konturen auf den Höhen -2,-1,0,1,2 für die Funktion f(x,y) zu zeichnen, gehe man wie folgt vor:

x←y←¯5 to 5,0.1

m←(x BY y) OF x∘.f y

m[1;1]←1

¯2 ¯1 0 1 2 CONTOUR m

AXES

LABEL

Zwei Nieveaulinien "fehlen". Warum wohl?

Mit einer anderen (mathematischen) Funktion kommen auch diese zum Zuge. Mit ein wenig mehr Arbeit lassen sich die Höhenlinien unterschiedlich einfärben: Variable pa setzen und CONTOUR mit jeweils einem Niveau im linken Argument aufrufen. Keine Sorge, dass passt solange svp unverändert bleibt.

Für welches f(x,y) sind das wohl die Niveaulinien?

Tatsächlich wurde auch schon vor mehr als 30 Jahren richtig gute Software gemacht. Ausnahmsweise meine ich nicht APL, denn das wurde letztes Jahr sogar 40.

Nein, es ist Graphpak, eine Sammlung von APL-Funktionen für die Erstellung von Grafiken. Damit habe ich erstmals 1983 mit VSAPL auf einem IBM-Mainframe einige Balkendiagramme erstellt.

Viel später habe ich einige Fingerübungen mit Graphpak zur Darstellung von mehr oder weniger komplizierten mathematischen Fragestellungen unternommen. Ein wenig Animation beim Nachstellen von Fußballspielen war auch dabei. Aber für diesen Zweck erschien mir die Nutzung von Graphpak wie mit Kanonen auf Spatzen geschossen.

"Business Grafiken" werden heute kaum noch mit APL2 und Graphpak erstellt. Mir fällt spontan zumindest kein Anwendungsfall ein. Dies ist heute Aufgabe von Business Intelligence Software, aber vor allem und leider von Excel.

Trotzdem habe ich in den vergangenen Monaten die Kombination von APL2 mit Graphpak schätzen, wenn nicht sogar lieben gelernt. Gerade bei der Darstellung mathematischer Sachverhalte, wie z.B. von Funktionsverläufe im Reellen oder Komplexen, ist dieses Team für mich unschlagbar. Funktionen einer oder mehrerer Veränderlichen sind im Handumdrehen mit APL dem Computer nahe gebracht, mit PLOT kann man den Graphen dieser Funktion umgehend visualisieren:

x←¯10 to 10,0.1

PLOT x,[1.5] f x

Das war's schon.

Keine Angst vor der Übergabe großer Variablen als Argument einer Funktion! Es ist nämlich nicht so, dass sich nach Aktivierung der Funktion der Inhalt des Arguments gleich zweimal im Arbeitsspeicher ausbreitet. Statt eine Kopie anzulegen speichert APL nur einen Pointer.

Das spart Platz, aber nur solange bis in der aufgerufenen Funktion das Argument selbst modifiziert wird. Selbst die kleinsten Änderung (z.B. (↑Arg)←0 ) bewirkt eine umgehende Erstellung einer Kopie der ursprünglichen Variablen.

Das Gleiche gilt für ganz einfache Zuweisungen der Form C←B, selbst wenn B bereits nur einen Pointer zu A darstellt. Und was passiert nun mit dieser verpointerten Kette, wenn A bzw. B modifiziert wird?

Ich meine den Zeitstempel für die letzte Änderung einer Funktion oder eines Operators, also die "Fix Time". Die Antwort ist doch ganz einfach und auch keine 500€ wert: 2 ⎕AT FOOname liefert als Ergebnis einen 7-stellingen ganzzahligen Vektor mit Datum und Uhrzeit des letzten "Fix".

Nein, das wäre zu einfach. Die Frage geht nach der Stelle, wo diese Angaben in der APL-Datei abgelegt sind, also der Datei, die den gespeicherten Workspace enthält.

Wer suchet, der wird was finden, so auch hier. Nun habe ich das gestern bereits das vierte Mal durchexerziert. Es ist also Zeit, das endlich niederzuschreiben. Hier die Erkenntnisse:

Was war es doch schwierig. Jahrelang, nein sogar jahrzehntelang, haben APLer sich den Kopf darüber zerbrochen, wie sie ihre Funktionen (oder Operatoren) vernünftig drucken bzw. ausserhalb des jeweiligen APL-Systems als Textdokument darstellen oder bearbeiten können. Ich erinnere mich da an Begriffe wie Codepages, APL-fähige Drucker, Druckertreiber, Schriftarten ...

Und tatsächlich, es gibt ihn: den Fortschritt in der Computerei. Heute kann ich einfach per Mausklick eine APL2-Funktion als PDF-Dokument darstellen, und das sogar in Farbe.

Ich benötige dazu nur einen "Drucker", der kein Papier beschmiert, sondern PDF-Dokumente erstellt. Dies kann ich z.B. mit FreePDF erreichen.

Damit brauche ich nur im Editor das geöffnete APL2-Objekt auf diesen "Drucker" auszugeben. Ich erhalte eine PDF-Datei mit den "Ausdruck" des Objektes, sogar mit Zeilennummern und farbig- so wie der Editor APL2-Objekte darstellt.

Einfach und schön, einfach schön!

In der Regel befassen sich APL-Tagungen mit Themen wie "Problem X leicht und schnell gelöst mit APL", "So geht es mit APL" oder "APL und der Rest der Welt". Und es ist tatsächlich so: Mit APL lassen sich wichtige Anwendungen leichter und schneller realisieren.

Aber manchmal lernt man bei besagten APL-Treffen interessante Dinge außerhalb des heilen APL-Universums, gute Dinge aus einer anderen Welt, in der normalerweise das Böse herrscht. So war es vor einer Woche in Bingen. Bernd zeigte, wie man APL2 über die Java-Schnittstelle mit Open Office verbinden kann. Ich bin ihm dankbar für die ausführliche Einführung in die Welt der alternativen, offenen Software für Büroanwendungen.

Denn es ist alles vorhanden, was ich brauche, und das zu einem wirklich günstigen Preis, nämlich kostenlos. Aus Sicht eines Anwenders ist auch die Kompatibilität mit den MS Office Formaten vollkommen zufrieden stellend. Leider spielt das auch für mich eine wesentliche Rolle.

Da kann man lange suchen - kleiner Unterschied, große Wirkung.

So kennt die externe Funktion COM kennt das Kommando "WAIT", und es gibt COM-Objekte mit einer Methode namens "Wait". Dies sollte man nicht verwechseln, es ist mir trotzdem passiert.

Es ist wohl so, dass COM nur Kommandos in Großbuchstaben akzeptiert. So, wie es im Users Guide niedergeschrieben steht. COM 'WAIT' timeout ist ebenso valide wie COM 'PROPERTY' params, "COM 'Wait' timeout" wirft dagegen einen Domain Error aus.

Ich habe lange nach dem Grund für diese Fehlermeldung gesucht, David hat ihn herausgefunden. Glücklicherweise nicht sofort, ich brauche mich also nicht für vollkommen verblödet zu halten.

Bei Eigenschaften und Methoden von COM-Objekten ist die Situation in der Regel entspannter: Ob ich nun z.B. COM 'METHOD' handle 'Wait' param schreibe oder COM 'METHOD' handle 'WAIT' param ist einerlei, ich erhalte in beiden Fällen das erwartete Verhalten.

... das war vor CSD 10 die Frage.

Die Erkennung und Markierung von URLs in Kommentaren hat wohl vielen APL2-Fans nicht so recht zugesagt. Ich kann das nachvollziehen. Es wurden Dinge als URL erkannt, die nie als solche gemeint waren.

In der Regel hätte mich das auch nicht weiter gestört, denn ich lasse einem Doppelpunkt stets eine Leerstelle folgen. Dies widerspricht der Definition einer URL.

CSD 10 bietet nun eine richtige Lösung: Die Markierung von Zeichenfolgen in Kommentaren als HTTP-Link gibt es nun als Option. Im APL2 Objekt-Editor kann unter "Options/System Options" mit "Underline URL" entschieden werden, ob aus dem Editor heraus direkt auf Web-Seiten zugegriffen werden kann.

Als Voreinstellung ist diese Option nicht aktiviert.

Dies ist für alle die beste Lösung: Ein sinnvolles Feature, das bei Bedarf eingeschaltet werden kann.

Das ist nicht die einzige Neuerung der CSD 10. Doch dazu später mehr ...

Gestern hatte ich den Eindruck, eine magische Hand hat eine APL2-Funktion auf meinem Rechner verändert. Wenn überhaupt habe ich diese Funktion seit fast 2 Jahren nicht mehr angefasst, trotzdem fällt sofort eine Änderung ins Auge:

Diese Zeile (deren Inhalt hier unerheblich ist), ein vorher ganz unschuldiger Kommentar, erscheint urplötzlich unterstrichen

⍝LBAR:→(0∊⍴SP←(E_VKDA[⍙VKDA_INH⍳⊂'TANR';]∊2288 2480)/⍳2⊃⍴E_VKDA)/LTHV

Ich war es nicht, aber wer war es dann?

Viele, viele APL2-Fans tragen dafür die Verantwortung. Allen voran Bernd, daneben auch die Teilnehmer einer GSE-Arbeitsgruppensitzung (wovon ich auch einer war) und schließlich David.

Als ich diese Veränderung an einer anderen Stelle von ca. zwei Jahren das erste Mal sah, erinnerte ich mich an ein damals aktuelles GSE-Requirement. Wir hielten Bernds Vorschlag für sinnvoll, in Kommentaren von APL-Funktionen URLs einbetten und verlinken zu können. Damit erhält der APL2-Nutzer die Möglichkeit, aus einer APL2-Funktion heraus sich eine Web-Seite in seinem Standardbrowser anzeigen zu lassen.

Offensichtlich fand auch David die Idee interessant und die Umsetzung nicht zu aufwändig. Mit der nächsten CSD war dieses Feature verfügbar.

Eine unterstrichene Kommentarzeile ist als kein Bug in der Darstellung einer Funktion, sondern ein Feature.

Abstürzende Software ist ärgerlich. Aber das kommt selbst bei den besten Exemplaren dieser Spezies vor. Keine einigermaßen komplexe Anwendung ist fehlerfrei - solange Menschen ihre Finger im Spiel haben. Irren ist eben menschlich. Ich bin gespannt, wann wir endlich in der Lage sind, die Fehlerfreiheit von Programmen maschinell nachzuweisen.

Solange das nicht möglich ist, müssen wir mit allzu menschlichen Fehlern leben. Selbst APL ist davor nicht gefeit. Gerade beim Test neuer Features bringe ich ab und zu eine APL-Sitzung zum Absturz. Es passiert auch schon mal, dass ich durch wochenlange intensive Entwicklung einer APL2-Anwendung den dazugehörigen Workspace zerraspelt vorfinde. Aber stets hilft hier die )clear- )copy - )save - Sequenz.

Das alles kommt so selten vor, dass man getrost APL-Systeme als äußerst zuverlässig und stabil bezeichnen kann.

Auch gängige Anforderungen an die Kompatibilität innerhalb der APL-Versionen eines Herstellers werden zufriedenstellend erfüllt. Selbst eine Migration von APL-Anwendungen auf Vorversionen ist mit den üblichen Einschränkungen möglich.

Ganz anders bei MS Access. Ich habe selten eine Anwendung so schnell wegen simpelster Probleme komplett abstürzen sehen. Es genügte schon, eine mdb mit einem ins leere gehenden Verweis zu übernehmen. Auch bei der Aufwärtskompatibilität von Version 10 nach 11 liegt offensichtlich einiges im Argen.

Ich will nicht wissen, wie viele Entwickler bei Kleinstweich an Access rumentwickeln, es werden garantiert mehr sein als alle Entwickler von APL-Systemen zusammengenommen. Ich kann mich des Eindrucks nicht erwehren, dass in den vorliegenden Fällen die Softwarequalität umgekehrt proportional zur Größe der Programmierteams ist.