Die zweitschönste Nebensache der Welt

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.

Kaum ist die Version 6.0 raus und verfügbar, schon gibt es ein Upgrade. Das ist gut und nicht schlecht. Denn die Version 6.2 enthält einige interessante Neuerungen und Erweiterungen.

APL+Win 6.2 ist verfügbar für Kunden mit einer APL+Win 6.0 "Subscription", das ist eine Lizenz zum Upgraden. Eine Vollversion soll demnächst angeboten werden.

Die erste Neuerung ist die UNIQUE-Grundfunktion. Für mich eine freudige Überraschung. Das ist eine sehr nützliche Spracherweiterung!

Wie die neue Grundfunktion aussieht und wie sie funktioniert lässt sich aus der Ankündigung nicht ersehen. Genauso wenig wie Details zu den weiteren neuen Features:

"The implementation of ⎕FX for ⎕MOM object system objects.

The new ")OUTPUT STRICT" state that only produces "IMPLICIT OUTPUT"
errors when visible output is generated.

The new Zip class for ⎕wi that will allow zipping and unzipping of files.

The new Session Manager printer margin settings."

Spannend und bestimmt nützlich ist auch die Unterstützung für zip.

Also werde ich auf 6.2 upgraden.

Wohl dem, der eine "Subscription" hat.

Mit der Version 6.0 unterstützt APL+Win nun auch Unicode-Daten.

Dies hatte ich in meinem Blog-Eintrag zu den Neuerungen dieser Version nicht erwähnt - aus zwei Gründen: Die Unterstützung ist noch nicht vollständig und ich hielt den Bedarf hier im Lande für nicht so gravierend. Falsch, letzteres ist falsch. Also Schade über mein Haupt. Ich gelobe Besserung.

APL2000 schrieb zur Unicode-Unterstützung

Initial Support for Unicode Character Data
⎕UCS system function supports a 32-bit Unicode character data representation. Initially support is provided for some primitives and planned for others and the other primitives yield the appropriate NONCE or DOMAIN error messages.
Unicode character data displayed in the Session Manager will be shown as <<<UCS Characters>>>.
The ⎕WI interface with Windows has been enhanced to interchange Unicode character data with ActiveX controls. The unicodebstr property has been added to control this behavior.

Auf den DPC-Seiten findet man

Unicode-Unterstützung
APL+Win V6 bietet erstmals eine Unterstützung für Unicode-Daten. Die Unterstützung von Unicode ist noch nicht in vollem Umfang implementiert und soll in späteren Releases weiter ausgebaut werden. Zunächst unterstützen nur die APL-Funktionen JOIN bzw. RAVEL (,⍪), SHAPE bzw. RESHAPE (⍴), PICK (⊃), ENCLOSE (⊂) und FIRST (↑) diesen Datentyp.
Eine neue Systemfunktion ⎕UCS dient zur Erzeugung von Textvektoren aus Unicode, ⎕DR wurde um den Datentyp 322 für Unicode-Textvektoren erweitert.

An diesem Text hatte ich noch selbst rumkorrigiert.

Mein erster Einwand bleibt richtig: Die Unterstützung ist noch nicht vollständig. Schön ist, dass APL+Win die gleiche Systemfunktion für die Konvertierung von und zu Unicode-Zeichen verwendet wie APL2.

Mein erstes, selbst erstelltes Sudoku gehört in die Kategorie "Für blutige Anfänger". Ganz einfach zu lösen, straight forward, zu einfach.

Das liegt an der Zahl der vorgegebenen Felder: 48. Das sind zu viele.

Also was liegt näher als einige Vorbelegungen zu entfernen. Aber Vorsicht! Der Schwierigkeitsgrad muss beibehalten werden, das resultierende Sudoku soll weiterhin mit SCAN und FILL zu lösen sein.

Genau das macht meine Funktion OPT_SUDOKU, die eine gewünschte Anzahl Vorbelegungen entfernt unter Beibehaltung der gewünschten Anforderung.

Und dies ist die Variante meines ersten Sudokus, vermindert um 21 zufällig ausgewählte vorbelegte Felder:


Das sieht doch schon anspruchsvoller aus.

"Sudoku Solver by Logic" bewertet dieses Sudoku mit einem Score von 108. Schwere Sudokus haben dort einen Score von 117, mittel schwere eine von 60.

"Mein Erstes" erhält dort einen Score von 40 - "easy".

Geschrieben, getan!

Nein, ich meine nicht das erste Sudoku, das ich jemanls gelöst habe (das habe ich nicht mehr), sondern das erste, das ich erstellt habe.




Und so wurde es gemacht:

Noch einige Worte zu meinem Trial-and-Error-Funktion ...

