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.
Inzwischen kenne ich die Erklärung für diesen Heißhunger auf Ressourcen. Allgemein kann nur vor der Verwendung von N-wise Reduce mit geschachtelten Argumenten - Tiefe 2 und größer - gewarnt werden, wenn die Größe des Arguments einen signifikanten Anteil am verfügbaren Workspace ausmacht.
In allen anderen Fällen, vor allem bei flachen, homogenen (entweder numerisch oder alphanumerisch) Argumenten, kann man diese schöne Schreibweise getrost verwenden. Mit Workstation APL2 sowieso und das ohne jegliche Einschränkung.
Ich hoffe, das Problem wird für den Mainframe behoben.