A Note on the Match Function in APL
Vector 7:4, page 133
The text of this article is not yet online. No complete scan of this issue has been found. The only copy found, on vector.org.uk, is damaged: its page images are lost, but the text machine-read from them survives, shown below (help find a scan).
Unedited OCR text, machine-read from a scan now lost: it contains errors, and its APL is wrong. Shown for searching.
VECTOR Vol.7 No.4
A Note on the Match Function in APL
by Joseph L.F. De Kerf
Abstract In SHARP APL, empty arrays of the same structure always match. In APL2-like implementations, empty arrays only match if they are of the same structure and prototype. As a compromise, the APL Working Group - designing the new standard ISO APL Extended - defines the match function such that when the arguments are empty arrays same structure a domain error is reported. It is suggested in this note that the definition of the match function for arrays with the same structure should be consistent with the definition of the primitive scalar function equal.
Introduction In ISO APL 8485 (1), the dyadic scalar function equal Z+A=B is defined such that, if the arguments 4 and B are arrays of the same structure, the explicit result Z is a boolean array of the same structure as the arguments, containing a 1 where the corresponding elements of A and B are equal, and 0 otherwise. If one argument is a scalar or one-item array, or if both arguments are one-item arrays, so-called scalar extension is applied. If the arguments A not conform, an appropriate error message is reported. Comparison Tolerance [ICT is an implicit argument.
Apparently there is no problem with this definition. With the introduction of arrays of arrays however, a controversy has arisen about the new dyadic function match Z«A=B. In some implementations, empty arrays of the same structure always match. In some other implementations, empty arrays of tle same structure only match if they are of the same prototype. Confronted with this controversy, the APL Working group ISO-IEC/JTC1/SC22/WG3 - designing the new standard ISO APL Extended - defines compromise the match function such that when the arguments are empty arrays of the same structure a domain error is reported.
The SHARP APL Approach In SHARP APL (2), based on the grounded array concept, the dyadic function Z<A=B, if the arguments A and B are of the same structure and data, returns as
133
VECTOR Vol.7 No.4
explicit result boolean scalar 1, and 0 otherwise. Two empty arrays of the same structure such as the empty character vector '' and the empty numeric vector 10 match, as they have no elements; ''=10 «+ 1. The definition conforms to Ken Iverson’s APL Dictionary (3).
The NARS Approach
In APL*PLUS NARS (4) and IBM APL2-like implementations (6), based on the floating array concept, two arguments match if they are of the same structure and data, and if empty, they are of the same structure and prototype. Two empty arrays of the same structure but different prototype, such as the empty character vector '' and the empty numeric vector 10, do not match: Tre1d <> 0.
The basic idea seems to be that two arrays match if and only if they behave in the same way. For example, the first function +B applied to the empty character vector '' gives a blank, while applied to the empty numeric vector 10 gives a zero, and as such they do not match. However, match doesn’t guarantee the same behaviour. For instance (the example is from a private communication by Eugene McDonnell):
Ocr+1z°13 Ati B+0,999999999999999 A=B 1 (1-A)21-B 9
The reason is of course that, such the dyadic scalar function equal, comparison tolerance (CT is an implicit argument. If comparison tolerance is set to zero, or the match function is defined as independent of comparison tolerance, two non-empty the same structure which match, always behave in the same way. And in the example given above, A and 2 no longer match:
o¢r<o Atl B+0.999999999999999 A=B 0 (1-A)s1-B8 0
134
VECTOR Vol.7 No.4
Defining the dyadic function match as independent of comparison tolerance however would produce situations which do not conform with the definition of the dyadic scalar function equal and are unacceptable. For instance, the product of an integer with its inverse could give a result which never matches the value one:
A+100p1 B«Bx+B+1100 Ocr<1E-13 A=B
ocr+o A=B 0
the discrepancies being dependent from the particular implementation used. For the implementation used in preparing this note (VAX APL Version 3 - DEC):
Ae100p1 B<100 Ocr<o (A#Bx+B)/B 23°27 46 54 89 92
which means that for this implementation the identity Bx+B«+>1 does not hold for the integers listed (23-27-46-54-89-92). Consistency of the concept match with the basic idea of assuring the same behaviour seems not to be feasible.
The ISO APL Approach
In the meantime, the APL Working Group ISO-IEC/JTC1/SC22/WG3 is preparing a new APL standard, provisionally called ISO APL Extended. At its Copenhagen Meeting in August 1990, the APL Working Group decided that "APL Extended must include the generalized array facility by defining the functions enclose ¢ and disclose > (as defined by APL2)”. As far as the inclusion of the dyadic function match is concerned however, it was clear that it would be very difficult to come to a concensus about the controversy described.
Finally, based earlier proposition from Eugene McDonnell (6), it was decided to define the dyadic function match in such a way that, when the arguments are empty arrays of the same structure, a domain error is reported. This gives the implementor the opportunity to choose - as a consistent extension - whether in this case the explicit is 1 or 0. This has no sense. In addition, as Jean-
135
VECTOR Vol.7 No.4
Jacques Girardot stated at the APL 90 Conference (7), "it means that what the standard defines conforming program should not use A=B without first checking the case of empty operands of the same dimensions” - an unacceptable situation.
Suggestions There is however a plausible solution. APL, as every higher level programming language, even assembler, contains a lot of redundancy. Redundancy increases the power language, but redundancy must be consistent. For the dyadic function match A=B for instance, this means that its definition must be consistent with the definition of the dyadic scalar A=B as given above; if two arrays have the same structure, they should match if and only if the conjunction 4 of the - enlist of A=B is 1 or A=B ++ A/ENLIST A=B (ENLIST? R being a monadic function that returns as explicit result a simple vector whose elements are all the single scalars in the right argument R taken in eventually nested row major order, as for instance the primitive function IR in some APL2-like implementations and the monadic system function QENLIS? R in VAX APL Version 3 of DEC). This gives for two empty arrays with the same structure instance the empty character vector '' and the empty numeric vector 10:
A/DENLIST ''=10
which means that those empty arrays match. Maybe the APL Working Group ISO-IEC/JTC1/SC22/WG3_ could reconsider its decision taken at the Copenhagen Meeting of August 1990. and discuss this proposal of consistency which, as far as the author of this note is concerned, is a must.
136
VECTOR Vol.7 No.4
References
(1]
22]
BI
i4]
B]
[6] ISO 8485; 1989 (E); Programming Language - APL;First Edition ~ 1989 11- 01; Edited by A. Morrow; International Organization for Standardization - ISO, Geneva, Switzerland, 1989. See also : ISO 8485 (F).
K.E. Iverson; Composition and Enclosure; SHARP APL Technical Note SATN-41; LP.Sharp Associates Limited, Toronto, Ontario, 20 June 1981.
K.E. Iverson; A Dictionary of APL; Publication No. 0402 8703 E3, LP.Sharp Associates Limited, Toronto, Ontario, March 1987. See also: APL Quote Quad, Vol. 18, No. 1, September 1987, pp.5-40.
C.M. Cheney; APL*PLUS Nested Arrays System ~ Reference Manual; Publication No. P046-0381; STSC, Bethesda, Maryland, March 1981.
D. Rabenhorst; A PL2 Language Manual - Installed User Program 5798-D]B; Publication No. SB21-3015-0 ~ First edition; [BM Corporation, APL Development Department, San Jose, California, June 1982.
E.E.McDonnell; Rationale for the Match Function - Proposed text for ISO Document; APL Working Group ISO-IEC/JTC1/SC22/WG3-N200; Dated 19 May 1988.
JJ. Girardot; Arrays and References; APL 90 Conference Proceedings, Copenhagen, Denmark, 13-17 August 1990; Edited by P Gjerlov; APL Quote Quad, Vol. 20, No.4, July 1990, pp.161-172
137