Mit wenigen Änderungen finde ich alle möglichen Lösungen zu einem Sudoku. Anstatt bei der ersten gefundenen Lösung (siehe 3.2) aufzuhören, kann man auch alle Kandidaten bis zum bitteren Ende durchlaufen und die jeweiligen Lösungen sammeln. Je nachdem wie das Problem gestellt ist, können das sehr viele werden, so viele, dass einem der Workspace um die Ohren fliegt. Was da passieren kann, habe ich noch nicht ausprobiert, ich tippe mal irgendwo in den Tiefen der Rekursion auf einen WS Full.

Lösungen sammeln war aber nie der Anlass für den Trial-and-Error. Es war die Idee, damit einen billigen Sudoku-Generator zu bekommen. Und das funktioniert prächtig:

Erst wollte ich nie einen eigenen Sudoku-Löser schreiben, dann habe ich doch einen implementiert. Zwar nur einige logische Methoden, aber immerhin.

Dann wollte ich kein Trial-and-Error-Verfahren vorsehen, aber auch hier bin ich mir jetzt untreu geworden. Es war ja so verlockend einfach:

Versuche zuerst ein Sudoku mit logischen Methoden zu lösen, soweit es geht. Als Ergebnis erhalte ich

(1) entweder ein nicht lösbares Sudoku,
(2) ein vollständig gelöstes Sudoku
(3) oder ein Sudoku, das sich nicht weiter mit den vorhandenen logischen Methoden lösen lässt.

Bei (1) gibt es keine Lösung des Sudokus, bei (2) habe ich eine Lösung gefunden, bei (3) tue ich das, was ich nie tun wollte: ich führe den Rechner in Versuchung.

Als jemand, der Mathematik studiert hat, wird man schon mal von "normalen" Menschen mit unausgesprochenem Mitleid versehen. Schließlich haben doch Mathematiker nur Zahlen im Kopf, und es mangelt ihnen häufig an sozialer Kompetenz. Aber dafür können wir auf unserer Habenseite eine erlernte Sorgfalt im Umgang mit Zahlen und Statistiken verbuchen.

Zahlen alleine sind weder wahr noch falsch. Zahlen aus statistischen Erhebungen werden nur im Zusammenhang mit Aussagen über das Untersuchungsgebiet interpretierbar. Und diese sollten stets mit dem reinen Zahlenwerk angegeben werden.

Der Sündenfall

Daher hat mich die folgende "Untersuchung" geradezu fassungslos das Heft 22 der Computerwoche zuschlagen lassen. Unter "Zahlen - Prognosen - Trends" (Seite 58) ist dort Folgendes zu lesen:

"Im Markt für relationale Datenbanksysteme gelang es Oracle auch im letzten Jahr. den Wettbewerb in Schach zu halten."

So weit, so unproblematisch. Doch dann geht's ans Zahlenwerk unter dem Titel "Weltweiter Markt für relationale Datenbanksysteme (RDBMS), 2005": Oracle 44,6%, IBM 21,4%, Microsoft 16,8% usw. Die Angaben beziehen sich gemäß der Fußnote auf einen Gesamtmarkt von 14.6 Mrd. Dollar. Quelle: IDC.

IDC, klingt doch seriös. Ist es aber nicht, es grenzt eher an einen üblen Versuch von Verdummung. Bei ein wenig journalistischer Sorgfalt hätte der zuständige Redakteur mal ins eigene Archiv geschaut - was ich dann getan habe.

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.

Meine Freude über die stetig wachsende Marktdurchdringung des IE-Konkurrenten Firefox wird umgehend leicht getrübt durch eine heise-Meldung:

"Nachdem die Ad- & Spyware-Szene bereits seit Jahren auf diesem Weg Lücken des Internet Explorer ausnutzt, geraten durch die steigende Verbreitung jetzt offenbar auch vermehrt Firefox-User ins Visier."

Jede Medaille hat eben zwei Seiten.

Ich habe bisher nie behauptet, dass die Computerwoche zum erweiterten Kreise der Microsoft-Apologeten gehöre, auch wenn sie schon mal einen solchen Verdacht nahe legt. Im einem CW-Artikel unter dem Titel "Mozilla-Chefin: Datenschutz treibt Marktanteil von Firefox an" ist weiter unten folgende Aussage zu finden:

"Netscape und Microsoft hatten sich in den neunziger Jahren in einem erbittert geführten "Browser-Krieg" gegenübergestanden, den Microsoft - auch durch den Einsatz von illegalen Geschäftspraktiken - für sich entscheiden konnte."

"Illegale Geschäftspraktiken" - so klare Einschätzungen wünsche ich mir häufiger.

Es sieht tatsächlich so aus, dass wir in diesem unseren Lande eine vorbildliche Fußball-Weltmeisterschaft hinlegen: Stimmung super, Stadien voll, Organisation typisch deutsch - Franz und Co. sei Dank.

Mir war bisher noch nicht bekannt, dass wir Deutschen kollektiv so durchknallen können.

Aber wir sind wohl nicht nur in Sachen Fußball-WM vorbildlich, sondern in der korrekten Nutzung von Web-Browsern:

Nach eine Studie von Techconsult (s. CW 21, 26.05.2006) nutzen in Deutschland bereits 30% Firefox als Browser. In Europa sind es dagegen im Durchschnitt erst 20%, auf den anderen Kontinenten sogar noch weniger.

Erfreulich ist auch, dass die Popularität von Firefox weltweit weiterhin stark ansteigt. In Deutschland wuchs der Anteil der Firefox-Nutzer im Vorjahrsvergleich um ca. 20%, in Europa sowie auch weltweit um ca. 30%.

Ein Grund für diese erfreulich vernünftige Entwicklung sind nach Ansicht der Mozilla-Präsidentin Datenschutz- und Sicherheitsüberlegungen der Anwender.

Weiter so, der IE hat immer noch zu viele Nutzer und Löcher.

Nach dem Start von APL2 sind werden sofort und automatisch zwei Shared Variables deklariert. Dies kann man mit dem APL2 SVP Monitor gut beobachten:

Entweder die apl2svpt.exe im APL2 bin-Verzeichnis ausführen oder - seit CSD 8 - den Monitor einfach durch Klick auf das "APL2 SVP Monitor"-Symbols in der Werkzeugleiste aktivieren. Dort findet man unter Info/Processors die mit APL2 gestarteten Partnerprogramme: den Session-Manager (AP120), den Interpreter (AP1), den Stacksprozessor (AP101) und die ID der Sitzung.

Schaut man sich die gemeinsamen Variablen zu diesen Prozessoren an, so sieht man, dass bereits zwei Variablen zwischen dem AP120 und dem AP1 deklariert wurden: AP120_SIGNAL und APL2. Öffnet man ein APL2-Objekt in den Object Editor, so gesellt sich als dritte Variable AP120_EDIT hinzu.

Über die Variable APL2 beschickt der Session Manager den APL2-Interpreter mit allen möglichen APL2-Anweisungen und Kontrollsignalen. Im Gegenzug erhält die Variable APL2 vom Interpreter das Ergebnis der Ausführung der Anweisung bzw. Informationen über aufgetretene Fehler.

Es geht aber auch ohne den Session Manager. Jedes beliebige selbst geschriebene Programm kann über das APL2 SVP Programming Interface die Variable APL2 ansprechen. Sobald der Interpreter als AP 1 ein Angebot für eine gemeinsame Variable namens APL2 erhält, wird dieses auch akzeptiert und der Interpreter erhält seine Anweisungen von jenem Programm.

So kann jeder, der der C-Programmierung mächtig ist seinen eigenen Session Manager schreiben. Ich kann mir aber kaum vorstellen, das dies irgend jemand ernsthaft tun würde.

Die Kommunikation mittels der Variablen APL2 mit dem Interpreter wird im User's Guide unter der Überschrift "Shared Variable Interpreter Interface" ab Seite 120 beschrieben. Das "SVP Programming Interface" ist dort wird ab Seite 604 dokumentiert.

Hier einige Presse Reaktionen auf das DB2 9 Announcement:

Die Computerwoche titelte am 8.6.2006 "IBM setzt im Kampf gegen Oracle auf XML". Langsam scheint die CW es gefressen zu haben, dass Oracle und Microsoft der XML-Integration in DB2 9 zur Zeit nichts entgegen zu setzen haben. Die berüchtigten "Kenner der Datenbankszene" kommen nicht mehr zu Wort.

Aber einen kleinen Seitenhieb konnte die CW sich doch nicht verkneifen. Da wird zuerst ein IBM-Oberer zitiert mit den Worten: "In Viper stecken alleine 68 Patente, und 750 Entwickler haben daran mehr als fünf Jahre lang gearbeitet." und "Niemand sonst hat so etwas, und die anderen werden Jahre brauchen, um das aufzuholen." Verschämt geklammerter Kommentar des Redakteurs: "(Ob das die Software AG wohl genauso sieht?)". Ich denke, Tamino wird von IBM nicht als der Wettbewerb angesehen. Die Stoßrichtung der zitierten Aussage geht eher in Richtung Oracle und Mickeysoft. Ich würde mir von der CW solche Nörgeleien auch mal zu deren Datenbank-Elaboraten wünschen.

Durchweg sachlich und informativ kommentierte heise am 9.6.2006 mit der Headline "IBM bringt neuen Datenbankserver".

Hat man beide Artikel gelesen, bringt zdnet Beitrag "IBM will mit XML-Funktionen Oracle-Kunden locken" eigentlich keine weiteren Informationen. Eine Unstimmigkeit mit der Computerwoche fällt hier auf: